cwielenb/CNCF-Dataset huggingface dataset:
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: Bhaumik_Shah.md

I am Bhaumik Shah, DevOps Engineer. We are setting up Kafka Platform for our bank and was looking for a Fault Tolerance tool which can provide chaos experiments. We have explored many tools which are available in the industry like: GremlinFree, PowerfulSeal, Pumba and finally Litmus. Litmus is far better which provides all the chaos feature for free which are available in other tools with license cost. I closely worked with Karthik to acheive below funcationalty for Kafka fault tolerance: Deploying confluent helm chart for kafka and checking brokers gets storage bound successfully Kill leader brokers under active load (via locust workload generator) and ensure it comes back Kill zookeeper pod and ensure it comes back Kill consumer pods (my own apps) and ensure they come back and don't miss messages Kill producer pods and ensure they come back and all messages get sent Looking for more enhancements/features and user friendly UI to configure/control all chaos experiments. I must say the team is doing great work and they are very proactive. Many congratulations to them on what they have achieved so far.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: CHAOS_EXPERIMENT_MATURITY.md

This document lists the criteria as per which the maturity levels of chaos experiments can be derived. <table> <tr> <th> Alpha </th> <th> Beta </th> <th> General Availabilty </th> </tr> <tr> <td> <ul> <li>Injects the intended chaos on any one standard Kubernetes platform (GKE, EKS, DOKS, vSphere)</li> <li>Has a clearly defined entry (initial status) & exit (resiliency) criteria</li> <li>Conforms to the standard litmus experiment structure (business logic, auxiliary tasks/utils, chaoslib)</li> <li>Provides a Kubernetes job manifest to execute the chaos experiment</li> <li>Accompanied by usage doc (readme) with pre-requisites, experiment tunables and procedure</li> </ul> </td> <td> <ul> <li>Successfully reverses the chaos, leaves cluster in a healthy state</li> <li>Clearly classified as an application-level or (cluster) infrastructure level chaos</li> <li>Leaves no chaos residue (cleans up resources created as part of execution) regardless of success</li> <li>Has sufficient debug messages (logs) indicating experiment flow</li> <li>Reuse of base chaoslib, existing (common) utils where possible</li> <li>Supports at least two of the standard Kubernetes platforms</li> <li>Accompanied by a how-to demo video to aid users</li> <li>Successfully executed by the LitmusChaos Operator (executor) via ChaosExperiment CR</li> <li>Templatizes any manifest/resource specification used in the experiment execution</li> </ul> </td> <td> <ul> <li>Supports all 4 standard Kubernetes platforms</li> <li>The ChaosResult CR contains sufficient info on the state (action & result of significant steps) of the chaos experiment</li> </ul> </td> </tr> </table>
Project: PowerfulSeal (Observability and Analysis / Chaos Engineering)
File: interactive.md

layout: default title: Interactive nav_order: 3 description: "" permalink: /interactive-mode parent: Modes ```sh $ seal interactive --help ``` Make sure you hit tab for autocompletion - that's what really makes the seal easy to use. Here's a sneak peek of what you can do in the interactive mode: ](https://asciinema.org/a/343525) ](https://asciinema.org/a/337767)
Project: Grafana (Observability and Analysis / Observability)
File: organising-alerts.md

aliases: ../../unified-alerting/alerting-rules/edit-cortex-loki-namespace-group/ # /docs/grafana/<GRAFANA_VERSION>/alerting/unified-alerting/alerting-rules/edit-cortex-loki-namespace-group/ ../../unified-alerting/alerting-rules/edit-mimir-loki-namespace-group/ # /docs/grafana/<GRAFANA_VERSION>/alerting/unified-alerting/alerting-rules/edit-mimir-loki-namespace-group/ canonical: https://grafana.com/docs/grafana/latest/alerting/fundamentals/alert-rules/organising-alerts/ description: Learn about organizing alerts using namespaces, folders, and groups keywords: grafana alerting organization labels: products: cloud enterprise oss title: Namespaces, folders, and groups weight: 107 Alerts can be organized using folders for Grafana-managed rules and namespaces for Mimir or Loki rules and group names. When creating Grafana-managed rules, the folder can be used to perform access control and grant or deny access to all rules within a specific folder. A namespace contains one or more groups. The rules within a group are run sequentially at a regular interval. The default interval is one (1) minute. You can rename Grafana Mimir or Loki rule namespaces and groups, and edit group evaluation intervals. The rules within a group are run sequentially at a regular interval, meaning no rules are evaluated at the same time and in order of appearance. The default interval is one (1) minute. You can rename Grafana Mimir or Loki rule namespaces and groups, and edit group evaluation intervals. Note If you want rules to be evaluated concurrently and with different intervals, consider storing them in different groups. Note Grafana managed alert rules are evaluated concurrently instead of sequentially.
Project: Graylog (Observability and Analysis / Observability)
File: Label.md

```js { "props": { "className": "container" } } const styles = ['Primary', 'Danger', 'Warning', 'Success', 'Info', 'Default']; <table className="table table-sm table-striped"> <tbody> {styles.map((style, i) => ( <tr key={`button-${style}-${i}`}> <th><strong>{style}:</strong></th> <td> <Label bsStyle={style.toLowerCase()}> EXAMPLE </Label> </td> </tr> ))} </tbody> </table> ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16789.md

key | value | date | 2024-04-18T16:02:21+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes If not configured otherwise, the service description of the active check "http" will be prepended with either "HTTP" or "HTTPS". In older installations only the "HTTP" prefix was possible and special handling was introduced to keep the old prefix for existing services. To improve the handling existing configurations of the "Service name" in the "Check HTTP service (deprecated)" rule may now be updated to contain the prefix "^HTTP" if the configured value does not start with a "^". This only changes the saved rule, the actual description of the service will not change.
Project: Zipkin (Observability and Analysis / Observability)
File: CONTRIBUTING.md

If you would like to contribute code, fork this GitHub repository and send a pull request (on a branch other than `master` or `gh-pages`). When submitting code, please apply . If the settings import correctly, CodeStyle/Java will be named Square and use 2 space tab and indent, with 4 space continuation indent. By contributing your code, you agree to license your contribution under the terms of the . All files are released with the Apache 2.0 license. If you are adding a new file it should have a header like below. This can be automatically added by running `./mvnw com.mycila:license-maven-plugin:format`. ``` /* Copyright The OpenZipkin Authors SPDX-License-Identifier: Apache-2.0 */ ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16698.md

key | value | date | 2024-04-25T08:08:50+00:00 version | 2.4.0b1 class | fix edition | cee component | notifications level | 1 compatible | yes The logrotate cronjob rotated the logfile mknotifyd.log in the right way but the mknotifyd was not aware of the changed logfile, resulting in logging to the rotated file. The mknotifyd is now aware of a change of the logfile.
Project: Checkmk (Observability and Analysis / Observability)
File: 16509.md

key | value | date | 2024-02-14T15:45:34+00:00 version | 2.4.0b1 class | fix edition | cee component | notifications level | 1 compatible | yes Configuring a service with "host check command > use the status of the service" would result in notifications for any service to be postponed forever. This has been fixed.
Project: Vector (Observability and Analysis / Observability)
File: 2022-01-19-component-sent-metrics-output-tag.md

date: "2022-01-19" title: "New `output` tag in internal metrics" description: "Adding an `output` tag for `componentsent*` metrics" authors: ["001wwang"] pr_numbers: [] release: "0.20.0" hideonrelease_notes: false In light of our work to support multiple output streams for components, we've added an `output` tag in the following metrics emitted by sources and transforms to ensure a seamless observability experience. You will not see the `output` tag for sink metrics because sinks currently do not use multiple outputs. `componentsentevents_total` `componentsenteventbytestotal` `eventsouttotal` (Note, this metric is deprecated in favor of the above) For example, the `remap` transform has a default output and an optionally enabled `dropped` output. The default output is specified simply as the `<component_id>` while the `dropped` output is specified as `<component_id>.dropped` in downstream components. Metrics for events sent to the default output will include a tag `output: _default`. Metrics for events sent to the `dropped` output will include a tag `output: dropped`. In general, all sources and transforms will use `output: _default` in metrics for events sent to their default output. ```json {"counter":{"value":1.0},"kind":"absolute","name":"componentsenteventstotal","namespace":"vector","tags":{"componentid":"foo","componentkind":"transform","componentname":"foo","componenttype":"remap","output":"default"}} {"counter":{"value":1.0},"kind":"absolute","name":"componentsenteventstotal","namespace":"vector","tags":{"componentid":"foo","componentkind":"transform","componentname":"foo","component_type":"remap","output":"dropped"}} ``` For user-defined outputs, the `output` tag will be populated accordingly with the user's custom output name. Importantly, to avoid naming collisions, `_default` is now a reserved name and cannot be used for user-defined outputs. The `route` transform is the only component that currently supports custom outputs (each configured route is an output). Components that can currently use multiple outputs include: You can view information about all of a component's outputs on its documentation page.
Project: Netdata (Observability and Analysis / Observability)
File: vsphere_inbound_packets_dropped.md

This alert is triggered when a significant number of inbound dropped packets are detected on the network interface of a Virtual Machine (VM) over the last 10 minutes. It indicates a potential issue with the VM's network connectivity or performance. Inbound dropped packets refer to packets that are received by a network interface but discarded before they are processed by the VM. This can occur for various reasons, such as network congestion, errors in packet content, or insufficient resources to handle the incoming data. Check for network congestion: High network usage can lead to packet drops when the network is saturated, or bandwidth is insufficient to handle the incoming traffic. Monitor the overall network usage in your environment to identify if this is the cause. Inspect network errors: Errors in packet content, such as checksum errors or framing errors, can result in dropped packets. Examine logs at the hypervisor and VM level for any indication of network errors. Check resource usage within the VM: Inspect CPU, memory, and disk usage within the VM. High resource utilization can lead to degraded network performance and dropped packets. Verify VM network configuration: Ensure that the VM's network configuration, such as its IP address, subnet mask, and default gateway, are correctly set. Misconfigured network settings can cause network issues, including higher rates of dropped packets. Check for faulty network hardware: Damaged or malfunctioning network hardware, such as network interface cards (NICs) or cables, can result in dropped packets. Check the hardware components involved in the VM's network connection and replace any faulty components. Evaluate hypervisor performance and configuration: The performance of the hypervisor hosting the VM can also impact network performance. Ensure the hypervisor has adequate resources and is configured correctly for optimal VM network performance.
Project: Vector (Observability and Analysis / Observability)
File: 2020-10-28-new-aws-integrations.md

date: "2020-10-27" title: "New AWS integrations" description: "Export observability data out of AWS." authors: ["binarylogic"] pr_numbers: [4101, 4779] release: "0.11.0" hideonrelease_notes: false badges: type: "new feature" domains: ["sources"] platforms: ["aws"] Getting observability data out of AWS can sometimes feel like you're in a , stitching together umpteen tools and hoping it all works in the end. We want to make this easier with Vector, and 0.11 includes our initial efforts: A new A new `aws_cloudwatch_logs_subscription_parser` transform (Removed in v0.23.0) A new A new A new To help you get started, we wrote on collecting AWS CloudWatch logs via AWS Firehose. With this setup you can send your AWS CloudWatch logs to any supported Vector . We're eager to hear what you think about these sources! and let us know.
Project: SkyWalking (Observability and Analysis / Observability)
File: tracing.md

Istio has built-in support to generate Zipkin traces from Envoy proxy sidecar, and SkyWalking can serve as a Zipkin server to collect and provide query APIs for these traces, you can deploy SkyWalking to replace Zipkin server in Istio, and point the Zipkin address to SkyWalking. SkyWalking also embeds Zipkin Lens UI as part of SkyWalking UI, you can use it to query Zipkin traces. SkyWalking has built-in Zipkin receiver, you can enable it by setting `receiver-zipkin` to `default` in `application.yml`, or by setting environment variable `SWRECEIVERZIPKIN=default` before starting OAP server: ```yaml receiver-zipkin: selector: ${SWRECEIVERZIPKIN:default} default: ``` After enabling the Zipkin receiver, SkyWalking listens on port 9411 for Zipkin traces, you can just change the Zipkin server address to SkyWalking's address with 9411 as the port. If you want to query Zipkin traces from SkyWalking, you need to enable the Zipkin traces query module by setting `query-zipkin` to `default` in `application.yml`, or by setting environment variable `SWQUERYZIPKIN=default` before starting OAP server: ```yaml query-zipkin: selector: ${SWQUERYZIPKIN:default} default: ``` After enabling Zipkin query module, SkyWalking listens on port 9412 for Zipkin query APIs, you can also query the Zipkin traces from SkyWalking UI, menu `Service Mesh --> Services --> Zipkin Trace`. When installing Istio, you can enable Zipkin tracing and point it to SkyWalking by setting ```shell istioctl install -y --set profile=demo \ --set meshConfig.defaultConfig.tracing.sampling=100 \ --set meshConfig.defaultConfig.tracing.zipkin.address=oap.istio-system.svc.cluster.local:9411 \ --set meshConfig.enableTracing=true ``` so that Istio proxy (Envoy) can generate traces and sent them to SkyWalking. For more details about Zipkin on Istio, refer to .
Project: Netdata (Observability and Analysis / Observability)
File: net.inet6.ip6.stats.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/integrations/net.inet6.ip6.stats.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/metadata.yaml" sidebar_label: "net.inet6.ip6.stats" learn_status: "Published" learnrelpath: "Collecting Metrics/FreeBSD" most_popular: False message: "DO NOT EDIT THIS FILE DIRECTLY, IT IS GENERATED BY THE COLLECTOR'S metadata.yaml FILE" endmeta--> <img src="https://netdata.cloud/img/network.svg" width="150"/> Plugin: freebsd.plugin Module: net.inet6.ip6.stats <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Collect information abou IPv6 stats. The plugin calls `sysctl` function to collect necessary data. This collector is supported on all platforms. This collector supports collecting metrics from multiple instances of this integration, including remote instances. This integration doesn't support auto-detection. The default configuration for this integration does not impose any limits on data collection. The default configuration for this integration is not expected to impose a significant performance impact on the system. Metrics grouped by scope. The scope defines the instance that the metric belongs to. An instance is uniquely identified by a set of labels. These metrics show general information about IPv6 connections. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | ipv6.packets | received, sent, forwarded, delivers | packets/s | | ipv6.fragsout | ok, failed, all | packets/s | | ipv6.fragsin | ok, failed, timeout, all | packets/s | | ipv6.errors | InDiscards, OutDiscards, InHdrErrors, InAddrErrors, InTruncatedPkts, InNoRoutes, OutNoRoutes | packets/s | There are no alerts configured by default for this integration. No action required. The configuration file name for this integration is `netdata.conf`. Configuration for this specific integration is located in the `[plugin:freebsd:net.inet6.ip6.stats]` section within that file. The file format is a modified INI syntax. The general structure is: ```ini [section1] option1 = some value option2 = some other value [section2] option3 = some third value ``` You can edit the configuration file using the `edit-config` script from the Netdata . ```bash cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata sudo ./edit-config netdata.conf ``` <details><summary>Config options</summary> | Name | Description | Default | Required | |:-|:--|:-|:--:| | ipv6 packets | Enable or disable ipv6 packet metric. | auto | no | | ipv6 fragments sent | Enable or disable ipv6 fragments sent metric. | auto | no | | ipv6 fragments assembly | Enable or disable ipv6 fragments assembly metric. | auto | no | | ipv6 errors | Enable or disable ipv6 errors metric. | auto | no | </details> There are no configuration examples.
Project: Grafana Loki (Observability and Analysis / Observability)
File: limit.md

title: limit menuTitle: description: The 'limit' Promtail pipeline stage. aliases: ../../../clients/promtail/stages/limit/ weight: The `limit` stage is a rate-limiting stage that throttles logs based on several options. This pipeline stage places limits on the rate or burst quantity of log lines that Promtail pushes to Loki. The concept of having distinct burst and rate limits mirrors the approach to limits that can be set for Loki's distributor component: `ingestionratemb` and `ingestionburstsize_mb`, as defined in . ```yaml limit: [rate: <int>] [burst: <int>] [bylabelname: <string>] [maxdistinctlabels: <int> | default = 10000] [drop: <bool> | default = false] ``` The following are examples showing the use of the `limit` stage. Simple `limit` stage configurations. Given the pipeline: ```yaml limit: rate: 10 burst: 10 ``` Would throttle any log line. Given the pipeline: ```yaml limit: rate: 10 burst: 10 drop: true ``` Would throttle any log line and drop logs when rate limit. Given the pipeline: ```yaml limit: rate: 10 burst: 10 drop: true bylabelname: "namespace" ``` Would ratelimit messages originating from each namespace independently. Any message without namespace label will not be ratelimited.
Project: Vector (Observability and Analysis / Observability)
File: 2021-04-21-vrl-abort.md

date: "2021-04-21" title: "Adding the `abort` keyword to VRL" description: "Aborting processing of events in `remap`" authors: ["jszwedko"] pr_numbers: [6723] release: "0.13.0" hideonrelease_notes: false badges: type: "new feature" domains: ["remap"] Vector 0.13 introduces a new to the [Vector Remap Language (VRL)][vrl]. This expression can be used to abort processing in a . This is useful for aborting processing of invalid events. By default, events that encounter an `abort` expression will be dropped by the , but this behavior can be modified to simply pass along the unmodified event to the next transform by setting `droponabort` to `false`. As an example, the `abort` expression can be used if you want to do some validation on the event before processing it, discarding any invalid events. Given a config of: ```toml [sources.in] type = "generator" format = "shuffle" interval = 1.0 lines = ['{ "message": "valid message", "type": "ok"}', '{ "message": "invalid message", "type": "unknown"}'] [transforms.remap] type = "remap" inputs = ["in"] source = """ . |= object!(parse_json!(string!(.message))) if .type != "ok" { abort # unknown type } """ [sinks.out] type = "console" inputs = ["remap"] encoding.codec = "json" ``` You would expect to see something like: ```json {"message":"valid message","timestamp":"2021-04-20T20:26:05.214875Z","type":"ok"} {"message":"valid message","timestamp":"2021-04-20T20:26:06.213879Z","type":"ok"} {"message":"valid message","timestamp":"2021-04-20T20:26:07.214254Z","type":"ok"} {"message":"valid message","timestamp":"2021-04-20T20:26:08.215219Z","type":"ok"} ``` That is, that all of the events that don't have a `type` of `ok`, would be dropped.
Project: Opstrace (Observability and Analysis / Observability)
File: sending-logs-with-promtail.md

In this guide we show how to configure a instance to securely send logs to your Opstrace cluster. An Opstrace cluster. A decision: for which Opstrace tenant would you like to send data? An Opstrace tenant authentication token file (for the tenant of your choice). Also see . Promtail can be instructed to send logs to an Opstrace cluster using the following basic configuration structure: ```yaml client: url: <string> bearertokenfile: <filename> tls_config: insecureskipverify: <boolean> ``` This is the tenant-specific data API endpoint of an Opstrace cluster for ingesting metrics. The endpoint URL is constructed using the tenant name and the cluster name: ```yaml url: https://loki.${TENANTNAME}.${CLUSTERNAME}.opstrace.io/loki/api/v1/push ``` Example: ```yaml url: https://loki.default.testcluster.opstrace.io/loki/api/v1/push ``` Your Opstrace cluster exposes the logs ingestion API securely. For authenticating the client towards the Opstrace cluster, the client has to present a tenant-specific data API authentication token with every request. To achieve that, we use the `bearertokenfile` parameter: Example: ```yaml bearertokenfile: /var/run/default-tenant/tenant-api-token-default ``` TLS is used for establishing a secure, private transport between the Promtail instance and the Opstrace cluster. By default, FluentD attempts to verify the certificate exposed by the Opstrace cluster against its trust store, for establishing authenticity of the Opstrace cluster towards Promtail. Depending on the `cert_issuer` cluster configuration option (see ) you may want to disable server certificate verification for testing purposes. This can be achieved via ```yaml tls_config: insecureskipverify: true ``` This is required for example when using `letsencrypt-staging` as `cert_issuer`.