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

is a German multinational corporation, founded and headquartered in Herzogenaurach, Bavaria, that designs and manufactures shoes, clothing and accessories. In adidas, we started months ago with a new initiative about how to implement chaos engineering practices in order to provide the engineering teams a guide and tools about how to test the resilience of the applications through chaos engineering. With this goal in mind, we started to define some best practices and processes to be shared with our engineering team, and we started to evaluate a few tools. After an evaluation of different tools, we decided to go ahead with Litmus Chaos. Applications/Workloads or Infra that are being subjected to chaos by Litmus Litmus chaos will be provided by our platform team as part of their services. It will be running on kubernetes and will be available for engineering teams. Experiments, like pod deletion, network latency or packetloss, applied between functional dependencies like checkout & Payments, login, order creation... Not applied in production yet. We defined a set of priorities (with different value) and stoppers, we analyzed the tooling and selected the most valued one: Prio 1 & Stoppers if not: Full detailed documentation in English available, API / Shared Libraries, Control Injecting Failure, Permissions scope isolated, Authorization, chaos Scenarios - Parallel, works with: Kuberentes, OpenSource Prio 2: Installation and Management, Metrics / Reporting, Halt attack, Automatic rollback, High/admin permissions on the node, Chaos scenarios as code, chaos attacks - Serial, Custom or Specialized Attacks, Custom or Specialized Scenarios, Works with: AWS Prio 3: Access to the logs, Scheduling attacks, Health Checks, Application Attacks, Target Randomization, Network Attacks, VMs Attacks, Public API, Web UI Staging/pre-prod Planned to go to production and through CI/CD pipelines. If you would like your name (as standalone user) or organization name to be added to the Adopters.md, please provide a preferred contact handle like GitHub id, Twitter id, LinkedIn id, website etc.
Project: SkyWalking (Observability and Analysis / Observability)
File: backend-aws-s3-monitoring.md

Amazon Simple Storage Service (Amazon S3) is an object storage service. SkyWalking leverages to transfer the CloudWatch metrics of s3 to and into the . AWS CloudWatch collect metrics for S3, refer to stream CloudWatch metrics of S3 to AWS Kinesis Data Firehose AWS Kinesis Data Firehose delivery metrics to through the HTTP endpoint Create CloudWatch metrics configuration for S3, refer to Create an Amazon Kinesis Data Firehose Delivery Stream, and set 's address as HTTP(s) Destination, refer to Create CloudWatch metric stream, and select the Firehose Delivery Stream which has been created above, set `Select namespaces` to `AWS/S3`, `Select output format` to `OpenTelemetry 0.7`. refer to Read for more details SkyWalking observes CloudWatch metrics of the S3 bucket, which is cataloged as a `LAYER: AWS_S3` `Service` in the OAP. | Monitoring Panel | Unit | Metric Name | Catalog | Description | Data Source | |-|-|--|-|--|-| | 4xx Errors | count | awss34xx | Service | The number of HTTP 4xx client error status code requests made to the S3 bucket | | | 5xx Errors | count | awss35xx | Service | The number of HTTP 5xx client error status code requests made to the S3 bucket | | | Downloaded | bytes | awss3downloaded_bytes | Service | The number of bytes downloaded for requests made to an Amazon S3 bucket | | | Uploaded | bytes | awss3uploaded_bytes | Service | The number of bytes uploaded for requests made to an Amazon S3 bucket | | | Request Average Latency | bytes | awss3request_latency | Service | The average of elapsed per-request time from the first byte received to the last byte sent to an Amazon S3 bucket | | | First Byte Average Latency | bytes | awss3request_latency | Service | The average of per-request time from the complete request being received by an Amazon S3 bucket to when the response starts to be returned | | | All Requests | bytes | awss3delete_requests | Service | The number of HTTP All requests made for objects in an Amazon S3 bucket | | | Get Requests | bytes | awss3delete_requests | Service | The number of HTTP Get requests made for objects in an Amazon S3 bucket | | | Put Requests | bytes | awss3delete_requests | Service | The number of HTTP PUT requests made for objects in an Amazon S3 bucket | | | Delete Requests | bytes | awss3delete_requests | Service | The number of HTTP Delete requests made for objects in an Amazon S3 bucket | | You can customize your own metrics/expression/dashboard panel. The metrics definition and expression rules are found in `/config/otel-rules/aws-s3/`. The AWS Cloud EKS dashboard panel configurations are found in `/config/ui-initialized-templates/aws_s3`.
Project: Netdata (Observability and Analysis / Observability)
File: mdstat_mismatch_cnt.md

This alert presents the number of unsynchronized blocks for the RAID array in crisis. Receiving this alert indicates a high number of unsynchronized blocks for the RAID array. This might indicate that data on the array is corrupted. This alert is raised to warning when the metric exceeds 1024 unsynchronized blocks. There is no standard approach to troubleshooting this alert because the reasons can be various. For example, one of the reasons might be a swap on the array, which is relatively harmless. However, this alert can also be triggered by hardware issues which can lead to many problems and inconsistencies between the disks.
Project: Netdata (Observability and Analysis / Observability)
File: netfilter.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/nfacct.plugin/README.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/nfacct.plugin/metadata.yaml" sidebar_label: "Netfilter" learn_status: "Published" learnrelpath: "Collecting Metrics/Linux Systems/Firewall" 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/netfilter.png" width="150"/> Plugin: nfacct.plugin Module: nfacct.plugin <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Monitor Netfilter metrics for optimal packet filtering and manipulation. Keep tabs on packet counts, dropped packets, and error rates to secure network operations. Netdata uses libmnl (https://www.netfilter.org/projects/libmnl/index.html) to collect information. This collector is supported on all platforms. This collector supports collecting metrics from multiple instances of this integration, including remote instances. This plugin needs setuid. This plugin uses socket to connect with netfilter to collect data 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. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | netfilter.netlink_new | new, ignore, invalid | connections/s | | netfilter.netlinkchanges | insert, delete, deletelist | changes/s | | netfilter.netlinksearch | searched, searchrestart, found | searches/s | | netfilter.netlinkerrors | icmperror, insertfailed, drop, earlydrop | events/s | | netfilter.netlink_expect | created, deleted, new | expectations/s | | netfilter.nfacct_packets | a dimension per nfacct object | packets/s | | netfilter.nfacct_bytes | a dimension per nfacct object | kilobytes/s | There are no alerts configured by default for this integration. Install `libmnl-dev` and `libnetfilter-acct-dev` using the package manager of your system. The configuration file name for this integration is `netdata.conf`. Configuration for this specific integration is located in the `[plugin:nfacct]` 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 | |:-|:--|:-|:--:| | update every | Data collection frequency. | 1 | no | | command options | Additinal parameters for collector | | no | </details> There are no configuration examples.
Project: Vector (Observability and Analysis / Observability)
File: 2021-02-16-filter-remap-support.md

title: "Remap support for the `filter` transform" description: "Use VRL to specify conditions for filtering events in a stream" date: "2021-02-16" authors: ["lucperkins"] pr_numbers: [] release: "0.12.0" hideonrelease_notes: false badges: type: "enhancement" transforms: ["filter"] The transform for Vector enables you to winnow down a stream of events to only those that match a specified condition. Previously, the `filter` transform required you to specify conditions using `check_fields`. But now you can use Vector Remap Language expressions in the transform to specify those conditions. This should make using `filter` more natural and expressive. The example configuration below shows the same `filter` transform using the old system (`check_fields`) and the new system (`remap`): ```toml [transforms.filteroutnon_critical] type = "filter" inputs = ["http-server-logs"]f condition.type = "check_fields" condition.message.status_code.ne = 200 condition.message.severity.ne = "info" condition.message.severity.ne = "debug" condition.type = "remap" condition.source = '.status_code != 200 && !includes(["info", "debug"], .severity)' ```
Project: Grafana Tempo (Observability and Analysis / Observability)
File: estimate-cardinality.md

title: Estimate cardinality from traces menuTitle: Estimate cardinality description: Service graphs help you understand the structure of a distributed system and the connections and dependencies between its components. weight: 300 Cardinality can pose a problem when you have lots of services. There isn't a direct formula or solution to this issue. The following guide should help estimate the cardinality that the feature will generate. For more information on cardinality, refer to the documentation. The amount of edges depends on the number of nodes in the system and the direction of the requests between them. Lets call this amount hops. Every hop will be a unique combination of client + server labels. For example: A system with 3 nodes `(A, B, C)` of which A only calls B and B only calls C will have 2 hops `(A B, B C)` A system with 3 nodes `(A, B, C)` that call each other (i.e., all bidirectional link) will have 6 hops `(A B, B A, B C, C B, A C, C A)` We cant calculate the amount of hops automatically based upon the nodes, but it should be a value between `#services - 1` and `#services!`. If we know the amount of hops in a system, we can calculate the cardinality of the generated (assuming `#hb` is the number of histogram buckets): ``` tracesservicegraphrequesttotal: #hops tracesservicegraphrequestfailed_total: #hops tracesservicegraphrequestserver_seconds: #hb * #hops tracesservicegraphrequestclient_seconds: #hb * #hops tracesservicegraphunpairedspans_total: #services (absolute worst case) tracesservicegraphdroppedspans_total: #services (absolute worst case) ``` Finally, we get the following cardinality estimation: ``` Sum: [([2 #hb] + 2) #hops] + [2 * #services] ``` {{% admonition type="note" %}} If `enablemessagingsystemlatencyhistogram` configuration is set to `true`, another histogram is produced: ``` tracesservicegraphrequestmessagingsystemseconds: #hb * #hops ``` In that case, the estimation formula would be: ``` Sum: [([3 #hb] + 2) #hops] + [2 * #services] ``` {{% /admonition %}} {{< admonition type="note" >}} To estimate the number of metrics, refer to the documentation. {{% /admonition %}}
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-host_maintain.md

category: Host apiurl: '/api/v1/host/maintain' title: "Set host maintain by ids or hostnames" type: 'POST' sample_doc: 'host.html' layout: default Required ``` { "ids": [1,2,3,4], "maintain_begin": 1497951907, "maintain_end": 1497951907 } ``` or ``` { "hosts": ["host.a","host.b"], "maintain_begin": 1497951907, "maintain_end": 1497951907 } ``` ```Status: 200``` ```{ "message": "Through: hosts, Affect row: 2" }```
Project: Checkmk (Observability and Analysis / Observability)
File: 16580.md

key | value | date | 2024-03-20T10:34:20+00:00 version | 2.4.0b1 class | fix edition | cre component | multisite level | 1 compatible | yes Prior to this Werk, if no events were found, the event statistics dashlet was drawn empty. This Werk corrects that behaviour and if no events are found, the graph should show with a count of zero.
Project: Checkmk (Observability and Analysis / Observability)
File: 16611.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-03-27T09:39:50+00:00 level | 1 class | fix component | notifications edition | cre When a user tries to access the notification setup page where a rule is listed for which the user does not have access rights, the page would crash making any changes impossible. With this werk, the table generation is fixed and the page will no longer crash the GUI.
Project: Loggie (Observability and Analysis / Observability)
File: VERSIONING.md

Semantic Versioning, commonly known as SemVer, is a great idea that has been very widely adopted as a way to decide how to name software versions. The whole concept is very well summarized on semver.org with the following lines: Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. Unfortunately, API changes are not the most important changes for libraries that serialize data for later consumption. For these libraries, such as BadgerDB, changes to the API are much easier to handle than change to the data format used to store data on disk. Serialization Versioning, like Semantic Versioning, uses 3 numbers and also calls them MAJOR.MINOR.PATCH, but the semantics of the numbers are slightly modified: Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make changes that require a transformation of the dataset before it can be used again. MINOR version when old datasets are still readable but the API might have changed in backwards-compatible or incompatible ways. PATCH version when you make backwards-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. Following this naming strategy, migration from v1.x to v2.x requires a migration strategy for your existing dataset, and as such has to be carefully planned. Migrations in between different minor versions (e.g. v1.5.x and v1.6.x) might break your build, as the API might have changed, but once your code compiles there's no need for any data migration. Lastly, changes in between two different patch versions should never break your build or dataset. For more background on our decision to adopt Serialization Versioning, read the blog post and the original proposal on .
Project: Netdata (Observability and Analysis / Observability)
File: systemd_swap_unit_failed_state.md

This alert monitors the state of your `systemd` swap units and is triggered when a swap unit is in the `failed` state. If you receive this alert, it means that you have an issue with one or more of your swap units managed by `systemd`. A swap unit in Linux is a dedicated partition or a file on the filesystem (called a swap file) used for expanding system memory. When the physical memory (RAM) gets full, the Linux system swaps some of the least used memory pages to this swap space, allowing more applications to run without the need for extra physical memory. If a `systemd` swap unit is in the `failed` state, it means that there was an issue initializing or activating the swap space. This might be due to configuration issues, disk space limitations, or filesystem errors. Check the status of the swap units: To list the swap units and their states, run the following command: ``` systemctl list-units --type=swap ``` Look for the failed swap units and note their names. Investigate the failed swap units: For each failed swap unit, check its status and any relevant messages by running: ``` systemctl status <swapunitname> ``` Replace `<swapunitname>` with the name of the failed swap unit. Check system logs: Examine the system logs for any errors or information related to the failed swap units with: ``` journalctl -xeu <swapunitname> ``` Identify the issue and take corrective actions: Based on the information from the previous steps, you may need to: Adjust swap unit configurations Increase disk space or allocate a larger swap partition Resolve disk or filesystem issues Restart the swap units Verify that the swap units are working: After resolving the issue, ensure the swap units are active and running by repeating step 1.
Project: Trickster (Observability and Analysis / Observability)
File: tls.md

Trickster supports TLS on both the frontend server and backend clients. To enable the TLS server, you must specify the `tlslistenport`, and optionally, the `tlslistenaddress` in the `frontend` section of your config file. For example: ```yaml frontend: listen_port: 8480 tlslistenport: 8483 ``` Note, Trickster will only start listening on the TLS port if at least one origin has a valid certificate and key configured. Each origin section of a Trickster config file can be augmented with the optional `tls` section to modify TLS behavior for front-end and back-end requests. For example: ```yaml backends: example: # example backend tls: # TLS settings for example backend fullchaincert_path: '/path/to/my/cert.pem' privatekeypath: '/path/to/my/key.pem' insecureskipverify: true certificateauthoritypaths: [ '/path/to/ca1.pem', '/path/to/ca2.pem' ] clientcertpath: '/path/to/client/cert.pem' clientkeypath: '/path/to/client/key.pem' ``` Each backend can handle encryption with exactly 1 certificate and key pair, as configured in the TLS section of the backend config (demonstrated above). If the path to any configured Certificate or Key file is unreachable or unparsable, Trickster will exit upon startup with an error providing reasonable context. You may use the same TLS certificate and key for multiple backends, depending upon how your Trickster configurations are laid out. Any certificates configured by Trickster must match the hostname header of the inbound http request (exactly, or by wildcard interpolation), or clients will likely reject the certificate for security issues. Each backend's TLS configuration can also configure the https client used for making requests against the origin as demonstrated above. `insecureskipverify` will instruct the http client to ignore hostname verification issues with the upstream origin's certificate, and process the request anyway. This is analogous to `-k | --insecure` in curl. `certificateauthoritypaths` will provide the http client with a list of certificate authorities (used in addition to any OS-provided root CA's) to use when determining the trust of an upstream origin's TLS certificate. In all cases, the Root CA's installed to the operating system on which Trickster is running are used for trust by the client. To us Mutual Authentication with an upstream origin server, configure Trickster with Client Certificates using `clientcertpath` and `clientkeypath` parameters, as shown above. You will likely need to also configure a custom CA in `certificateauthoritypaths` to represent your certificate signer, unless it has been added to the underlying Operating System's CA list.
Project: Netdata (Observability and Analysis / Observability)
File: kubelet_1m_pleg_relist_latency_quantile_05.md

This alert is related to Kubernetes and is triggered when the average `Pod Lifecycle Event Generator (PLEG)` relisting latency over the last minute is higher than the expected threshold (quantile 0.5). If you receive this alert, it means that the kubelet is experiencing some latency issues, which may affect the scheduling and management of your Kubernetes Pods. The Pod Lifecycle Event Generator (PLEG) is a component within the kubelet responsible for keeping track of changes (events) to the Pod and updating the kubelet's internal status. This ensures that the kubelet can successfully manage and schedule Pods on the Kubernetes node. Relisting latency refers to the time taken by the PLEG to detect, process, and update the kubelet about the events or changes in a Pod's lifecycle. High relisting latency can lead to delays in the kubelet reacting to these changes, which can affect the overall functioning of the Kubernetes cluster. Check the kubelet logs for any errors or warnings related to PLEG: ``` sudo journalctl -u kubelet ``` Look for any logs related to PLEG delays, issues, or timeouts. Restart the kubelet if necessary: ``` sudo systemctl restart kubelet ``` Sometimes, restarting the kubelet can resolve sporadic latency issues. Monitor the Kubernetes node's resource usage (CPU, Memory, Disk) using `kubectl top nodes`: ``` kubectl top nodes ``` If the node's resource usage is too high, consider scaling your cluster or optimizing workloads. Check the overall health of your Kubernetes cluster: ``` kubectl get nodes kubectl get pods --all-namespaces ``` These commands will help you identify any issues with other nodes or Pods in your cluster. Investigate the specific Pods experiencing latency in PLEG: ``` kubectl describe pod <pod_name> -n <namespace> ``` Look for any signs of the Pod being stuck in a pending state, startup issues, or container crashes.
Project: Checkmk (Observability and Analysis / Observability)
File: 16640.md

key | value | date | 2024-03-14T14:49:51+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | no To better support the combination of different validation functions, FormSpecs now expect a sequence of validation functions instead of just one for `custom_validate`. The validation of empty inputs is now handled in the new validator `LengthInRange` instead of `DisallowEmpty`. If you used ``` custom_validate=DisallowEmpty() ``` before, use ``` customvalidate=LengthInRange(minvalue=1) ``` now. For consistency, `InRange` is renamed to `NumberInRange`
Project: Vector (Observability and Analysis / Observability)
File: amazon-linux.md

title: Install Vector on Amazon Linux short: Amazon Linux supported_installers: ["YUM", "RPM", "Docker", "Vector installer"] weight: 1 The is a supported and maintained Linux image provided by Amazon Web Services for use on Amazon Elastic Compute Cloud (Amazon EC2). It's designed to provide a stable, secure, and high-performance execution environment for applications running on Amazon EC2. This page covers installing and managing Vector on the Amazon Linux operating system. {{< supported-installers >}}