cwielenb/CNCF-Dataset huggingface dataset:
Project: Grafana Mimir (Observability and Analysis / Observability)
File: _index.md

description: Visualize your metric data with Grafana title: Visualize metric data menuTitle: Visualize weight: 45 keywords: visualize grafana dashboards has built-in support for Mimir through the Prometheus data source type. These steps are done in a local or on-premise instance of Grafana. Log in to your Grafana instance. If this is your first time running Grafana, the username and password are both `admin`. From within Grafana, go to `Connections` > `Add new connection`. Search for Prometheus, and select Create a Prometheus data source. In the HTTP > Prometheus server URL field, enter a server URL: If you deployed Mimir via the `mimir-distributed` Helm chart, the default URL inside the Kubernetes cluster is `http://<HELM-RELEASE>-nginx.<MIMIR-NAMESPACE>.svc/prometheus`, and `http://<INGRESS-HOST>/prometheus` from the outside, provided that you set up an ingress. If you are running microservices, point to the proxy in front of Mimir (such as Nginx or the GEM gateway) rather than to one component of Mimir. To view metrics in Grafana, select Explore. From the top-left, select the newly created data source. Select a metric, apply (optional) label filters, and select Run query. Learn more about PromQL and querying by reading . Read more about Grafana's feature. Read about Grafanas built-in support for the .
Project: Promscale (Observability and Analysis / Observability)
File: binary.md

A full Promscale installation consists of both the promscale connector, and a TimescaleDB instance with the Promscale Extension installed. We provide pre-built binaries (and packages) for the both. The simplest way to get started with TimescaleDB and the Promscale Extension is to install both from the TimescaleDB package repository. You can find instructions on how to install TimescaleDB for your favourite distribution . Once you have installed TimescaleDB for a specific Postgres version from our package repository, you can simply install the Promscale Extension for the same Postgres version, e.g.: ```bash apt-get install -y promscale-extension-postgresql-14 ``` Similarly, you can get the latest version of the Promscale Connector from the official (instructions for installing packages from the repository can be found ). ```bash apt-get install -y promscale ``` If you're using systemd, you can use our unit and an associated configuration file to configure the Promscale connector. Otherwise, you can start the Promscale connector directly: ```bash promscale -db.host <DBHOSTNAME> -db.port <DBPORT> -db.name <DBNAME> -db.password <DB-Password> -db.ssl-mode allow ``` Note that the flags `db.name` and `db.password` refer to the name and password of your TimescaleDB database. Further note that the command above starts the Promscale connector in "SSL allowed" mode. For production setups it's recommended to start Promscale in "SSL required" mode enabled. To do so, configure your TimescaleDB instance with ssl certificates and drop the `-db.ssl-mode` flag. Promscale will then authenticate via SSL by default. You must tell prometheus to use this remote storage connector by adding the following lines to `prometheus.yml`: ```yaml remote_write: url: "http://<connector-address>:9201/write" remote_read: url: "http://<connector-address>:9201/read" read_recent: true ``` Note: Setting `read_recent` to `true` will make Prometheus query data from Promscale for all PromQL queries. This is highly recommended. You can configure Prometheus remote-write with our recommended configurations from . The Promscale Connector binary is configured through either CLI flags, environment variables, or a YAML configuration file. Precedence goes like this: CLI flag value, if not set, environment variable value, if not set, configuration file value, if not set, default value. All environment variables are prefixed with `PROMSCALE`. Configuration file is a YAML file where the keys are CLI flag names and values are their respective flag values. The list of available cli flags is available in in our docs or by running with the `-h` flag (e.g. `promscale -h`) Before building, make sure the following prerequisites are installed: The Promscale Connector is a Go project managed by go modules. You can download it in any directory and on the first build it will download it's required dependencies. ```bash $ git clone git@github.com:timescale/promscale.git $ cd ./promscale $ cd cmd/promscale $ go install $ go build ./... ```
Project: Netdata (Observability and Analysis / Observability)
File: web_log_5m_successful_old.md

This alert, `weblog5msuccessfulold`, calculates the average number of successful HTTP requests per second for the 5 minutes starting 10 minutes ago. If you receive this alert, it means that there might be a significant change in the number of requests your web server is serving. The alert is useful for understanding the workload on your web server based on historical request data. It helps to ensure that the web server is functioning as expected and can handle the current number of users without negatively impacting their experience. To troubleshoot this alert, follow these steps: Check the current number of successful HTTP requests to compare with the historical data of the alert. You can use Netdata's web dashboard to see the current requests rate in real-time. If the number of requests has increased significantly, it might indicate a potential issue. Identify any potential issues or errors on your web server. Check the server's error logs for any signs of abnormal behavior or error messages. This can help you determine if there are any underlying issues causing the increase in requests. Analyze the user traffic to understand the cause of the increase in successful requests. This could be caused by a sudden spike in website visitors, a DDoS attack, or the introduction of new and popular content on your website. You can use tools like Google Analytics or server access logs to get detailed information about user traffic. Review server resources and performance to ensure the web server has adequate resources to handle the request load. If the number of requests is higher than usual, check the server's CPU usage, memory usage, and network bandwidth to ensure optimal performance. Evaluate server configuration to check for any misconfigurations, outdated software, or resource limitations that may impact the handling of requests. Update or adjust configurations as necessary to improve the web server's performance. Monitor and take necessary actions based on your findings. If the increase in successful requests is a result of legitimate traffic, ensure that your web server can handle the extra load. If the traffic is malicious or the result of an attack, consider implementing security measures like rate-limiting or blocking IPs.
Project: Keep (Observability and Analysis / Observability)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: '' assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: Thanos (Observability and Analysis / Observability)
File: SECURITY.md

At the Thanos team we are not security experts. However we try our best to avoid security concerns and to avoid writing features that handle sensitive information at all. It's worth noting that we assume metric data to be sensitive and important. External labels and query API parameters are considered less sensitive, as they are logged and put into metrics/traces. We follow best programming practices. We test heavily, including e2e tests against major object storages. We use vetting and static analysis tools on every pull request. We use secure protocols for building processes, e.g. when producing Docker images. We don't put any data that is stored in the TSDB into logs or instrumentation. If we use crypto tools, we always rely on FLOSS and standard libraries, like the official library. We always use TLS by default for communication with all object storages. We use stable Go versions to build our images and binaries. We update Go as soon as a new version is released. We use only FLOSS tools. We don't encrypt metrics in local storage, i.e. on disk. We don't do client-side encryption for object storage. We recommend setting server-side encryption for object storage. We don't allow specifying authorization or TLS for Thanos server HTTP APIs. | Version | Supported | |--|--| | >= 0.10.1 | :whitecheckmark: | | < 0.10.1 | :x: | If you encounter a security vulnerability, please let us know privately via the Thanos Team email address: thanos-io@googlegroups.com.
Project: Netdata (Observability and Analysis / Observability)
File: web_log_5m_requests_ratio.md

The `weblog5mrequestsratio` alert indicates that there is a significant increase in the number of successful HTTP requests to your web server in the last 5 minutes compared to the previous 5 minutes. This alert is important for monitoring sudden traffic surges, which can potentially overload your server. Check the source of the increased traffic Use web server logs to determine the source of the increased traffic. Identify if the requests are coming from a specific IP address, group of IP addresses, or even bots. For example, for Nginx, you can check the log files at `/var/log/nginx/access.log`. For Apache, the logs can be found at `/var/log/apache2/access.log`. Analyze the requests Look at the type of requests (GET, POST, etc.) and the requested resources (URLs). This analysis can help you understand if the increase in traffic is legitimate or if it's due to an issue like a DDoS attack or a web crawler. Monitor server performance Use monitoring tools like `top`, `iotop`, or Netdata itself to check your server's performance metrics. Keep an eye on CPU, RAM, and disk usage to ensure that the server is not getting overloaded. Optimize server resources and configuration If you find that the traffic increase is legitimate and your server is struggling to handle the load, consider optimizing your server resources and configuration. Techniques include: Increasing server resources (CPU, RAM, disk) Using a caching mechanism Load balancing and scaling out your infrastructure User connection rate limiting and request throttling Mitigate potential attacks If the analysis reveals that the increase in traffic is due to a DDoS attack, implement mitigation strategies like firewalls, IP blocking, or using a web application firewall (WAF). Ensure that you have a robust security system in place to protect your server from such attacks.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_cluster.KubeManagedFieldsEntry.md

title: "Interface: KubeManagedFieldsEntry" linkTitle: "KubeManagedFieldsEntry" slug: "libk8scluster.KubeManagedFieldsEntry" .KubeManagedFieldsEntry ManagedFieldsEntry is a workflow-id, a FieldSet and the group version of the resource that the fieldset applies to. `KubeManagedFieldsEntry` apiVersion: `string` APIVersion defines the version of this resource that this field set applies to. The format is "group/version" just like the top-level APIVersion field. It is necessary to track the version of a field set because it cannot be automatically converted. _ fieldsType: `string` FieldsType is the discriminator for the different fields format and version. There is currently only one possible value: "FieldsV1" _ fieldsV1: `object` FieldsV1 holds the first JSON version format as described in the "FieldsV1" type. _ manager: `string` Manager is an identifier of the workflow managing these fields. _ operation: `string` Operation is the type of operation which lead to this ManagedFieldsEntry being created. The only valid values for this field are 'Apply' and 'Update'. _ subresource: `string` Subresource is the name of the subresource used to update that object, or empty string if the object was updated through the main resource. The value of this field is used to distinguish between managers, even if they share the same name. For example, a status update will be distinct from a regular update using the same manager name. Note that the APIVersion field is not related to the Subresource field and it always corresponds to the version of the main resource. _ timestamp: `string` Time is the timestamp of when the ManagedFields entry was added.The timestamp will also be updated if a field is added, the manager changes any of the owned fields value or removes a field. The timestamp does not update when a field is removed from the entry because another manager took it over.
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: version-comparison.md

sidebar_position: 3 You are free to run the Open Source version of Flagsmith however you see fit! There are some differences between the Open Source, SaaS hosted and Enterprise versions: The Open Source version has no API request or Identity limits - you can run as many API instances in a cluster as you wish. The Open Source version has no Dashboard User limits. The Open Source version has no Environment limits. The Open Source version is limited to a single Project. The SaaS and Enterprise versions have . The SaaS and Enterprise versions have . The SaaS and Enterprise versions have . The SaaS and Enterprise versions have additional Authentication Providers: - - :::tip You can switch between SaaS and Self Hosted Flagsmith using our . ::: Our SaaS platform has a number of benefits: You can get up and running right away. Our global provides global low latency flags. We aim to serve all flag requests in < 150ms, globally. Get real-time flag updates to your clients, the moment they are changed in the dashboard. We deal with platform upgrades, security patches, scaling and backups. You can run our Enterprise version either on-premise, or we can provide private cloud instance dedicated to your organisation. . , , and authentication, as well as the ability to lock authentication to a single provider. Additional database engines: Oracle, SQL Server and MySQL. Additional deployment and orchestration options as detailed below. Completely Free! The Open Source version has no API request or Identity limits - you can run as many API instances in a cluster as you wish. The Open Source version has no Dashboard User limits - you can have as many team members as you wish. Deploy with one click to a number of different .
Project: Grafana (Observability and Analysis / Observability)
File: _index.md

aliases: guides/ guides/whats-new-in-v2-1/ guides/whats-new-in-v2-5/ guides/whats-new-in-v2-6/ guides/whats-new-in-v2/ guides/whats-new-in-v3-1/ guides/whats-new-in-v3/ guides/whats-new-in-v4-1/ guides/whats-new-in-v4-2/ guides/whats-new-in-v4-3/ guides/whats-new-in-v4-4/ guides/whats-new-in-v4-5/ guides/whats-new-in-v4-6/ guides/whats-new-in-v4/ guides/whats-new-in-v5-1/ guides/whats-new-in-v5-2/ guides/whats-new-in-v5-3/ guides/whats-new-in-v5-4/ guides/whats-new-in-v5/ guides/whats-new-in-v6-0/ guides/whats-new-in-v6-1/ guides/whats-new-in-v6-2/ guides/whats-new-in-v6-3/ guides/whats-new-in-v6-4/ guides/whats-new-in-v6-5/ guides/whats-new-in-v6-6/ guides/whats-new-in-v6-7/ whats-new-in-v2-0/ whats-new-in-v2-1/ whats-new-in-v2-5/ whats-new-in-v2-6/ whats-new-in-v3-0/ whats-new-in-v3-1/ whats-new-in-v4-0/ whats-new-in-v4-1/ whats-new-in-v4-2/ whats-new-in-v4-3/ whats-new-in-v4-4/ whats-new-in-v4-5/ whats-new-in-v4-6/ whats-new-in-v5-0/ whats-new-in-v5-1/ whats-new-in-v5-2/ whats-new-in-v5-3/ whats-new-in-v5-4/ whats-new-in-v6-0/ whats-new-in-v6-1/ whats-new-in-v6-2/ whats-new-in-v6-3/ whats-new-in-v6-4/ whats-new-in-v6-5/ whats-new-in-v6-6/ whats-new-in-v6-7/ description: Learn about new and updated features in Grafana. labels: products: cloud enterprise oss menuTitle: What's new title: What's new in Grafana weight: 1 For release highlights, deprecations, and breaking changes in Grafana releases, refer to these "What's new" pages for each version. {{% admonition type="note" %}} For Grafana versions prior to v9.2, additional information might also be available in the archive of . {{% /admonition %}} For a complete list of every change, with links to pull requests and related issues when available, see the .
Project: Vector (Observability and Analysis / Observability)
File: 2021-06-02-drop-jemalloc.md

date: "2021-06-02" title: "Switching to the system allocator" description: "Vector has switched from using jemalloc to the system allocator" authors: ["jszwedko"] pr_numbers: [6781] release: "0.14.0" hideonrelease_notes: false badges: type: "announcement" domains: ["performance"] Since version 0.2.0, Vector has used [jemalloc] as its memory allocator on *nix-based OSes. As part of some ongoing performance work, we've made the decision to switch to the system allocator provided by the platform Vector is deployed on. This will be either the for `glibc`-based builds (like Debian) or the for `musl`-based builds (like Alpine Linux). In environments where Vector has access to multiple CPUs, we recommend using the `glibc`-based builds as, at the time of writing, [we have observed that the GNU allocator performs better][performance] when running on multiple threads. If you are installing one of the packages or release assets listed on the , then you will be getting a `glibc` build. `musl` builds are available through the [full release asset listing][014full]. If you are running Vector in Docker, we recommend using the `v0.14.0-distroless-libc` image for a light-weight Vector image; however the `v0.14.0-debian` image will also be using the GNU Allocator. The `v0.14.0-alpine` and `v0.14.0-static` images use `musl` as `glibc` is not available there. This change was made largely because we had insufficient evidence and motivation to use anything other than the system allocator which is a sensible default otherwise. As we have a better understanding of Vector's allocation profile, it is likely we will revisit this decision.
Project: Checkmk (Observability and Analysis / Observability)
File: 16519.md

key | value | date | 2024-02-16T13:37:01+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes This werk makes it possible to create a BI rule via the REST-API using the same schema that is returned in a response. Previously, this was not possible after some changes to how our label_groups are now configured.
Project: Checkmk (Observability and Analysis / Observability)
File: 16408.md

key | value | date | 2024-03-07T13:47:39+00:00 version | 2.4.0b1 class | fix edition | cre component | omd level | 2 compatible | yes Sites may have configuration, MKPs and other local files, which are incompatible with the version targeted by `omd update`. If such a problem occurs, then aborting the update may be necessary. In earlier versions, users were advised to perform a downgrade, which was not user-friendly and had several pitfalls. Downgrading is not supported as it has many potential downsides. With this Werk, `omd update` is better able to deal with these situations. `omd update` will show the message ``` Completed verifying site configuration. Your site now has version {target version}. ``` If the update is aborted before this message is shown, then the site is restored to it's previous state. This includes selecting the `abort` option, unexpected internal errors, or aborting the update using CTRL-C.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: multi-worker.md

In specific scenarios, a fluentd with a single worker instance cannot process and forward the high amount of logs produced on clusters. This can lead to fluentd Pods not accepting additional traffic from fluent-bits and fluent-bits suffering under Backpressure. In the end, both fluentd and fluent-bit Pods might run into their memory limits and get restarted by Kubernetes. Enabling multiple worker processes per fluentd Pod will increase the performance of this component, so it is recommended to use a multi-worker approach in environments with high log volume. Additionally the official might be helpful. When enabling the multi-worker setup, it is recommended to ensure the following things: Place the fluentds on separate Nodes Increase the compute and memory resources Do not use specific filter plugins detectExceptions Also scale To ensure that the fluentd Pods have enough resources, a common approach is to use specific Nodes for the fluentds and to reserve enough computing and memory resources. A new nodePool should be created with a specific label and a taint. Ideally, the nodeType is compute-optimized. It could look like the following: ```yaml apiVersion: v1 kind: Node metadata: labels: type: cpu name: node1 spec: taints: effect: NoSchedule key: type value: cpu ``` The corresponding setting in the FluentdSpec looks like follows: ```yaml nodeSelector: type: cpu tolerations: effect: NoSchedule key: type operator: Equal value: cpu ``` Additionaly we will have to increase the resources that are requested by the fluentd Pods. In the default setting they use following requests and limits: ```yaml resources: limits: cpu: 1 memory: 400M requests: cpu: 500m memory: 100M ``` In this short walkthrough, we will increase the fluentd workers from `1` to `5`. Therefore, we will multiply the requests and limits with factor 5 to ensure enough resources are reserved. Additionally, we will set requests and limits to the same values to ensure that the fluentd Pods are not affected by other workloads on the Node. This is, in general, a good practice. It is necessary to set the following settings in the FluentdSpec: ```yaml resources: limits: cpu: 5 memory: 2G requests: cpu: 5 memory: 2G ``` Lastly we can increase the number of fluentd-workers that are used per Pod and set the rootDir field. It is important that those two settings are changed together otherwise the fluentd process will not work correctly: ```yaml workers: 5 rootDir: /buffers ``` The full configuration of the Logging resource looks like follows: ```yaml fluentd: nodeSelector: type: cpu tolerations: effect: NoSchedule key: type operator: Equal value: cpu resources: limits: cpu: 5 memory: 2G requests: cpu: 5 memory: 2G workers: 5 rootDir: /buffers ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16799.md

key | value | date | 2024-04-19T10:57:49+00:00 version | 2.4.0b1 class | fix edition | cee component | metrics level | 1 compatible | yes When configuring the metrics rendered in custom and forecast graphs, users have to select a host, a service and a metric. Previously, if any of these fields were missing, the Checkmk UI displayed the message "Cannot calculate graph recipes" and an uninformative traceback. As of this werk, the UI instead displays a descriptive error message.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-dashboard_screen_delete.md

category: DashboardScreen apiurl: '/api/v1/dashboard/screen/:screen_id' title: 'Delete a DashboardScreen' type: 'DELETE' sample_doc: 'dashboard.html' layout: default Required ```Status: 200``` ```{"message":"ok"} ``` For errors responses, see the .