cwielenb/CNCF-Dataset huggingface dataset:
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: scheduled-flags.md

:::tip Scheduled Flags are part of our Scale-Up and Enterprise plans. ::: You can use Scheduled Flags to queue up changes to Flags to be modified automatically in a future point in time. You can create a Scheduled Flag change in 1 of two ways: As part of a Change Request. If you are not enforcing Change Requests, you can schedule the Flag change when modifying a Flag. Once an Environment is configured with Change Requests enabled, attempting to change a flag value will prompt you to create a new Change Request. You will need to provide: The title of the Change Request Optionally a description of the reason for the Change Request The Date and Time that you want the flag change to take effect If the Environment you are working with does not have Change Requests enabled, you can create a Scheduled Flag Change directly when editing the Flag. Scheduled Flags pending go live will appear in the Change Request area. Once the Schedule of the flag has passed the Scheduled Flag will move to the "Closed" list.
Project: M3 (Observability and Analysis / Observability)
File: operator.md

title: "M3DB Operator" menuTitle: "M3DB Operator" weight: 1 chapter: true This documentation is for the M3DB which can run and operate on Kubernetes. For more background on the M3DB operator, see our on its origins and usage at Uber. The M3DB operator aims to automate everyday tasks around managing M3DB. Specifically, it aims to automate: Creating M3DB clusters Destroying M3DB clusters Expanding clusters (adding instances) Shrinking clusters (removing instances) Replacing failed instances It explicitly does not try to automate every single edge case a user may ever run into. For example, it does not aim to automate disaster recovery if an entire cluster is taken down. Such use cases may still require human intervention, but the operator will aim to not conflict with such operations a human may have to take on a cluster. Generally speaking, the operator's philosophy is if it would be unclear to a human what action to take, we will not try to guess.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: caching.md

title: Improve performance with caching menuTitle: Improve performance with caching description: Learn how to improve query performance by using caching. weight: 65 Caching is mainly used to improve query performance by storing bloom filters of all backend blocks which are accessed on every query. Tempo uses an external cache to improve query performance. The supported implementations are and . Memcached is one of the cache implementations supported by Tempo. It is used by default in the Tanka and Helm examples, see . As a cluster grows in size, the number of instances of Tempo connecting to the cache servers also increases. By default, Memcached has a connection limit of 1024. If this limit is surpassed new connections are refused. This is resolved by increasing the connection limit of Memcached. These errors can be observed using the `tempomemcacherequestdurationseconds_count` metric. For example, by using the following query: ```promql sum by (status_code) ( rate(tempomemcacherequestdurationsecondscount{}[$rateinterval]) ) ``` This metric is also shown in (the left panel): <p align="center"><img src="../cachingmemcachedconnection_limit.png" alt="QPS and latency of requests to memcached"></p> Note that the already open connections continue to function, just new connections are refused. Additionally, Memcached will log the following errors when it can't accept any new requests: ``` accept4(): No file descriptors available Too many open connections accept4(): No file descriptors available Too many open connections ``` When using the , the number of open connections can be observed at `memcachedcurrentconnections`. Tempo querier accesses bloom filters of all blocks while searching for a trace. This essentially mandates the size of cache to be at-least the total size of the bloom filters (the working set) . However, in larger deployments, the working set might be larger than the desired size of cache. When that happens, eviction rates on the cache grow high, and hit rate drop. Not nice! Tempo provides two config parameters in order to filter down on the items stored in cache. ``` [cachemincompaction_level: <int>] [cachemaxblock_age: <duration>] ``` Using a combination of these config options, we can narrow down on which bloom filters are cached, thereby reducing our cache eviction rate, and increasing our cache hit rate. Nice! In order to decide the values of these config parameters, you can use a cache summary command in the that prints a summary of bloom filter shards per day and per compaction level. The result looks something like this: <p align="center"><img src="../cache-summary.png" alt="Cache summary"></p> The above image shows the bloom filter shards over 14 days and 6 compaction levels. This can be used to decide the above configuration parameters.
Project: Elastic (Observability and Analysis / Observability)
File: log10.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Returns the logarithm of a value to base 10. The input can be any numeric value, the return value is always a double. Logs of 0 and negative numbers return `null` as well as a warning. ``` ROW d = 1000.0 | EVAL s = LOG10(d) ```
Project: Netdata (Observability and Analysis / Observability)
File: 1hour_memory_hw_corrupted.md

The Linux kernel keeps track of the system memory state. You can find the actual values it tracks in the under the `/proc/meminfo` subsection. One of the values that the kernel reports is the `HardwareCorrupted` , which is the amount of memory, in kibibytes (1024 bytes), with physical memory corruption problems, identified by the hardware and set aside by the kernel so it does not get used. The Netdata Agent monitors this value. This alert indicates that the memory is corrupted due to a hardware failure. While primarily the error may be due to a failing RAM chip, it can also be caused by incorrect seating or improper contact between the socket and memory module. Most of the time uncorrectable errors will make your system reboot/shutdown in a state of panic. If not, that means that your tolerance level is high enough to not make the system go into panic. You must identify the defective module immediately. `memtester` is a userspace utility for testing the memory subsystem for faults. You may also receive this error as a result of incorrect seating or improper contact between the socket and RAM module. Check both before consider replacing the RAM module.
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: qos-enhanced-bypass-cpuset-management.md

title: "Enhanced bypass cpuset management capability" description: "Enhanced bypass cpuset management capability" weight: 23 Kubelet supports the static CPU manager strategy. When the guaranteed pod runs on the node, kebelet will allocate the specified dedicated CPU for the pod, which cannot be occupied by other processes. This ensures the CPU monopoly of the guaranteed pod, but also causes the low utilization of CPU and nodes, resulting in a certain waste. Crane agent provides a new strategy for cpuset management, allowing pod and other pod to share CPU. When it specifies CPU binding core, it can make use of the advantages of less context switching and higher cache affinity of binding core, and also allow other workload to deploy and share, so as to improve resource utilization. Three types of pod cpuset are provided: Exclusive: after binding the core, other containers can no longer use the CPU and monopolize the CPU Share: other containers can use the CPU after binding the core None: select the CPU that is not occupied by the container of exclusive pod, can use the binding core of share type Share type binding strategy can make use of the advantages of less context switching and higher cache affinity, and can also be shared by other workload deployments to improve resource utilization Relax the restrictions on binding cores in kubelet Originally, it was required that the CPU limit of all containers be equal to the CPU request. Here, it is only required that the CPU limit of any container be greater than or equal to 1 and equal to the CPU request to set the binding core for the container Support modifying the cpuset policy of pod during the running of pod, which will take effect immediately The CPU manager policy of pod is converted from none to share and from exclusive to share without restart How to use: Set the cpuset manager of kubelet to "None" Set CPU manager policy through pod annotation `qos.gocrane.io/cpu-manager: none/exclusive/share` ```yaml apiVersion: v1 kind: Pod metadata: annotations: qos.gocrane.io/cpu-manager: none/exclusive/share ```
Project: Vector (Observability and Analysis / Observability)
File: 2020-01-07-prometheus-source.md

date: "2020-03-31" title: "New Prometheus Source" description: "Scrape prometheus metrics with Vector" authors: ["binarylogic"] pr_numbers: [1264] release: "0.7.0" hideonrelease_notes: false badges: type: "new feature" domains: ["sources"] sources: ["prometheus"] aliases: ["/blog/prometheus-source"] We love and so we've added a to let you send Prometheus format metrics anywhere you like. <!--more--> This was an important feat for Vector because it required us to mature our metrics data model and tested our interoperability between metrics sources. To use it simply add the source config and point it towards the hosts you wish to scrape: ```toml [sources.mysourceid] type = "prometheus_scrape" hosts = ["http://localhost:9090"] scrapeintervalsecs = 1 ``` For more guidance get on the . We believe the most common use cases for this source will be backups and migration, if you have an interesting use case we'd .
Project: SkyWalking (Observability and Analysis / Observability)
File: backend-storage.md

The SkyWalking storage is pluggable. We have provided the following storage solutions, which allow you to easily use one of them by specifying it as the `selector` in `application.yml` ```yaml storage: selector: ${SW_STORAGE:elasticsearch} ``` Natively supported storage: This is recommended to use for medium scale deployments from 0.6 until 1.0. BanyanDB is going to be our next generation storage solution. It has shown high potential performance improvement. Less than 50% CPU usage and 50% memory usage with 40% disk volume compared to Elasticsearch in the same scale. We are looking for early adoption. Please contact us through slack channels if you are interested in using BanyanDB. H2 is the default storage option in the distribution package. It is recommended to use H2 for testing and development ONLY. MySQL and PostgreSQL are recommended for production environments for medium scale deployments, especially for low trace and log sampling rate. Some of their compatible databases may support larger scale better, such as TiDB and AWS Aurora. Elasticsearch and OpenSearch are recommended for production environments, specially for large scale deployments. OpenSearch derived from Elasticsearch 7.10.2 and iterate by its own roadmap.
Project: Cortex (Observability and Analysis / Observability)
File: MAINTAINERS.md

This page lists all active maintainers of this repository. If you were a maintainer and would like to add your name to the Emeritus list, please send us a PR. See for governance guidelines and how to become a maintainer. See for general contribution guidelines. , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: scheduled.md

Scheduling introduces the ability for users to changes their flags for future points in time. While this sounds deceptively straightforward, it unlocks the potential for users to create complex release strategies by scheduling the incremental steps in advance. For example, you may want to turn a feature ON for internal testing tomorrow and then enable it for your beta user segment four days later. ```yaml linenums="1" hl_lines="6-13" scheduled-flag: true: "B" false: "A" default: "Default" rollout: scheduled: steps: date: 2020-04-10T00:00:00.10+02:00 rule: beta eq "true" percentage: 100 date: 2022-05-12T15:36:00.10+02:00 rule: beta eq "false" ``` ```json { "scheduled-flag": { "true": "B", "false": "A", "default": "Default", "rollout": { "scheduled": { "steps": [ { "date": "2020-04-09T22:00:00.100Z", "rule": "beta eq \"true\"", "percentage": 100 }, { "date": "2022-05-12T13:36:00.100Z", "rule": "beta eq \"false\"" } ] } } } } ``` ```toml [scheduled-flag] true = "B" false = "A" default = "Default" [scheduled-flag.rollout] [scheduled-flag.rollout.scheduled] [[scheduled-flag.rollout.scheduled.steps]] date = 2020-04-09T22:00:00.100Z rule = "beta eq \"true\"" percentage = 100.0 [[scheduled-flag.rollout.scheduled.steps]] date = 2022-05-12T13:36:00.100Z rule = "beta eq \"false\"" ``` :::info You can change any fields that are available on your flag. Since your configuration has not been changed manually, it does not trigger any notifier. ::: | Field | Description | ||| |`steps`| The only mandatory field in a step is the `date`.<br/>If no date is provided the step will be skipped.<br/><br/>The other attributes of your `step` are what you want to update your flag, so every field available in the can be updated.<br/>The new value in a field will override the existing one. |
Project: Checkmk (Observability and Analysis / Observability)
File: 16511.md

key | value | date | 2024-02-21T13:39:02+00:00 version | 2.4.0b1 class | fix edition | cee component | multisite level | 1 compatible | yes cmcdump would not handle semicolons correctly, leading to garbled or incomplete output and spurious errors. This has been fixed by escaping semicolons in cmcdump and unescaping them in livestatus.
Project: Checkmk (Observability and Analysis / Observability)
File: 16680.md

key | value | date | 2024-04-15T06:44:00+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | no This change is only relevant for plugin developers. The available topics for rule specs have changed: added: `SYNTHETIC_MONITORING` removed: `AGENT_PLUGINS`
Project: Micrometer (Observability and Analysis / Observability)
File: enhancement-request.md

name: Enhancement request about: Request an enhancement for Micrometer title: '' labels: 'waiting-for-triage' assignees: '' Please describe the feature request. A clear and concise description of what you would like to be able to do with Micrometer and cannot currently. Rationale Please help us understand the rationale (why) behind the enhancement request. Additional context Add any other context about the feature request here, e.g. related issues, prior art.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: configure-redis-cache.md

title: "Configure Redis cache" menuTitle: "Redis cache" description: "Learn how to configure Grafana Mimir to use external Redis as cache" Besides support for Memcached, Mimir also supports Redis for the chunks-cache, index-cache, results-cache and metadata-cache. To use Redis, deploy Redis instances, disable the built-in Memcached configuration flag in values.yaml of `mimir-distributed` Helm chart, and then configure Mimir to use Redis. To disable Memcached, remove any `chunks-cache`, `index-cache`, `metadata-cache` and `results-cache` configuration from your Helm `values.yaml` file. Alternatively, explicitly disable each of the Memcached instances by setting `enabled` to `false`: ```yaml chunks-cache: enabled: false index-cache: enabled: false metadata-cache: enabled: false results-cache: enabled: false ``` Next, configure Mimir to connect to Redis using `structuredConfig`. Refer to [the configuration parameters reference] for Redis connection configuration options. For example: ```yaml mimir: structuredConfig: blocks_storage: bucket_store: chunks_cache: backend: redis redis: endpoint: <redis-url>:6379 index_cache: backend: redis redis: endpoint: <redis-url>:6379 metadata_cache: backend: redis redis: endpoint: <redis-url>:6379 frontend: cache_results: true results_cache: backend: redis redis: endpoint: <redis-url>:6379 ``` {{% docs/reference %}} {{% /docs/reference %}}
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: getting_started.md

sidebar_position: 21 description: Getting started with the relay proxy. Before starting your relay proxy you will need to create a minimal configuration file. ```yaml retriever: kind: http url: https://raw.githubusercontent.com/thomaspoignant/go-feature-flag/main/examples/retriever_file/flags.yaml ``` After that you can launch the relay proxy by using this command: ```shell go-feature-flag-relay-proxy --config=/path/to/your/configfile ``` The relay proxy will read the configuration file and retrieve all the flags. After that you can use all the available endpoints (see **Service endpoints** section) and get the variations for your users. A common way to run go-feature-flag relay proxy is to use the Docker Container. An image is available on docker Hub . You can also run it as a service in your application following the Installation section. To configure the relay proxy you should provide a configuration file when launching the instance. The easiest way to provide the file is to use the option `--config=/pathtoyour_file.yaml`. But if you don't provide this option, the relay proxy will look in these folders if a file named `goff-proxy.yaml` is available. current folder `/goff/` `/etc/opt/goff/` To learn how to configure the relay proxy, read . To export the data you can use all the capabilities of `go-feature-flag` SDK. To configure it please refer to the of the configuration. The Relay Proxy defines many HTTP/HTTPS endpoints. Most of these are proxies for GO Feature Flag services, to be used by SDKs that connect to the Relay Proxy. Others are specific to the Relay Proxy, such as for monitoring its status. Please refer to to get the full details of what exists in our REST API.
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_queue_message_expired.md

This alert is related to VerneMQ, a scalable and open-source MQTT broker. The `vernemqqueuemessage_expired` alert indicates that there is a high number of expired messages that could not be delivered in the last minute. In MQTT, messages are kept in queues until they are delivered to their respective subscribers. Sometimes, messages might have a specific lifespan given by the Time to Live (TTL) attribute, and if they are not delivered within this time, they expire. Expired messages are removed from the queue and are not delivered to subscribers. This usually means that clients are unable to process the incoming messages fast enough, putting the VerneMQ system under stress. Check VerneMQ status: Use the `vernemq` command along with the `vmq-admin` tool to monitor the status of your VerneMQ broker: ``` sudo vmq-admin cluster show ``` Analyze the output to make sure that the cluster is up and running without issues. Check the message rate and throughput: You can use the `vmq-admin metrics show` command to display key metrics related to your VerneMQ cluster: ``` sudo vmq-admin metrics show ``` Analyze the output and identify any sudden increase in the message rate or unusual rate of message expiration. Identify slow or malfunctioning clients: VerneMQ provides a command to list all clients connected to the cluster. You can use the following command to identify slow or malfunctioning clients: ``` sudo vmq-admin session show ``` Check the output for clients who have a high amount of queue delay, low queued messages, or are not receiving messages properly. Optimize client connections: Increasing the message TTL or decreasing the message rate can help decrease the number of expired messages. Adjust the client settings accordingly, ensuring they match the application requirements. Ensure proper resource allocation: Check whether the VerneMQ broker has enough resources by monitoring CPU, memory, and disk usage using tools like `top`1, `vmstat`, or `iotop`. Check VerneMQ logs: VerneMQ logs can provide valuable insight into the underlying issue. Check the logs for any relevant error messages or warnings: ``` sudo tail -f /var/log/vernemq/console.log sudo tail -f /var/log/vernemq/error.log ``` Monitor Netdata charts: Monitor Netdata's VerneMQ dashboard to gain more insight into the behavior of your MQTT broker over time. Look for spikes in the number of expired messages, slow message delivery, or increasing message queues.
Project: Grafana Loki (Observability and Analysis / Observability)
File: docs.md

title: "{{ replace .Name "-" " " | title }}" description: "" lead: "" date: {{ .Date }} lastmod: {{ .Date }} draft: true images: [] menu: docs: parent: "" weight: 999 toc: true {{< img src="{{ .Name | urlize }}.jpg" alt="{{ replace .Name "-" " " | title }}" caption="{{ replace .Name "-" " " | title }}" >}}
Project: Micrometer (Observability and Analysis / Observability)
File: CONTRIBUTING.md

This Contributing Guide is intended for those that would like to contribute to Micrometer. If you would like to use any of the published Micrometer modules as a library in your project, you can instead include the Micrometer artifacts from the Maven Central repository using your build tool of choice. See . Contributions come in various forms and are not limited to code changes. The Micrometer community benefits from contributions in all forms. For example, those with Micrometer knowledge and experience can contribute by: Answering Answering questions on the Share Micrometer knowledge in other ways (e.g. presentations, blogs) The remainder of this document will focus on guidance for contributing code changes. It will help contributors to build, modify, or test the Micrometer source code. Contributions in the form of source changes require that you fill out and submit the if you have not done so previously. The Micrometer source code is hosted on GitHub at https://github.com/micrometer-metrics/micrometer. You can use a Git client to clone the source code to your local machine. Micrometer targets Java 8 but requires JDK 11 or later to build. If you are not running Gradle with JDK 11 or later and Gradle cannot detect an existing JDK 17 installation, it will download one. The Gradle wrapper is provided and should be used for building with a consistent version of Gradle. The wrapper can be used with a command, for example, `./gradlew check` to build the project and check conventions. This repository should be imported as a Gradle project into your IDE of choice. The is configured to check and apply consistent formatting in the codebase through the build. The `checkFormat` task checks the formatting as part of the `check` task. Apply formatting with the `format` task. You should rely on the formatting the `format` task applies instead of your IDE's configured formatting. Specific modules or a test class can be run from your IDE for convenience. The Gradle `check` task depends on the `test` task, and so tests will be run as part of a build as described previously. Run `./gradlew pTML` to publish a Maven-style snapshot to your Maven local repo. The build automatically calculates the "next" version for you when publishing snapshots. These local snapshots can be used in another project to test the changes. For example: ```groovy repositories { mavenLocal() } dependencies { implementation 'io.micrometer:micrometer-core:latest.integration' } ``` Micrometer has a number of integration tests that are implemented with and use Docker. These tests do not run by default. The integration tests for Elasticsearch use the elasticsearch docker image that has the . Do not run the Micrometer integration tests if you do not agree to the terms of the license. You need a Docker daemon running for these tests to work. You can run them with the `dockerTest` task. For example, with the Gradle wrapper: `./gradlew dockerTest`.