cwielenb/CNCF-Dataset huggingface dataset:
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: DOCKERHUB_deprecated.md

<p align="center"> <img width="250" height="238" src="https://github.com/thomaspoignant/go-feature-flag/raw/main/logo.png" alt="go-feature-flag logo" /> </p> <p align="center"> <img alt="Docker Image Version" src="https://img.shields.io/docker/v/thomaspoignant/go-feature-flag-relay-proxy?sort=semver&color=green"/> <img alt="Docker Image Size" src="https://img.shields.io/docker/image-size/thomaspoignant/go-feature-flag-relay-proxy?sort=semver"/> <img alt="Docker Hub downloads" src="https://img.shields.io/docker/pulls/thomaspoignant/go-feature-flag-relay-proxy?logo=docker"/> <a href="https://github.com/thomaspoignant/go-feature-flag/blob/main/LICENSE"><img src="https://img.shields.io/github/license/thomaspoignant/go-feature-flag" alt="License"/></a> <a href="https://gofeatureflag.org/slack"><img src="https://img.shields.io/badge/join-us%20on%20slack-gray.svg?longCache=true&logo=slack&colorB=green" alt="Join us on slack"></a> </p> The GO Feature Flag Relay Proxy retrieve your feature flag configuration file using SDK and expose APIs to get your flags variations. It lets a number of servers to connect to a single configuration file. This can be useful if you want to use the same feature flags configuration file for frontend and backend, this allows to be language agnostic by using standard protocol. For more information about GO Feature Flag Relay Proxy, please visit . This default distribution is the official distribution for `go-feature-flag-relay-proxy`. Where to file issues: ). Source are available in . All versions are available in the . Release notes are available . `go-feature-flag-relay-proxy` requires a configuration file to be used. By default, we expect to have this configuration file in the `/goff` directory of the container and the file should be named `goff-proxy.yaml`. The default port used for the service is `1031`. ```shell docker run \ -v $(pwd)/goff-proxy.yaml:/goff/goff-proxy.yaml \ thomaspoignant/go-feature-flag-relay-proxy:latest ``` This is a small example on how to run `go-feature-flag-relay-proxy` locally. ```shell curl https://raw.githubusercontent.com/thomaspoignant/go-feature-flag/main/cmd/relayproxy/testdata/config/valid-file.yaml -o goff-proxy.yaml docker run \ -p 1031:1031 \ -v $(pwd)/goff-proxy.yaml:/goff/goff-proxy.yaml \ thomaspoignant/go-feature-flag-relay-proxy:latest curl -X 'POST' \ 'http://localhost:1031/v1/feature/flag-only-for-admin/eval' -H 'accept: application/json' -H 'Content-Type: application/json' \ -d '{ "user": { "key": "contact@gofeatureflag.org", "anonymous": true, "custom": { "admin": true, "email": "contact@gofeatureflag.org" }}, "defaultValue": "false"}' ``` View information for the software contained in this image. This project is open for contribution, see the for some helpful tips.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: store-exemplars.md

aliases: ../../operators-guide/use-exemplars/storing-exemplars/ ../../operators-guide/using-exemplars/storing-exemplars/ ../../operators-guide/use-exemplars/store-exemplars/ description: Learn how to store exemplars in Grafana Mimir. menuTitle: Store exemplars title: Store exemplars in Grafana Mimir weight: 30 You can enable exemplar storage in Grafana Mimir and view the resulting data in Grafana. While exemplars can be enabled for all tenants at once or for only specific tenants, we recommend enabling and enforcing limits for exemplars for only specific tenants. In the Grafana Mimir configuration file, set the `limits.maxglobalexemplarsperuser` value. Start with a relatively low number (100,000) and adjust it if needed. A partial Grafana Mimir configuration file with `maxglobalexemplarsperuser` set globally looks as follows: ```yaml limits: maxglobalexemplarsperuser: 100000 ``` Save and deploy the configuration file. Perform a rolling update of Grafana Mimir components. Ensure Grafana Mimir uses a runtime configuration file by verifying that the flag `-runtime-config.file` is set to a non-null value. For more information about supported runtime configuration, refer to In the runtime configuration file, set the `overrides.<TENANT>.maxglobalexemplarsperuser` value. Start with a relatively low number (100,000) and adjust it if needed. A partial runtime configuration file with `maxglobalexemplarsperuser` set for a tenant called "tenant-a" would look as follows: ```yaml overrides: "tenant-a": maxglobalexemplarsperuser: 100000 ``` Save and deploy the runtime configuration file. After the `-runtime-config.reload-period` has elapsed, components reload the runtime configuration file and use the updated configuration.
Project: M3 (Observability and Analysis / Observability)
File: flushing.md

title: "Flushing" weight: 2 Flushing is the process by which m3aggregator instances output the aggregated time series data (by using protocol). There are two targets to which the data is flushed: Persistence: the aggregated data is flushed to `m3coordinator` which then persists it in `m3db`. Forwarding: intermediate aggregation data is flushed to other nodes of `m3aggregator` (in a multi-node setup) for further processing. This is necessary for rollup rule processing - eg. when a label is dropped, the resulting time series has a new id which potentially maps to a different shard (which may be owned by a different node). In a replicated setup, only the the data (both persistence and forwarding). After each flush, for every combination of shard/metrics type/aggregation window the leader node in etcd. Follower nodes are [watching the changes of last flushed timestamps](https://github.com/m3db/m3/blob/0865ebc80e85234b00532f93521438856883da9c/src/aggregator/aggregator/followerflushmgr.go#L563-L567) for the shardset that they own. The data that has been flushed by the leader node is considered as persisted, and the followers can the corresponding data they have accumulated for the given shard/metrics type/aggregation window. If, for some reason, a follower node does not receive last flush timestamp updates from the leader, it will keep the aggregated data for a while, but the follower will go into after the time period defined by `maxBufferSize` and start discarding the accumulated data in order to reclaim the memory. The default value for this setting is 5 minutes: ```yaml aggregator: flushManager: maxBufferSize: 5m ``` When a follower gets promoted to a leader, it initially flushes time windows it has buffered, following the last flush timestamp reported by the previous leader via etcd. are timestamps that can be used to control flushing from the given shard. They are fields that are defined for each shard in the placement structure. If the shard has its cutover field set to some timestamp value, the shard will only once the wall clock will go past the given cutover timestamp. Until this happens, any aggregated data gets discarded. Similarly, if the shard has its cutoff field set to some value, the shard will once the wall clock will go past the given cutoff timestamp. If the shard does not have cutover/cutoff fields it will flush indefinitely.
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: about-configurations.md

aliases: /docs/phlare/latest/operators-guide/configuring/about-configurations/ /docs/phlare/latest/configure-server/about-configurations/ description: Learn about Pyroscope configuration and key guidelines to consider. menuTitle: About configurations title: About Pyroscope configurations weight: 10 You can configure Pyroscope via a (-based) configuration file or CLI (command-line-interface) flags. It is best to specify your configuration via the configuration file rather than CLI flags. Every parameter that is set in the configuration file can also be set via a corresponding CLI flag. If you specify both CLI flags and configuration parameters, CLI flags take precedence over corresponding values in a configuration file. You can specify the configuration file by using the `-config.file` CLI flag. To see the CLI flags that you need to get started with Pyroscope, run the `pyroscope -help` command. To see the current configuration state of any component, use the `/api/v1/status/config` HTTP API endpoint. It is recommended to use a single configuration file and either pass it to all replicas of Pyroscope (if you are running multiple single-process Pyroscope replicas) or to all components of Pyroscope (if you are running Pyroscope as microservices). If you are running Pyroscope on Kubernetes, you can achieve this by storing the configuration file in a and mounting it in each Pyroscope container. This helps avoid a common misconfiguration pitfall: while certain configuration parameters might look like theyre only needed by one type of component, they might in fact be used by multiple components. For example, the `-distributor.replication-factor` CLI flag is not only required by ingesters, but also by distributors and queriers. By using a single configuration file, you ensure that each component gets all the configuration that it needs without needing to track which parameter belongs to which component. There is no harm in passing a configuration that is specific to one component (such as an ingester) to another component (such as a querier). In such case, the configuration is simply ignored. If necessary, you can use advanced CLI flags to override specific values on a particular Pyroscope component or replica. This can be helpful if you want to change a parameter that is specific to a certain component, without having to do a full restart of all other components. The most common use case for CLI flags is to use the `-target` flag to run Pyroscope as microservices. By setting the `-target` CLI flag, all Pyroscope components share the same configuration file, but you can make them behave as a given component by specifying a `-target` command-line value, such as `-target=ingester` or `-target=querier`.
Project: Flipt (Observability and Analysis / Feature Flagging)
File: ARCHITECTURE.md

This document provides an overview of the key elements and structure of the Flipt React/Typescript client application (UI). The application is a modern web application built using React and TypeScript with Redux for global state management. Read more about the reasoning behind the choice of React/TypeScript on our . App: These files contain the 'pages for the application. This folder is further divided into subfolders for each page. The `App.tsx` file is the entry point for the application. It contains the routes for the application and the top-level components that are rendered on each page. We use for routing. is used for client-side routing to maintain backward compatability with the previous version of the UI. Components: These are reusable pieces of code that return a React element to be rendered to the page. The components for this application are located in the `components` directory. This directory is further divided into subdirectories which roughly correspond to the pages of the application. For example, the `namespaces` directory contains components that are used on the Namespaces page. State: Redux is used for global state management in the application. The `store.ts` file is where the Redux store is configured. This store is the single source of truth for global state data in the application (ie: `namespacesSlice.ts` contains the Redux slice for managing the namespaces state). Most other state in the application is managed locally by React components via the `useState` hook and the API. Data: This folder contains `api.ts` which is our thin wrapper around the . It also contains and other 'data' related functionality such as `validations.ts` for Yup validation. Types: TypeScript types are used throughout the application to enforce type safety. Utils: The `utils` directory contains utility functions that are used across the application. TODO See: <https://github.com/flipt-io/flipt/blob/main/DEVELOPMENT.md#ui> for instructions on how to run the UI locally. We use for unit testing and for end-to-end testing. The unit tests are located alongside the code they test. The end-to-end tests are located in the `tests` directory. The end-to-end tests are run in a Docker container via Dagger. To run the tests locally, you will need to have Docker installed. You can run the tests locally by running the following command from the root of the repository: mage dagger:run test:ui We use for linting. The configuration for ESLint is located in the `.eslintrc.json`. The linting rules are enforced via CI (GitHub Actions) and locally via the `lint` script in the `package.json` file (`npm run lint`). We use for formatting. The configuration for Prettier is located in the `prettier.config.cjs` file. Run `npm run format` to format the code.
Project: Checkmk (Observability and Analysis / Observability)
File: 16308.md

key | value | date | 2024-01-11T12:12:45+00:00 version | 2.3.0b1 class | feature edition | cre component | notifications level | 2 compatible | yes Previously, you could only test your notification rulesets using the "Analyze" option against a limited set of notifications in the backlog or with the "Fake check result" command. We now introduce the possibility to define a custom notification and test it against your rulesets. The option can be found in "Setup" - "Notifications" - "Test notifications". In the popup, select whether you want to test on a host or a service notification. Select the host and service (if you want to test on a service notification) and the type of simulation. Currently supported are 'Start of downtime" and "Status change". Optionally, you can specify a custom plugin output. A checkbox allows you to decide whether to test only (default) or to send a real notification according to your notification rules. Within the 'Advanced condition simulation' options you can set a custom notification date and time to test period matching and the notification number.
Project: Grafana (Observability and Analysis / Observability)
File: parca.md

aliases: ../features/datasources/parca/ description: Continuous profiling for analysis of CPU and memory usage, down to the line number and throughout time. Saving infrastructure cost, improving performance, and increasing reliability. keywords: parca guide profiling labels: products: cloud enterprise oss title: Parca weight: 1110 Grafana ships with built-in support for Parca, a continuous profiling OSS database for analysis of CPU and memory usage, down to the line number and throughout time. Add it as a data source, and you are ready to query your profiles in . To configure basic settings for the data source, complete the following steps: Click Connections in the left-side menu. Under Your connections, click Data sources. Enter `Parca` in the search bar. Click Parca. The Settings tab of the data source is displayed. Set the data source's basic configuration options: | Name | Description | | | | | `Name` | A name to specify the data source in panels, queries, and Explore. | | `Default` | The default data source will be pre-selected for new panels. | | `URL` | The URL of the Parca instance, e.g., `http://localhost:4100` | | `Basic Auth` | Enable basic authentication to the Parca data source. | | `User` | User name for basic authentication. | | `Password` | Password for basic authentication. | Query editor gives you access to a profile type selector, a label selector, and collapsible options. Select a profile type from the drop-down menu. While the label selector can be left empty to query all profiles without filtering by labels, the profile type must be selected for the query to be valid. Grafana does not show any data if the profile type isnt selected when a query is run. Use the labels selector input to filter by labels. Parca uses similar syntax to Prometheus to filter labels. Refer to for available operators and syntax. Select a query type to return the profile data which can be shown in the , metric data visualized in a graph, or both. You can only select both options in a dashboard, because panels allow only one visualization. Profiles can be visualized in a flame graph. See the to learn about the visualization and its features. Parca returns profiles aggregated over a selected time range, and the absolute values in the flame graph grow as the time range gets bigger while keeping the relative values meaningful. You can zoom in on the time range to get a higher granularity profile up to the point of a single Parca scrape interval. Metrics results represent the aggregated value, over time, of the selected profile type. Parca returns ungrouped data with a series for each label combination. This allows you to quickly see any spikes in the value of the scraped profiles and zoom in to a particular time range. You can modify the Grafana configuration files to provision the Parca data source. To learn more, and to view the available provisioning settings, see . Here is an example config: ```yaml apiVersion: 1 datasources: name: Parca type: parca url: http://localhost:3100 ``` {{% docs/reference %}} {{% /docs/reference %}}
Project: SkyWalking (Observability and Analysis / Observability)
File: backend-k8s-monitoring.md

Kubernetes is an open-source container-orchestration system for automating computer application deployment, scaling, and management. It was originally designed by Google and is now maintained by the Cloud Native Computing Foundation. It aims to provide a "platform for automating deployment, scaling, and operations of application containers across clusters of hosts". It works with a range of container tools, including Docker. Nowadays, Kubernetes is the fundamental infrastructure for cloud native applications. SkyWalking provides the following ways to monitor deployments on Kubernetes. Use kube-state-metrics (KSM) and cAdvisor to collect metrics of Kubernetes resources, such as CPU, service, pod, and node. Read for more details. Rover is a SkyWalking native eBPF agent to collect network Access Logs to support topology-aware and metrics analysis. Meanwhile, due to the power of eBPF, it could profile running services written by C++, Rust, Golang, etc. Read for more details. SkyWalking deeply integrates with Kubernetes to help users understand the status of their applications on Kubernetes. Cillium with Hubble is in our v10 plan.
Project: Vector (Observability and Analysis / Observability)
File: what-is-vector.md

title: What is Vector? weight: 1 tags: ["concepts"] Vector is a high-performance observability data pipeline that puts organizations in control of their observability data. [Collect], [transform], and [route] all your logs, metrics, and traces to any vendors you want today and any other vendors you may want tomorrow. Vector enables dramatic cost reduction, novel data enrichment, and data security where you need it, not where is most convenient for your vendors. Open source and up to 10x faster than every alternative. Vector is downloaded millions of times per month and relied on by companies like T-Mobile, Comcast, Zendesk, and Discord to own their observability data. {{< jump "/docs/setup/quickstart" >}}
Project: Checkmk (Observability and Analysis / Observability)
File: 15326.md

key | value | date | 2024-02-05T07:35:36+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Both oracle instance and oracle uptime services vanished due to too strict validation. Crash report showed a `ValidationError`.
Project: OpenSearch (Observability and Analysis / Observability)
File: failed_check.md

title: '[AUTOCUT] Gradle Check Failure on push to {{ env.branch_name }}' labels: '>test-failure, bug, autocut' Gradle check has failed on push of your commit {{ env.prfromsha }}. Please examine the workflow log {{ env.workflow_url }}. Is the failure unrelated to your change?
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: file.md

title: File weight: 200 generated_file: true Storing messages in plain-text files More info at https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.37/administration-guide/56#TOPIC-1829124 Documentation: https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.37/administration-guide/36#TOPIC-1829044 Store file path Default: - Enable creating non-existing directories. Default: false The group of the directories created by syslog-ng. To preserve the original properties of an existing directory, use the option without specifying an attribute: dir-group(). Default: Use the global settings The owner of the directories created by syslog-ng. To preserve the original properties of an existing directory, use the option without specifying an attribute: dir-owner(). Default: Use the global settings The permission mask of directories created by syslog-ng. Log directories are only created if a file after macro expansion refers to a non-existing directory, and directory creation is enabled (see also the create-dirs() option). For octal numbers prefix the number with 0, for example use 0755 for rwxr-xr-x. Default: Use the global settings This option enables putting outgoing messages into the disk buffer of the destination to avoid message loss in case of a system failure on the destination side. Default: false Default: - Default: -
Project: Grafana Tempo (Observability and Analysis / Observability)
File: generic_forwarding.md

title: Generic forwarding menuTitle: Generic forwarding description: Asynchronous replication of ingested traces weight: 130 Generic forwarding allows asynchronous replication of ingested traces. The distributor writes received spans to both the ingester and defined endpoints, if enabled. This feature works in a "best-effort" manner, meaning that no retries happen if an error occurs during replication. {{< admonition type="warning" >}} Generic forwarding does not work retroactively. Once enabled, the distributor only replicates freshly ingested spans. {{% /admonition %}} Enabling generic forwarding requires the configuration of the `distributor` and `overrides`. First, define a list of forwarders in the `distributor` section. Each forwarder must specify a unique `name`, supported `backend`, and backend-specific configuration. Second, reference these forwarders in the `overrides` section. This allows for fine-grained control over forwarding and makes it possible to enable this feature globally or on a per-tenant basis. For a detailed view of all the config options for the generic forwarding feature, please refer to and configuration pages.