cwielenb/CNCF-Dataset huggingface dataset:
Project: Netdata (Observability and Analysis / Observability)
File: vm.stats.sys.v_soft.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/integrations/vm.stats.sys.v_soft.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/metadata.yaml" sidebarlabel: "vm.stats.sys.vsoft" 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/freebsd.svg" width="150"/> Plugin: freebsd.plugin Module: vm.stats.sys.v_soft <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Software Interrupt vm.stats.sys.v_soft 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. This metric shows software interrupt frequency. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | system.soft_intr | interrupts | interrupts/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]` 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 option</summary> | Name | Description | Default | Required | |:-|:--|:-|:--:| | vm.stats.sys.v_soft | Enable or disable software inerrupts metric. | yes | no | </details> There are no configuration examples.
Project: Vector (Observability and Analysis / Observability)
File: splunk_hec_logs.md

title: Splunk HEC logs description: Deliver log data to Splunk's component_kind: sink layout: component tags: ["splunk", "hec", "http event collector", "component", "sink", "logs"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Checkmk (Observability and Analysis / Observability)
File: 16241.md

key | value | date | 2024-02-29T10:20:38+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes You're affected if you're monitoring your systemd units with an old agent and your unit is missing a descpription. Parsing may have failed with: ``` loadedstatus, activestatus, current_state, descr = remains.split(" ", 3) E ValueError: not enough values to unpack (expected 4, got 3) ``` This is fixed now.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: Laura_Henning.md

I started using LitmusChaos for a student project in November 2019 and have been observing its extraordinary evolution since then. My company does not yet have plans for adopting chaos engineering because the system we develop is in its early stages. So they kind of commissioned me to find a possible solution and implementation and above all gain knowledge. I came across LitmusChaos through the CNCF Landscape in my research for available open source tools. I did a quick assessment of other tools and found LitmusChaos to fulfill my requirements completely. The help I received from the MayaData developers during my early stages of "is it me or is there really a bug?" convinced me to invest more time in the community and even start constructing own chaoslibs. The presentation I recently held to my team (and many people in the video call I didn't know :D) earned me lots of positive feedback and a possible research question for my upcoming bachelor thesis. So let's see what the future has to offer!
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: cloudwatch.md

title: Amazon CloudWatch weight: 200 generated_file: true This plugin outputs logs or metrics to Amazon CloudWatch. For details, see . ```yaml spec: cloudwatch: awskeyid: valueFrom: secretKeyRef: name: logging-s3 key: awsAccessKeyId awsseckey: valueFrom: secretKeyRef: name: logging-s3 key: awsSecretAccessKey loggroupname: operator-log-group logstreamname: operator-log-stream region: us-east-1 autocreatestream true buffer: timekey: 30s timekey_wait: 30s timekeyuseutc: true ``` Create log group and stream automatically. Default: false AWS access key id Instance Profile Credentials call retries Default: nil AWS secret key. The role ARN to assume when using cross-account sts authentication The session name to use with sts authentication Default: 'fluentd' Enable AssumeRoleCredentials to authenticate, rather than the default credential hierarchy. See 'Cross-Account Operation' below for more detail. Use to set the number of threads pushing data to CloudWatch. Default: 1 Use this parameter to connect to the local API endpoint (for testing) Use to set an optional HTTP proxy Include time key as part of the log entry Default: UTC Name of the library to be used to handle JSON data. For now, supported libraries are json (default) and yaml Use localtime timezone for includetimekey output (overrides UTC default) Set a hash with keys and values to tag the log group resource Specified field of records as AWS tags for the log group Name of log group to store logs Specified field of records as log group name Output rejectedlogevents_info request log. Default: false Name of log stream to store logs Specified field of records as log stream name Maximum number of events to send at once Default: 10000 Maximum length of the message Keys to send messages as events If true, putlogeventsretrylimit will be ignored Maximum count of retry (if exceeding this, the events will be discarded) Time before retrying PutLogEvents (retry interval increases exponentially like putlogeventsretrywait * (2 ^ retry_count)) AWS Region Remove field specified by loggroupawstagskey Remove field specified by loggroupname_key Remove field specified by logstreamname_key Remove field specified by retentionindays Use to set the expiry time for log group when created with autocreatestream. (default to no expiry) Use specified field of records as retention period The threshold for chunk flush performance check. Parameter type is float, not time, default: 20.0 (seconds) If chunk flush takes longer time than this threshold, fluentd logs warning message and increases metric fluentdoutputstatusslowflush_count. Use tag as a group name Use tag as a stream name
Project: Checkmk (Observability and Analysis / Observability)
File: 16210.md

key | value | date | 2024-01-11T09:34:55+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | no Prior to this Werk, the REST API could delete non-empty folders without any further check. With this Werk, the endpoint now accepts the delete_method query parameter. The possible values are: recursive: Deletes the folder and all the elements it contains. abort_on_nonempty: Deletes the folder only if it is not empty If no delete_method is provided, recursive is asumed and the behaviour is the same as before this Werk. The enpoint will return a 409 status code when trying to delete a folder that contains hosts, rules, subfolders or is referenced by another object. Use example: `curl -X 'DELETE' 'http://example.com/mysite/checkmk/api/1.0/objects/folderconfig/myfolder?deletemetod=aborton_nonempty' -H 'accept: /`
Project: Grafana Loki (Observability and Analysis / Observability)
File: storage_size_calculator.md

This document demonstrates how to install storage size calculator for loki on OpenShift. Note: The storage size calculator works out of the box on OpenShift. Storage Size Calculator is used to have an idea on how to properly size a Loki cluster. It spins up a log collector that is used to collect metrics for a period of time and based on the amount of logs being collected, extrapolate the amount of logs required for a day and from that recommend a t-shirt size. Create a running OpenShift cluster. A container registry that you and your OpenShift cluster can reach. We recommend . Deploy the to the cluster. Create the `openshift-logging` namespace in the cluster: ```console kubectl create ns openshift-logging ``` Deploy the storage size calculator by executing following command in the terminal: ```console make deploy-size-calculator REGISTRYORGOPENSHIFT=$YOURQUAYORG ``` where `$YOURQUAYORG` is your personal account where you can push container images. You should see `log-file-metric-exporter-xxx` and `storage-size-calculator-xxx` pods running. Note: is used to collect metrics about container logs being produced in a kubernetes environment. It publishes `logloggedbytes_total` metric to prometheus. Now you can check the logs to see the recommended t-shirt size for your cluster: ```console kubectl -n openshift-logging logs <POD_NAME> ``` where `<POD_NAME>` is the name of the storage size calculator pod and can be found using: ```console kubectl -n openshift-logging get pods ``` Note: The storage size calculator logs the recommended t-shirt size every minute. To cleanup the deployment you can use: ```console make undeploy-size-calculator ``` This will cleanup the resources related to storage size calculator. However, the Loki Operator would still be running. If you want to contribute to the storage size calculator, you can follow this local development and testing process. Fork and clone the repo. All the files related to storage size calculator exists at and the main file is at . Update the code to fix a bug or add a new feature. To test the changes made, build the image and push it to quay. Replace the `image` value in with your quay image to test the changes. Build the image using: ```console make oci-build-calculator ``` This will build the storage size calculator image using Push the image to quay using: ```console make oci-push-calculator ``` After replacing the image name, deploy the storage size calculator to test your changes: ```console make deploy-size-calculator REGISTRYORGOPENSHIFT=$YOURQUAYORG ``` where `$YOURQUAYORG` is your personal account where you pushed your container image. If everything works fine then create a pull request. If you get `permission denied` error while running `make deploy-size-calculator` then make file executable by running: ```console chmod +x hack/deploy-prometheus-secret.sh ``` Now rerun the same `make deploy-size-calculator` again and it should work fine.
Project: Parseable (Observability and Analysis / Observability)
File: USERS.md

The following document is a list of users and adopters who use Parseable. The users themselves directly maintain the list. You can add your organization by editing this file directly. If you're using Parseable in your organization, please add your company name to this list. It really helps the project gain momentum and credibility. It's a small contribution to the project with a big impact. | Organization | Contact | Description of Use | | | - | | | | | Frontend application logging | | | | Centralized Kubernetes Logging | | | | Centralized application/infrastructure logging |
Project: Checkmk (Observability and Analysis / Observability)
File: 16350.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-04-12T11:07:00+00:00 level | 1 class | feature component | wato edition | cre Before this werk, the process of creating a Support Diagnostics Dump sometimes lead to a timeout exception. The hard-coded timeout was 110s. Now, it's possible to configure the timeout in the user interface.
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_disconnect_received_reason_not_normal.md

This alert is triggered when the number of not normal v5 DISCONNECT packets received by VerneMQ in the last minute is above a certain threshold. This indicates that there is an issue with MQTT clients connecting to your VerneMQ MQTT broker that requires attention. In the context of this alert, "not normal" refers to v5 DISCONNECT packets that were received with a reason code other than "normal disconnection", as specified in the MQTT v5 protocol. Normal disconnection refers to clients disconnecting gracefully without any issues. Inspect VerneMQ logs Check the VerneMQ logs for any relevant information about the MQTT clients that are experiencing not normal disconnects. This can provide important context to identify the root cause of the issue. ``` sudo journalctl -u vernemq ``` Check the MQTT clients Investigate the MQTT clients that are experiencing not normal disconnects. This may involve inspecting client logs or usage patterns, as well as verifying that the clients are using the correct MQTT version (v5) and have the appropriate configurations. Monitor VerneMQ metrics Use the VerneMQ metrics to monitor the broker's performance and identify any sudden spikes in abnormal disconnects or other relevant metrics. To view the VerneMQ metrics, access the VerneMQ admin interface, usually available at `http://<yourvernemqaddress>:8888/metrics`. Review network conditions Verify that there are no networking issues between the MQTT clients and the VerneMQ MQTT broker, as these issues could cause MQTT clients to disconnect unexpectedly. Review VerneMQ configuration Review your VerneMQ configuration to ensure it is correctly set up to handle the expected MQTT client load and usage patterns.
Project: Netdata (Observability and Analysis / Observability)
File: k8s_cgroup_ram_in_use.md

This alert monitors the `RAM usage` in a Kubernetes cluster by calculating the ratio of the memory used by a cgroup to its memory limit. If the memory usage exceeds certain thresholds, the alert triggers and indicates that the system's memory resources are under pressure. Check overall RAM usage in the cluster Use the `kubectl top nodes` command to check the overall memory usage on the cluster nodes: ``` kubectl top nodes ``` Identify Pods with high memory usage Use the `kubectl top pods --all-namespaces` command to identify Pods consuming a high amount of memory: ``` kubectl top pods --all-namespaces ``` Inspect logs for errors or misconfigurations Check the logs of Pods consuming high memory for any issues or misconfigurations: ``` kubectl logs -n <namespace> <pod_name> ``` Inspect container resource limits Review the resource limits defined in the Pod's yaml file, particularly the `limits` and `requests` sections. If you're not setting limits on Pods, then consider setting appropriate limits to prevent running out of resources. Scale or optimize applications If high memory usage is expected and justified, consider scaling the application by adding replicas or increasing the allocated resources. If the memory usage is not justified, optimizing the application code or configurations may help reduce memory usage.
Project: HertzBeat (Observability and Analysis / Observability)
File: extend-push.md

id: extend-push title: Push Style Custom Monitoring sidebar_label: Push Style Custom Monitoring Push style curstom monitor is a type of monitor which allow user to configure metrics format and push metrics to hertzbeat with their own service. Here we will introduce how to use this feature. Peer Server Start Pushing Metrics -> HertzBeat Push Module Stage Metrics-> HertzBeat Collect Module collect Metrics Periodically HertzBeat will parsing metrics with the format configured by user while adding new monitor. HertzBeat DashBoard -> Service Monitor -> Push Style Monitor -> New Push Style Monitor -> set Push Module Host (hertzbeat server ip, usually 127.0.0.1/localhost) -> set Push Module Port (hertzbeat server port, usually 1157) -> configure metrics field (unit: string, type: 0 number / 1 string) -> end
Project: Krkn (Observability and Analysis / Chaos Engineering)
File: ROADMAP.md

Following are a list of enhancements that we are planning to work on adding support in Krkn. Of course any help/contributions are greatly appreciated. to suggest scenarios having probability of impacting the service under test using profiling results [ ] Chaos AI integration to improve and automate test coverage [ ] Support for running all the scenarios of Kraken on Kubernetes distribution - see https://github.com/krkn-chaos/krkn/issues/185, https://github.com/redhat-chaos/krkn/issues/186 in terms of adding best practices, test environment recommendations and scenarios to make sure the OpenShift platform, as well the applications running on top it, are resilient and performant under chaotic conditions.
Project: SkyWalking (Observability and Analysis / Observability)
File: aws-firehose-receiver.md

AWS Firehose receiver listens on `0.0.0.0:12801` by default, and provides an HTTP Endpoint `/aws/firehose/metrics` that follows You could leverage the receiver to collect , and analysis it through as the receiver bases on Create CloudWatch metrics configuration for S3 (refer to ) Stream CloudWatch metrics to AWS Kinesis Data Firehose delivery stream by Specify AWS Kinesis Data Firehose delivery stream HTTP Endpoint (refer to ) Usually, the process flow with OAP is as follows: ``` CloudWatch metrics with S3 --> CloudWatch Metric Stream (OpenTelemetry formart) --> Kinesis Data Firehose Delivery Stream --> AWS Firehose receiver(OAP) --> OpenTelemetry receiver(OAP) ``` The following blogs demonstrate complete setup process for AWS S3 and API Gateway: | Description | Configuration File | Data Source | |--|-|| | Metrics of AWS Cloud S3 | otel-rules/aws-s3/s3-service.yaml | AWS CloudWatcher Metrics Stream -> AWS Firehose delivery stream -> SkyWalking OAP Server with | | Metrics of AWS DynamoDB | otel-rules/aws-dynamodb/dynamodb-service.yaml | AWS CloudWatcher Metrics Stream -> AWS Firehose delivery stream -> SkyWalking OAP Server with | | Metrics of AWS DynamoDB | otel-rules/aws-dynamodb/dynamodb-endpoint.yaml | AWS CloudWatcher Metrics Stream -> AWS Firehose delivery stream -> SkyWalking OAP Server with | | Metrics of AWS API Gateway | otel-rules/aws-gateway/gateway-service.yaml | AWS CloudWatcher Metrics Stream -> AWS Firehose delivery stream -> SkyWalking OAP Server with | | Metrics of AWS API Gateway | otel-rules/aws-gateway/gateway-endpoint.yaml | AWS CloudWatcher Metrics Stream -> AWS Firehose delivery stream -> SkyWalking OAP Server with | Only OpenTelemetry format is supported (refer to ) According to HTTPS requirement by AWS Firehose(refer to , users have two options A proxy(e.g. Nginx, Envoy) is required in front of OAP's Firehose receiver to accept HTTPS requests from AWS Firehose through port `443`. (Recommended based on the general security policy) Set `aws-firehose/enableTLS=true` with suitable cert/key files through `aws-firehose/tlsKeyPath` and `aws-firehose/tlsCertChainPath` at OAP side to accept requests from firehose directly. AWS Firehose receiver support setting accessKey for Kinesis Data Firehose, please refer to
Project: Checkmk (Observability and Analysis / Observability)
File: 16397.md

key | value | date | 2024-01-23T08:14:35+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Previously, the agent specialzerto would show the following error message in the CheckMK HW/SW Inventory ``` NOOPParser: Ignoring invalid data b'<<<zerto_agent:sep(0)>>>Initialized OK<<<<host1.example.com>>>> ``` Moreover, the service `Zerto Agent Status` was not discoverable and some piggyback data would incorrectly be mapped to the source host. This is now fixed.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: USERS.md

This is a list of users that are using & benefited by LitmusChaos. Please send a PR to this file (along with details ) to add yourselves. | User | Usecase | Details | | : | : | : | | |Reasearch on how to do chaos engineering in minikube clusters like | | | |Testing deployment designs for resiliency|Coming Soon!| | |Create Cloud Native Validation Suite on || | |Use LitmusChaos for Kafka Resiliency on Dev/Staging|| | |Ensure reliability of microservices|| | |Chaos Engineering Practice as SRE|| | |Performance Anomaly Detection in Cloud and Containerized Applications|Coming Soon!|
Project: Spring Cloud Sleuth (Observability and Analysis / Observability)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: '' assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-user_get_info_by_name.md

category: User apiurl: '/api/v1/user/name/#{user_name}' title: 'Get User info by name' type: 'GET' sample_doc: 'user.html' layout: default Required `Admin` usage ex. /api/v1/user/name/laiwei ```Status: 200``` ``` { "cnname": "laiwei8", "email": "laiwei8@xx", "id": 8, "im": "", "name": "laiwei8", "phone": "", "qq": "", "role": 0 }``` For more example, see the . For errors responses, see the .
Project: Elastic (Observability and Analysis / Observability)
File: README.md

The Tableau Connector works in tandem with the Elastic JDBC driver to facilitate the query of Elasticsearch. It gives users a simple way to query Elasticsearch data from Tableau. After providing basic connection and authentication information, users can easily select Elasticsearch indices for use in Tableau Desktop and Tableau Server. Tableau connector for Elasticsearch installation: Go to the page. Download the .taco connector file. Move the .taco file here: Windows: C:\Users\[Windows User]\Documents\My Tableau Repository\Connectors macOS: /Users/[user]/Documents/My Tableau Repository/Connectors Elasticsearch JDBC Driver Installation: Go to the page. Download the Elasticsearch JDBC Driver .jar file and move it into the following directory: Windows - C:\Program Files\Tableau\Drivers macOS - /Users/[user]/Library/Tableau/Drivers Relaunch Tableau and connect with Elasticsearch by Elastic.
Project: Loggie (Observability and Analysis / Observability)
File: PULL_REQUEST_TEMPLATE.md

XXXXX XX XXXX Follow this checklist to help us incorporate your contribution quickly and easily. Notice, `it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR`. filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue. [x] Format the pull request title like `[ISSUE #123] Fix UnknownException when host config not exist`. Each commit in the pull request should have a meaningful subject line and body. [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. [x] Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when a cross-module dependency exists. .