cwielenb/CNCF-Dataset huggingface dataset:
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: scaling.md

First, the . Many providers already have this configured, so does `kind`. Next, Prometheus and the have to be installed. The default Prometheus address values will probably have to be adjusted (set `prometheus.url`, `prometheus.port` and `prometheus.path` to the appropriate values). You might also want to install to access basic metrics. PRO TIP: If the `metrics-server` pod's readiness fails with HTTP 500, try adding the `--kubelet-insecure-tls` flag to the container. If the necessary custom metric is not available in Prometheus, a Prometheus recording rule should be defined: ```yaml groups: name: my-logging-hpa.rules rules: expr: (nodefilesystemsizebytes{container="buffer-metrics-sidecar",mountpoint="/buffers"}-nodefilesystemfreebytes{container="buffer-metrics-sidecar",mountpoint="/buffers"})/nodefilesystemsize_bytes{container="buffer-metrics-sidecar",mountpoint="/buffers"} record: bufferspaceusage_ratio ``` Alternatively, the derived metric could be defined as a config rule in the Prometheus Adapter's config map. Next, if it's not already installed, install the logging-operator and configure a logging with at least one flow. Make sure that the logging resource has buffer volume metrics monitoring enabled under `spec.fluentd`: ```yaml bufferVolumeMetrics: serviceMonitor: true ``` You can check that the custom metric is available with: ```sh kubectl get --raw '/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/*/bufferspaceusage_ratio' ``` The replica count of the stateful set is enforced by the logging-operator only if it is explicitly set in the logging resource's replica count. If it's not set explicitly in the logging resource, then the logging operator allows managing it from the outside. To allow for HPA to control the replica count of the statefulset simply avoid setting the replica count through the logging resource. Finally, the HPA resource must be created. ```yaml apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: one-eye-fluentd spec: scaleTargetRef: apiVersion: apps/v1 kind: StatefulSet name: one-eye-fluentd minReplicas: 1 maxReplicas: 10 metrics: type: Pods pods: metric: name: bufferspaceusage_ratio target: type: AverageValue averageValue: 800m ``` This example tries to keep the average buffer volume usage of Fluentd instances at 80%.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: configure-resource-utilization-based-ingester-read-path-limiting.md

description: Learn how to configure Grafana Mimir for resource utilization based ingester read path limiting. menuTitle: Resource utilization based ingester read path limiting title: Configure resource utilization based ingester read path limiting weight: 120 Grafana Mimir allows you to configure limits for CPU and/or memory utilization, which cause the ingester to reject incoming read requests while either of the limits is reached. The idea is to prevent expensive queries from interrupting the write path, ensuring a minimum of headroom for the latter. The ingester's model of memory utilization corresponds to the Go heap size, which it tracks, along with a sliding window average of the process' CPU utilization. The process' CPU utilization and Go memory heap size are sampled every second, and a sliding window average is taken of the CPU utilization. If either is greater than or equal to the corresponding configured limit, ingester read requests get rejected with HTTP status code 503 (Service Unavailable), until utilization levels are below respective limits again. Whenever the ingester rejects a read request due to utilization based limiting, it increments the `cortexingesterutilizationlimitedreadrequeststotal` counter metric. CPU and memory utilization are also tracked, via the `cortexingesterutilizationlimitercurrentcpuload` and `cortexingesterutilizationlimitercurrentmemoryusage_bytes` gauge metrics respectively. To configure resource utilization based ingester read path limiting, you may use the following flags: `-ingester.read-path-cpu-utilization-limit`: CPU utilization limit, as CPU cores `-ingester.read-path-memory-utilization-limit`: Memory limit, in bytes Alternatively, you may configure the ingester via YAML, as in the following snippet: ```yaml ingester: readpathcpuutilizationlimit: 0.8 readpathmemoryutilizationlimit: 20132659200 ```
Project: Flipt (Observability and Analysis / Feature Flagging)
File: DEPRECATIONS.md

This page is used to list deprecation notices for Flipt. Deprecated configuration options will be removed after ~6 months from the time they were deprecated. Deprecated API endpoints, fields and objects will be removed after ~1 year from the time they were deprecated. <!-- Template for new deprecations: since Description. === Before ``` yaml foo: bar ``` === After ``` yaml foo: bar ``` --> since This module is no longer supported. OpenTelemetry dropped support for Jaeger exporter in July 2023. Jaeger officially accepts and recommends using OTLP. since `offset` has been deprecated in favor of `pagetoken`/`nextpage_token` for `ListFlagRequest`, `ListSegmentRequest` and `ListRuleRequest`. See: . The following options were deprecated in the past and were already removed. deprecated in removed in deprecated in removed in deprecated in removed in deprecated in removed in deprecated in removed in
Project: Grafana Loki (Observability and Analysis / Observability)
File: document-metrics-configurations-changes.md

title: Document metrics and configurations changes description: Document metrics and configurations changes Any metrics and configurations that are removed or modified need to be documented in the upgrade guide. Configurations whose default values changed should also be documented in the upgrade guide. All the steps are performed on `release-VERSION_PREFIX` branch. Check which configs changed, including whose default values changed. ``` $ OLD_VERSION=X.Y.Z ./tools/diff-config.sh ``` Record configurations that are modified (either renamed or had its default value changed) in the . Check if any metrics have changed. ``` $ OLD_VERSION=X.Y.Z ./tools/diff-metrics.sh ``` Record metrics whose names have been modified in the .
Project: Netdata (Observability and Analysis / Observability)
File: httpcheck_web_service_slow.md

The Netdata Agent monitors your HTTP endpoints. You can specify endpoints the Agent will monitor in the Agent's Go module under `go.d/httpcheck.conf`. The Agent calculates the average response time for every HTTP request made to the endpoint being monitored per hour. The Agent also calculates the average response time in a 3-min window. The Netdata Agent compares these two (average) values. If there is a significant increase in 3-min average, then it will trigger a warning alert when the response time 3-min average is at least twice as much as 1-hour average. The alert will escalate to critical when the response time 3-min average reaches three times the average amount per hour. To troubleshoot this issue, check for: Network congestion in your system's network and/or in the remote endpoint's network. If the endpoint is managed by you, then check the system load.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: how-to-update-the-build-image.md

The build image currently can only be updated by a Grafana Mimir maintainer. If you're not a maintainer you can still open a PR with the changes, asking a maintainer to assist you in publishing the updated image. The automatic procedure is as follows: Update `mimir-build-image/Dockerfile` and create a pull request. When the PR is changed to ready to review, wait for CI to add an additional commit to your pull request, which updates `LATESTBUILDIMAGE_TAG` in the Makefile. Merge the pull request. The manual procedure is: Update `mimir-build-image/Dockerfile` on a new branch. Note: the resulting images have the tag name derived from the branch name. Make sure to have . Docker Desktop and major distributions have it in the docker package. On Linux you'll need some extra qemu packages as well: `sudo apt-get install qemu qemu-user-static binfmt-support debootstrap`. And set up docker buildx: `docker buildx create --name armBuilder ; docker buildx use armBuilder`. Build and publish the image by using `make push-multiarch-build-image`. This will build and push multiplatform docker image (for Linux/amd64 and Linux/arm64). Replace the image tag in Makefile (variable `LATESTBUILDIMAGE_TAG`). Open a PR and make sure the CI with the new build image passes
Project: Netdata (Observability and Analysis / Observability)
File: httpcheck_web_service_up.md

The `httpcheckwebservice_up` alert monitors the liveness status of an HTTP endpoint by checking its response over the past minute. If the success percentage is below 75%, this alert will trigger, indicating that the web service may be experiencing issues. An HTTP endpoint is like a door where clients make requests to access web services or APIs. The liveness status reveals whether the service is available and responding to client requests. Ideally, this success percentage should be near 100%, indicating that the endpoint is consistently accessible. Check logs for any errors or warnings related to the web server or application. Depending on your web server or application, look for log files that may provide insights into the causes of the issues. Some common log locations are: Apache: `/var/log/apache2/` Nginx: `/var/log/nginx/` Node.js: Check your application-specific log location. Examine server resources such as CPU, memory, and disk usage. High resource usage can cause web services to become slow or unresponsive. Use system monitoring tools like `top`, `htop`, or `free` to check the resource usage. Test the HTTP endpoint manually. You can use tools like `curl`, `wget`, or `httpie` to send requests to the HTTP endpoint and inspect the responses. Examine the response codes, headers, and contents to spot any problems. Example using `curl`: ``` curl -I http://example.com/some/endpoint ``` Check for network issues between the monitoring agent and the HTTP endpoint. Use tools like `ping`, `traceroute`, or `mtr` to check for network latency or packet loss between the monitoring agent and the HTTP endpoint. Review the web server or application configuration. Ensure the web server and application configurations are correct and not causing issues. Look for misconfigurations, incorrect settings, or other issues that may affect the liveness of the HTTP endpoint.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: halodoc.md

is a secure health-tech platform with a mission to simplifying access to healthcare by connecting millions of patients with licensed doctors, insurance, labs, and pharmacies in one simple mobile application. Halodocs innovative technology, nimble services, and patient focus enable a host of solutions including 24/7 doctor tele consultation via chat, voice or video; medicine purchase & delivery; lab services at home; and strong customer support. Halodoc is the 2018 Forbes Indonesia Choice Award winner and Galen Growths 2018 Most Innovative HealthTech Startup in Asia, a testimony to a team of compassionate, innovative, trustworthy and agile people who take ownership of their work in building the most trusted digital healthcare company. We wanted a tool that we could leverage to test the resiliency of multi k8s cluster workloads in a private cloud, after evaluating different tools of similar flavour, we wanted to exercise our chaos experiments using Litmus, as it has the following benefits. It is designed for Kubernetes workload It has the wide range of chaos experiments to perform on k8s workload and Infrastructure It has litmus portal as control plane to target chaos experiments against multiple k8s cluster within our organisation. It has prometheus integration, able to see in litmus portal dashboard about how each of the workflow chaos experiments perform. It fits into our gitops flow to enable end to end automation. At Halodoc we use Litmus to validate the resiliency of our private aws managed eks by covering the following areas. Testing resiliency of Control plane Kubernetes Infrastructure Validating the HA of different control plane services Target SRE tools at k8s clusters, benchmark it based on several parameters. Litmus has has a wide variety of chaos experiments for Kubernetes workload and Infrastructure and provides a very easy way for end-to-end automation of resiliency test cases.
Project: Vector (Observability and Analysis / Observability)
File: 2022-07-07-secrets-management.md

date: "2022-07-07" title: "Load secrets into Vector" description: "A new mechanism to load secrets into Vector from an external process" authors: ["jszwedko"] pr_numbers: [11985] release: "0.23.0" hideonrelease_notes: false badges: type: enhancement With this release, we have introduced a new mechanism to load secrets securely into Vector by calling an external process. This can be used, for example, to integrate with a service like to provide credentials. Previously the preferred mechanism was injection via environment variables, but there are some security concerns as these values can be read if a user on a host has access to read from the `/proc` filesystem for the Vector process. A secret backend can be configured like this: ```toml [secret.backend_1] type = "exec" # exec is the only supported backend as of writing command = ["/path/to/cmd1"] ``` You can then specify where secrets should be read via `SECRET[<backend name>.<secret name>]` in the config like: ```toml [sources.mysourceid] type = "aws_sqs" region = "us-east-1" queue_url = "https://sqs.us-east-2.amazonaws.com/123456789012/MyQueue" auth.accesskeyid = "SECRET[backend1.awsaccesskeyid]" auth.secretaccesskey = "SECRET[backend1.awssecretaccesskey]" ``` Here `auth.accesskeyid` and `auth.secretaccesskey` will use secrets provided by the `backend_1` secret backend. When Vector starts, it will call the configured secret backend command, here `/path/to/cmd1`, with the needed secrets provided as JSON on stdin: ```json {"version": "1.0", "secrets": ["awsaccesskeyid", "awssecretaccesskey"]} ``` The command is then expected to write the secrets to stdout as JSON in the following format: ```json { "awsaccesskey_id": {"value": "AKIAIOSFODNN7EXAMPLE", "error": null}, "awssecretaccess_key": {"value": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY", "error": null} } ``` Vector will then use the returned values when loading the configuration. If an `error` is returned, or the command exits non-zero, Vector will log any errors and stop. See the for additional details.
Project: Checkmk (Observability and Analysis / Observability)
File: 16416.md

key | value | date | 2024-03-28T08:38:12+00:00 version | 2.4.0b1 class | fix edition | cre component | omd level | 1 compatible | yes On SUSE Linux Enterprise Server 15 systems, the `scp` command could crash with ``` /usr/bin/ssh: symbol lookup error: /usr/bin/ssh: undefined symbol: EVPKDFCTXfree, version OPENSSL111d lost connection ``` when executed as a site user.
Project: Grafana Loki (Observability and Analysis / Observability)
File: release-loki-build-image.md

title: Releasing Loki Build Image description: Releasing Loki Build Image aliases: ../../maintaining/release-loki-build-image/ The is the Docker image used to run tests and build Grafana Loki binaries in CI. The build and publish process of the image is triggered upon a merge to `main` if any changes were made in the folder `./loki-build-image/`. To build and use the `loki-build-image`: Create a branch with the desired changes to the Dockerfile. Update the version tag of the `loki-build-image` pipeline defined in `.drone/drone.jsonnet` (search for `pipeline('loki-build-image')`) to a new version number (try to follow semver). Run `DRONESERVER=https://drone.grafana.net/ DRONETOKEN=<token> make drone` and commit the changes to the same branch. The `<token>` is your personal drone token, which can be found by navigating to https://drone.grafana.net/account. Create a PR. Once approved and merged to `main`, the image with the new version is built and published. {{% admonition type="note" %}} Keep an eye on https://drone.grafana.net/grafana/loki for the build after merging (). {{% /admonition %}} Create a branch. Update the `BUILDIMAGEVERSION` variable in the `Makefile`. Run `loki-build-image/version-updater.sh <new-version>` to update all the references. Run `DRONESERVER=https://drone.grafana.net/ DRONETOKEN=<token> make drone` to update the Drone config to use the new build image. Create a new PR.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-admin_change_role.md

category: Admin apiurl: '/api/v1/admin/changeuserrole' title: "Change User's role" type: 'PUT' sample_doc: 'admin.html' layout: default Required `Admin` usage admin: accept option: yes no ```{"user_id": 14, "admin": "yes"}``` ```Status: 200``` ```{"message":"user role update sccuessful, affect row: 1"}```
Project: Vector (Observability and Analysis / Observability)
File: 2020-01-12-use-comma-delim-server-list-instead-of-an-array.md

date: "2020-07-13" title: "Use comma delim server list in `kafka` sink" description: "This change achieve consistency with our `kafka` source and other Kafka clients" authors: ["binarylogic"] pr_numbers: [1502] release: "0.7.0" hideonrelease_notes: false badges: type: "breaking change" domains: ["sinks"] sinks: ["kafka"] The `kafka` sink field `bootstrap_servers` has been changed from an array to a string, expecting a comma separated list of bootstrap servers similar to the `kafka` source. ```diff title="vector.toml" [sinks.mysinkid] type = "kafka" inputs = ["my-source-id"] bootstrap_servers = ["10.14.22.123:9092", "10.14.23.332:9092"] bootstrap_servers = "10.14.22.123:9092,10.14.23.332:9092" ```
Project: Grafana Tempo (Observability and Analysis / Observability)
File: v1-4.md

title: Version 1.4 release notes menuTitle: V1.4 description: Release notes for Grafana Tempo 1.4 weight: 80 The Tempo team is excited to announce the release of Tempo 1.4. Server-side metrics As the headline feature for Tempo 1.4, generate metrics from your traces, for advanced insight into your application's performance over time. Start and end time `start` and `end` parameters were added to the `/api/traces/{traceID}` endpoint. This allows more efficient searches by only querying a subset of blocks on the backend. Protect instances from very large traces Additional protection against large traces has been added. These features all key off the existing `maxbytesper_trace` configuration parameter. and Hedge everything Improve backend search throughput Tempo using our favorite solution: hedging. ``` querier: search: externalhedgerequests_at: 5s externalhedgerequestsupto: 3 ``` When upgrading to Tempo v1.4, be aware of these breaking changes: A new ingestion endpoint was added to support faster search and proper start/end times on blocks. Roll out all ingesters before rolling the distributors to prevent downtime. Also, during this period, the ingesters will use considerably more resources and should be scaled up, or incoming traffic should be heavily throttled. Once all distributors and ingesters have rolled, performance will return to normal. Internally, we have observed ~1.5x CPU load on the ingesters during the rollout. A few querier options were moved while adding hedging to external endpoints. ```yaml querier: searchquerytimeout: 30s searchexternalendpoints: [] searchpreferself: 2 ``` was relocated to ```yaml querier: search: query_timeout: 30s prefer_self: 2 external_endpoints: [] ``` Updated vulture testing of full backend search, and as a result, dropped the CLI parameter `tempo-search-retention-duration`. Correct the handling of Azure "Blob Not Found" errors. Correct block start and end times to be based on actual trace start/end times, instead of on trace ingestion times. Eliminate a data race and ingester crash during search by trace ID. Eliminate spurious "failed to mark block compacted during retention" errors. Eliminate an error with the message "Writer is closed" by resetting the compression writer correctly on the error path. Metrics-generator: don't inject X-Scope-OrgID header for single-tenant setups. Compactor: populate `compactionobjectscombinedtotal` and `tempodiscardedspanstotal{reason="tracetoolargetocompact"}` metrics again. Distributor: prevent panics when concurrently calling `shutdown` to forwarder's queueManager.
Project: Checkmk (Observability and Analysis / Observability)
File: 16665.md

key | value | date | 2024-04-03T12:32:28+00:00 version | 2.4.0b1 class | fix edition | cre component | multisite level | 1 compatible | yes Accessing a built-in dashboard after overriding it with a custom dashboard could cause certain dashlets to crash. For example, you could access the built-in dashboard by clicking the link in Customize > Dashboards > Built-in. Another way to access the built-in dashboard is for example by having a bookmark to it. Now this crash no longer occurs and all dashlets render correctly.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-5-1.md

hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 8.5.1 <!-- Auto generated by update changelog github action --> Azure Monitor: Fix space character encoding for metrics query link to Azure Portal. , CloudWatch: Prevent log groups from being removed on query change. , Cloudwatch: Fix template variables in variable queries. , Explore: Prevent direct access to explore if disabled via feature toggle. , InfluxDB: Fixes invalid no data alerts. , Navigation: Prevent navbar briefly showing on login. , Plugins Catalog: Fix styling of hyperlinks. , Table: Fix filter crashes table. , TimeSeries: Properly stack series with missing datapoints. ,
Project: Netdata (Observability and Analysis / Observability)
File: 1m_successful.md

This alert is triggered when the percentage of successful HTTP requests (1xx, 2xx, 304, 401 response codes) within the last minute falls below a certain threshold. A warning state occurs when the success rate is below 85%, and a critical state occurs when it falls below 75%. This alert can indicate a malfunction in your web server's services, malicious activity towards your website, or broken links. Analyze response codes: Identify the specific HTTP response codes your web server is sending to clients. Use the Netdata dashboard and inspect the `detailedresponsecodes` chart for your web server to track the error codes being sent. Check server logs: Review the web server logs to identify any issues, patterns, or errors causing the decrease in successful requests. Investigate any unusual or unexpected response codes. Inspect application logs: Check the logs of applications running on your web server for any errors or issues that might be affecting the success rate of HTTP requests. Verify server resources: Ensure your server has adequate resources (CPU, RAM, disk space) to handle the workload, as resource limitations can impact the success rate of HTTP requests. Review server configuration: Check your web server's configuration for any misconfigurations, incorrect permissions, or improper settings that may be causing the issue. Monitor security: Look for signs of malicious activity, such as a high number of requests from a specific IP address or a sudden spike in requests. Implement security measures, such as rate limiting, IP blocking, or Web Application Firewalls (WAF), if necessary.