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

Thank you for trusting the `go-feature-flag` and using it in your organization. | Organizartion | Website / Contact | Description of use | |-|-|-| | Cast.ai | https://cast.ai/ | | | Chapati systems | https://chapati.systems/ | | | Lyft | https://github.com/lyft/atlantis | Inside the Atlantis fork used by Lyft. | | Tencent | https://github.com/TencentBlueKing/bkmonitor-datalink | Used inside BKMONITOR-DATALINK. | | Agentero | https://agentero.com/ | FF tool within Agentero platform |
Project: SkyWalking (Observability and Analysis / Observability)
File: i18n.md

This section explains how to manage translations for internationalization of menu items. SkyWalking UI's internationalization translations are in the . The translations include `menu name` and `description`. The translation key of `menu name` is the value of `i18nKey` from . The translation key of `description` consists of the `i18nKey` value and `_desc` suffix. The `description` contents will be displayed on the Marketplace page. The following is a typical `menu name` and `description` for i18nKey=`general_service` ```json { "general_service": "General Service", "generalservicedesc": "Observe services and relative direct dependencies through telemetry data collected from SkyWalking Agents." } ```
Project: Netdata (Observability and Analysis / Observability)
File: ipmi_sensors_states.md

This alert is related to the IPMI (Intelligent Platform Management Interface) sensors in your system. IPMI is a hardware management interface used for monitoring server health and collecting information on various hardware components. The alert is triggered when any of the IPMI sensors detect conditions that are outside the normal operating range, and are in a warning or critical state. Check IPMI sensor status: To check the status of IPMI sensors, you can use the `ipmi-sensors` command with appropriate flags. For instance: ``` sudo ipmi-sensors --output-sensor-state ``` This command will provide you with detailed information on the current state of each sensor, allowing you to determine which ones are in a warning or critical state. Analyze sensor data: Based on the output obtained in the previous step, identify the sensors that are causing the alert. Take note of their current values and thresholds. To obtain more detailed information, you can also use the `-v` (verbose) flag with the command: ``` sudo ipmi-sensors -v --output-sensor-state ``` Investigate the cause of the issue: Once you have identified the sensors in a non-nominal state, start investigating the root cause of the issue. This may involve checking the hardware components, system logs, or contacting your hardware vendor for additional support. Resolve the issue: Based on your investigation, take the necessary steps to resolve the issue. This may include replacing faulty hardware, addressing configuration errors, or applying firmware updates. Verify resolution: After addressing the issue, use the `ipmi-sensors` command to check the status of the affected sensors. Ensure that they have returned to the nominal state, and no additional warning or critical conditions are being reported.
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_registry.CreateResourceEvent.md

title: "Interface: CreateResourceEvent" linkTitle: "CreateResourceEvent" slug: "plugin_registry.CreateResourceEvent" .CreateResourceEvent Event fired when creating a resource. data: `Object` | Name | Type | Description | | : | : | : | | `status` | `CONFIRMED` | What exactly this event represents. 'CONFIRMED' when the user chooses to apply the new resource. For now only 'CONFIRMED' is sent. | _ type: `CREATE_RESOURCE`
Project: Hubble (Observability and Analysis / Observability)
File: SECURITY.md

Join the [kubernetes-security-announce] group for security and vulnerability announcements. You can also subscribe to an RSS feed of the above using . Instructions for reporting a vulnerability can be found on the [Kubernetes Security and Disclosure Information] page. Information about supported Kubernetes versions can be found on the [Kubernetes version and version skew support policy] page on the Kubernetes website.
Project: Grafana (Observability and Analysis / Observability)
File: traceql-search.md

description: Learn how to create TraceQL queries in Grafana using Explore > Search. keywords: grafana tempo traces queries labels: products: cloud enterprise oss menuTitle: Search traces title: Search traces using TraceQL query builder weight: 300 Inspired by PromQL and LogQL, TraceQL is a query language designed for selecting traces. TraceQL provides a method for formulating precise queries so you can zoom in to the data you need. Query results are returned faster because the queries limit what is searched. To learn more about how to query by TraceQL, refer to the . The TraceQL query builder, located on the Explore > Query type > Search in Grafana, provides drop-downs and text fields to help you write a query. This feature is automatically available in Grafana 10 (and newer) and Grafana Cloud. To enable the TraceQL query builder in self-hosted Grafana through version 10.1, . {{< docs/shared source="grafana" lookup="datasources/tempo-search-traceql.md" leveloffset="+1" version="<GRAFANA VERSION>" >}}
Project: Vector (Observability and Analysis / Observability)
File: patch-release.md

name: Vector patch release about: Use this template for a new patch release. title: "Vector [version] release" labels: "domain: releasing" Before the release: [ ] Create a new release preparation branch from the current release branch `git fetch && git checkout v0.<current minor version> && git checkout -b prepare-v0.<new version number>` [ ] Cherry-pick in all commits to be released from the associated release milestone If any merge conflicts occur, attempt to solve them and if needed enlist the aid of those familiar with the conflicting commits. [ ] Run `cargo vdev build release-cue` to generate a new cue file for the release [ ] Add `changelog` key to generated cue file [ ] Add description key to the generated cue file with a description of the release (see previous releases for examples). [ ] Update version number in `distribution/install.sh` [ ] Add new version to `website/cue/reference/versions.cue` [ ] Create new release md file by copying an existing one in `./website/content/en/releases/` and updating version number [ ] Bump the release number in the `Cargo.toml` to the current version number [ ] Run `cargo check` to regenerate `Cargo.lock` file [ ] Commit these changes [ ] Open PR against the release branch (`v0.<new version number>`) for review [ ] PR approval On the day of release: [ ] Ensure release date in cue matches current date. [ ] Rebase the release preparation branch on the release branch Squash the release preparation commits (but not the cherry-picked commits!) to a single commit. This makes it easier to cherry-pick to master after the release. `git checkout prepare-v0.<new version number> && git rebase -i v0.<current minor version>` [ ] Merge release preparation branch into the release branch `git co v0.<current minor version> && git merge --ff-only prepare-v0.<current minor version>.<patch>` [ ] Tag new release [ ] `git tag v0.<minor>.<patch> -a -m v0.<minor>.<patch>` [ ] `git push origin v0.<minor>.<patch>` [ ] Wait for release workflow to complete Discoverable via . [ ] Push the release branch to update the remote (This should close the preparation branch PR). `git checkout v0.<current minor version> && git push` . [ ] Once Helm chart is released, updated Vector manifests Run `cargo vdev build manifests` and open a PR with changes to have them available internally. Follow the . [ ] Cherry-pick any release commits from the release branch that are not on `master`, to `master` [ ] Reset the `website` branch to the `HEAD` of the release branch to update https://vector.dev [ ] `git checkout website && git reset --hard origin/v0.<current minor version>.<patch> && git push` [ ] Kick-off post-mortems for any regressions resolved by the release
Project: Loggie (Observability and Analysis / Observability)
File: CONTRIBUTING.md

Welcome to Kubernetes. We are excited about the prospect of you joining our ! The Kubernetes community abides by the CNCF . Here is an excerpt: As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. We have full documentation on how to get started contributing here: <! If your repo has certain guidelines for contribution, put them here ahead of the general k8s resources --> Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests - Main contributor documentation, or you can just jump directly to the - Common resources for existing developers - We have a diverse set of mentorship programs available that are always looking for volunteers! <! Custom Information - if you're copying this template for the first time you can add custom content here, for example: - Replace `kubernetes-users` with your slack channel string, this will send users directly to your channel. -->
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: audit-seccomp.md

title: Gadget audit-seccomp The Audit Seccomp gadget provides a stream of events with syscalls that had their seccomp filters generating an audit log. An audit log can be generated in one of those two conditions: The Seccomp profile has the flag SECCOMPFILTERFLAG_LOG (currently ) and returns any action other than SECCOMPRETALLOW. The Seccomp profile does not have the flag SECCOMPFILTERFLAG_LOG but returns SCMPACTLOG or SCMPACTKILL*. ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: audit-seccomp namespace: gadget spec: node: minikube gadget: audit-seccomp runMode: Manual outputMode: Stream ``` Start audit seccomp ```bash $ kubectl annotate -n gadget trace/audit-seccomp \ gadget.kinvolk.io/operation=start ``` Stop audit seccomp ```bash $ kubectl annotate -n gadget trace/audit-seccomp \ gadget.kinvolk.io/operation=stop ``` Stream
Project: Grafana Tempo (Observability and Analysis / Observability)
File: search-tag.md

title: Tag search description: Troubleshoot No options found in Grafana tag search weight: 476 aliases: ../operations/troubleshooting/search-tag/ An issue occurs while searching for traces in Grafana Explore. The Service Name and Span Name drop down lists are empty, and there is a `No options found` message. HTTP requests to Tempo query frontend endpoint at `/api/search/tag/service.name/values` would respond with an empty set. The introduction of a cap on the size of tags causes this issue. Configuration parameter `maxbytespertagvalues_query` causes the return of an empty result when a query exceeds the configured value. There are two main solutions to this issue: Reduce the cardinality of tags pushed to Tempo. Reducing the number of unique tag values will reduce the size returned by a tag search query. Increase the `maxbytespertagvalues_query` parameter in the block of your Tempo configuration to a value as high as 50MB.
Project: M3 (Observability and Analysis / Observability)
File: README.md

A partitioned message queueing, routing and delivery library designed for very small messages at very high speeds that don't require disk durability. This makes it quite useful for metrics ingestion pipelines. Messages are written in the following manner: Write to the public `Writer` in `writer.go`, which acquires read lock on writer (can be concurrent). That writes to all registered `consumerServiceWriter` writers (one per downstream service) in a sequential loop, one after another. The `consumerServiceWriter` selects a shard by asking message what shard it is and writes immediately to that shard's `shardWriter`, without taking any locks in any of this process (should check for out of bounds of the shard in future). The `shardWriter` then acquires a read lock and writes it to a `messageWriter`. The `messageWriter` then acquires a write lock on itself and pushes the message onto a queue. The `messageWriter` has a background routine that periodically acquires it's writeLock and scans the queue for new writes to forward to downstream consumers. If `messageWriter` is part of a `sharedShardWriter` it will have many downstream consumer instances. Otherwise, if it's part of a `replicatedShardWriter` there is only one consumer instance at a time. The `consumerWriter` (one per downstream consumer instance) then takes a write lock for the connection index selected every write that it receives. The `messageWriter` selects the connection index based on the shard ID so that shards should balance the connection they ultimately use to send data downstream to instances (so IO is not blocked on a per downstream instance).
Project: Checkmk (Observability and Analysis / Observability)
File: 14618.md

key | value | date | 2024-01-23T06:59:04+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes As a result of a refactoring instead of deleting just pre-filtered mails, `checkmailloop` would delete all previously fetched mails. This change brings back the former behavior.
Project: Netdata (Observability and Analysis / Observability)
File: pagerduty.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/integrations/pagerduty.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/metadata.yaml" sidebar_label: "PagerDuty" learn_status: "Published" learnrelpath: "Alerts & Notifications/Notifications/Centralized Cloud Notifications" message: "DO NOT EDIT THIS FILE DIRECTLY, IT IS GENERATED BY THE NOTIFICATION'S metadata.yaml FILE" endmeta--> <img src="https://netdata.cloud/img/pagerduty.png" width="150"/> From the Netdata Cloud UI, you can manage your space's notification settings and enable the configuration to deliver notifications on PagerDuty. <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> A Netdata Cloud account Access to the Netdata Space as an Admin The Netdata Space needs to be on a paid plan You need to have a PagerDuty service to receive events using webhooks. Steps to configure your PagerDuty to receive notifications from Netdata: Create a service to receive events from your services directory page on PagerDuty At step 3, select `Events API V2` Integration or View Webhooks if you already have some defined Once the service is created, you will be redirected to its configuration page, where you can copy the Integration Key and Integration URL (Alert Events) fields to add them to your notification configuration in the Netdata UI. Click on the Space settings cog (located above your profile icon) Click on the Notification tab Click on the + Add configuration button (near the top-right corner of your screen) On the PagerDuty card click on + Add A modal will be presented to you to enter the required details to enable the configuration: Notification settings* are Netdata specific settings Configuration name - you can optionally provide a name for your configuration you can easily refer to it Rooms - by specifying a list of Rooms you are select to which nodes or areas of your infrastructure you want to be notified using this configuration Notification - you specify which notifications you want to be notified using this configuration: All Alerts and unreachable, All Alerts, Critical only Integration configuration* are the specific notification integration required settings, which vary by notification method. For PagerDuty: Integration Key - is a 32 character key provided by PagerDuty to receive events on your service. Integration URL (Alert Events) - is the URL provided by PagerDuty where we will send notifications.
Project: Netdata (Observability and Analysis / Observability)
File: elasticsearch_cluster_health_status_red.md

This alert is triggered when the Elasticsearch cluster health status turns `RED`. If you receive this alert, it means that there is a problem that needs immediate attention, such as data loss or one or more primary and replica shards are not allocated to the cluster. Elasticsearch cluster health status provides an indication of the cluster's overall health, based on the state of its shards. The status can be `green`, `yellow`, or `red`: `Green`: All primary and replica shards are allocated. `Yellow`: All primary shards are allocated, but some replica shards are not. `Red`: One or more primary shards are not allocated, leading to data loss. Check the Elasticsearch cluster health using the `_cat` API: ``` curl -XGET 'http://localhost:9200/_cat/health?v' ``` Examine the output to understand the current health status, the number of nodes and shards, and any unassigned shards. To get more details on the unassigned shards, use the `_cat/shards` API: ``` curl -XGET 'http://localhost:9200/_cat/shards?v' ``` Look for shards with the status `UNASSIGNED`. Identify the root cause of the issue, such as: A node has left the cluster or failed, causing the primary shard to become unassigned. Insufficient disk space is available, preventing shards from being allocated. Cluster settings or shard allocation settings are misconfigured. Take appropriate action based on the root cause: Ensure all Elasticsearch nodes are running and connected to the cluster. Add more nodes or increase disk space as needed. Review and correct cluster and shard allocation settings. Monitor the health status as the cluster recovers: ``` curl -XGET 'http://localhost:9200/_cat/health?v' ``` If the health status turns `YELLOW` or `GREEN`, the cluster is no longer in the `RED` state.
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: experimentation.md

An experimentation rollout is when your flag is configured to be served only for a determined time. It means that before the rollout start date, the `default` value is served to all users. Between the dates the flag is evaluated. After the end date the `default` value is served to all users. ```yaml experimentation-flag: percentage: 50 true: "B" false: "A" default: "Default" rollout: experimentation: start: 2021-03-20T00:00:00.10-05:00 end: 2021-03-21T00:00:00.10-05:00 ``` ```json { "experimentation-flag": { "percentage": 50, "true": "B", "false": "A", "default": "Default", // highlight-start "rollout": { "experimentation": { "start": "2021-03-20 00:00:00 -0500", "end": "2021-03-21 00:00:00 -0500" } }, // highlight-end } } ``` ```toml [experimentation-flag] percentage = 50.0 true = "B" false = "A" default = "Default" [experimentation-flag.rollout] [experimentation-flag.rollout.experimentation] start = 2021-03-20T05:00:00.100Z end = 2021-03-21T05:00:00.100Z ``` Check this to see how it works. :::info The dates are in the format supported natively by your flag file format. ::: | Field | Description | ||| |`start`| The date the flag will be started to be served.| |`end`| The date the flag will be stopped to be served.| :::info A/B test is the shorthand for a simple controlled experiment. As the name implies, two versions (A and B) of a single variable are compared, which are identical except for one variation that might affect a user's behavior. A/B tests are widely considered the simplest form of controlled experiment. **(source wikipedia)** ::: To have a proper A/B testing solution with the module you should use the experimentation rollout combined with the . This combination will allow to have your experimentation running for a dedicated time, and you will have the data to knows exactly which user was on which version of the flag. To setup the duration of your A/B test you can use a tool from vwo, that will help you to set up the test duration correctly.
Project: Vector (Observability and Analysis / Observability)
File: amqp.md

title: AMQP description: Collect events from compatible brokers like RabbitMQ component_kind: source layout: component tags: ["amqp", "rabbitmq", "component", "source"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Netdata (Observability and Analysis / Observability)
File: vsphere_host_mem_usage.md

The `vspherehostmem_usage` alert is triggered when the memory utilization of a vSphere host reaches critical levels. This alert is raised to a warning level when the utilization exceeds 90% and becomes critical when it exceeds 98%. High memory utilization can lead to performance issues on the virtual machines running on the host. Log in to the vSphere client: Access the vSphere client to get an overview of your host's memory utilization and to identify which virtual machines are consuming the most memory. Identify high memory-consuming virtual machines: In the vSphere client, go to the "Hosts and Clusters" view and select the affected host. In the "Virtual Machines" tab, you can now see the memory usage of each virtual machine running on the host. Identify any virtual machines that are consuming a high amount of memory. Analyze the memory usage in the virtual machines: Connect to the high memory-consuming virtual machines and use their respective task managers (e.g., "top" command in Linux or Task Manager in Windows) to identify the applications and processes that are causing the high memory usage. Take action: If an application or process is consuming an excessive amount of memory and is not required, consider stopping it. Alternatively, if the application or process is essential, you may need to allocate more memory to the virtual machine or consider moving the workload to a different host with more available resources. Ensure the virtual machine's memory is optimally configured, as over-allocating memory may cause contention. Monitor the situation: Keep an eye on the memory utilization of the host and the virtual machines after making changes. If memory utilization remains high, consider analyzing other virtual machines or adding more memory to the host.
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: sigsnoop.md

title: Gadget sigsnoop sigsnoop traces all signals sent on the system. The following parameters are supported: failed: Trace only failed signal sending (default to false). signal: Which particular signal to trace (default to all). pid: Which particular pid to trace (default to all). kill-only: Trace only signals sent by the kill syscall (default to false). ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: sigsnoop namespace: gadget spec: node: ubuntu-hirsute gadget: sigsnoop runMode: Manual outputMode: Stream filter: namespace: default ``` Start sigsnoop gadget ```bash $ kubectl annotate -n gadget trace/sigsnoop \ gadget.kinvolk.io/operation=start ``` Stop sigsnoop gadget ```bash $ kubectl annotate -n gadget trace/sigsnoop \ gadget.kinvolk.io/operation=stop ``` Stream
Project: SkyWalking (Observability and Analysis / Observability)
File: thrift-plugin.md

The message with Field ID, 8888, must be reserved. Because Thrift cannot carry metadata to transport Trace Header in the original API, we transport them by wrapping TProtocolFactory. Thrift allows us to append any additional fields in the message even if the receiver doesn't deal with them. Those data will be skipped and left unread. Based on this, the 8888th field of the message is used to store Trace Header (or metadata) and to transport them. That means the message with Field ID, 8888, must be reserved. Avoid using the Field(ID is 8888) in your application.