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

<table> <tr> <th>Commands</th> <th>Description</th> <th>Time Taken</th> </tr> <tr> <td>/run-unit</td> <td>This command is used for executing all unit tests using Cypress.</td> <td>Moderate</td> </tr> <tr> <td>/run-e2e-AuthTests</td> <td>This Command is used for executing all Auth-Related e2e-tests (Login and Welcome Modal functionalities) using Cypress by building and deploying the respective PR in a KinD Cluster.</td> <td>Depends on Changes in the PR ( If changes are done in frontend, It can take more than 11 mins.), moderate in other cases.</td> </tr> <tr> <td>/run-e2e-Settings</td> <td>This Command is used for executing all Settings and Teaming Related e2e-tests using Cypress by building and deploying the respective PR in a KinD Cluster.</td> <td>Depends on Changes in the PR ( If changes are done in frontend, It can take more than 11 mins.), moderate in other cases.</td> </tr> <tr> <td>/run-e2e-all</td> <td>This Command is used for executing all e2e-tests using Cypress by building and deploying the respective PR in a KinD Cluster.</td> <td>Depends on Changes in the PR ( If changes are done in frontend, It can take more than 11 mins.), moderate in other cases.</td> </tr> </table>
Project: Netdata (Observability and Analysis / Observability)
File: users.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/apps.plugin/integrations/users.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/apps.plugin/metadata.yaml" sidebar_label: "Users" learn_status: "Published" learnrelpath: "Collecting Metrics/Processes and System Services" 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/users.svg" width="150"/> Plugin: apps.plugin Module: users <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> This integration monitors resource utilization on a user context. 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 refer to the user. Labels: | Label | Description | |:--|:-| | user | The name of the user. | Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | user.cpu_utilization | user, system | percentage | | user.cpuguestutilization | guest | percentage | | user.cpucontextswitches | voluntary, involuntary | switches/s | | user.mem_usage | rss | MiB | | user.memprivateusage | mem | MiB | | user.vmem_usage | vmem | MiB | | user.mempagefaults | minor, major | pgfaults/s | | user.swap_usage | swap | MiB | | user.diskphysicalio | reads, writes | KiB/s | | user.disklogicalio | reads, writes | KiB/s | | user.processes | processes | processes | | user.threads | threads | threads | | user.fdsopenlimit | limit | percentage | | user.fds_open | files, sockets, pipes, inotifies, event, timer, signal, eventpolls, other | fds | | user.uptime | uptime | seconds | | user.uptime_summary | min, avg, max | seconds | There are no alerts configured by default for this integration. No action required. There is no configuration file. There are no configuration options. There are no configuration examples.
Project: Netdata (Observability and Analysis / Observability)
File: vcsa_database_storage_health.md

The `vcsadatabasestorage_health` alert monitors the health of database storage components in a VMware vCenter Server Appliance (vCSA). When this alert is triggered, it indicates that one or more components have a health status of Warning, Critical or Unknown. Unknown (`-1`): The system is unable to determine the component's health status. Healthy (`0`): The component is functioning correctly and has no known issues. Warning (`1`): The component is currently operating but may be experiencing minor problems. Critical (`2`): The component is degraded and might have significant issues affecting functionality. Critical (`3`): The component is unavailable or expected to stop functioning soon, requiring immediate attention. No health data (`4`): There is no health data available for the component. Identify the affected components: To begin troubleshooting the alert, you need to identify which components are experiencing health issues. You can check the vCenter Server Appliance Management Interface (VAMI) to review the health status of all components. Access the VAMI by navigating to `https://<appliance-IP>/ui` in your web browser. Log in with your vCenter credentials. Click on the `Health` tab in the left-hand menu to view the health status of all components. Investigate the issues: Once you have identified the affected components, review the alarms and events in vCenter to determine the root cause of the problems. Pay close attention to any recent changes or updates that may have impacted system functionality. Review the vCenter Server logs: If necessary, examine the logs in vCenter Server to gather more information about any possible issues. The logs can be accessed via SSH, the VAMI, or using the Log Browser in the vSphere Web Client. Take corrective actions: Based on your findings from the previous steps, address the issues affecting the health status of the components. In the case of insufficient storage, increasing the storage capacity or deleting unnecessary files might resolve the problem. If the issues are caused by hardware failures, consider replacing or repairing the affected hardware components. For software-related issues, ensure that all components are up-to-date and properly configured. Monitor the component health: After taking corrective actions, continue to monitor the health statuses of the affected components through the VAMI to ensure that the issues have been successfully resolved.
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_subscribe_error.md

This alert is related to `VerneMQ`, the open-source, distributed MQTT message broker. If you receive this alert, it means that the number of failed v3/v5 `SUBSCRIBE` operations has increased in the last minute. MQTT v3 and v5 are different versions of the MQTT protocol, used for the Internet of Things (IoT) devices and their communication. The `SUBSCRIBE` operation allows a client (device) to subscribe to a specific topic and receive messages published under that topic. Check the VerneMQ logs Identify the location of the VerneMQ logs. The default location is `/var/log/vernemq`. If you have changed the default location, you can find it in the `vernemq.conf` file by looking for `log.console.file` and `log.error.file`. ``` grep log.console.file /etc/vernemq/vernemq.conf grep log.error.file /etc/vernemq/vernemq.conf ``` Analyze the logs for any errors or issues related to the `SUBSCRIBE` operation: ``` tail -f /path/to/vernemq/logs ``` Check the system resources Check the available resources (RAM and CPU) on your system: ``` top ``` If you find that the system resources are low, consider adding more resources or stopping unnecessary processes/applications. Check the client-side logs Most MQTT clients (e.g., Mosquitto, Paho, MQTT.js) provide their logs to help you identify any issues related to the `SUBSCRIBE` operation. Analyze the client logs for errors in connecting, subscribing, or receiving messages from the MQTT broker. Analyze the topics and subscriptions Verify if there are any invalid, restricted, or forbidden topics in your MQTT broker. Check the ACLs (Access Control Lists) and client authentication settings in your VerneMQ `vernemq.conf` file. ``` grep -E '^(allowanonymous|vmqacl.aclfile|vmqpasswd.password_file)' /etc/vernemq/vernemq.conf ``` Ensure the `ACLs` and authentication configuration are correct and allow the clients to subscribe to the required topics.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_cluster.KubeOwnerReference.md

title: "Interface: KubeOwnerReference" linkTitle: "KubeOwnerReference" slug: "libk8scluster.KubeOwnerReference" .KubeOwnerReference apiVersion: `string` API version of the referent. _ blockOwnerDeletion: `boolean` If true, AND if the owner has the "foregroundDeletion" finalizer, then the owner cannot be deleted from the key-value store until this reference is removed. `see` for how the garbage collector interacts with this field and enforces the foreground deletion. Defaults to false. To set this field, a user needs "delete" permission of the owner, otherwise 422 (Unprocessable Entity) will be returned. _ controller: `boolean` If true, this reference points to the managing controller. _ kind: `string` Kind of the referent. _ name: `string` Name of the referent. _ uid: `string` UID of the referent.
Project: Sidekick (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: Checkmk (Observability and Analysis / Observability)
File: 16601.md

key | value | date | 2024-03-19T07:49:40+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes The McAfee Web Gateway has been rebranded to Skyhigh Secure Web Gateway with its release 12.2.2. The base OID has been changed from `.1.3.6.1.4.1.1230` to `.1.3.6.1.4.1.59732`. Where possibile the "McAfee" string has been removed in favor of more generic therms. The old plugin names and ruleset names have been kept for compatibility/history-keeping reasons.
Project: Checkmk (Observability and Analysis / Observability)
File: 16506.md

key | value | date | 2024-02-21T11:56:07+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes There was a problem during service discovery which prevented Checkmk from assigning the AWS EC2 and ELB tags delivered by the AWS agent to their respective piggyback hosts. This werk fixes the discovery process such that the data is parsed properly and custom tags from AWS will now show up as host labels on the created piggyback hosts.
Project: Checkmk (Observability and Analysis / Observability)
File: 16697.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-04-23T06:07:04+00:00 level | 1 class | fix component | multisite edition | cre If both filters "Multiple sites" and "Sites" were set, the "Multiple sites" filter was used, even if empty.
Project: Netdata (Observability and Analysis / Observability)
File: dnsmasq_dhcp_dhcp_range_utilization.md

This alert indicates that the number of leased IP addresses in your DHCP range, managed by dnsmasq, is close to the total number of provisioned DHCP addresses. The alert will be triggered in a warning state when the percentage of leased IP addresses is between 80-90% and in a critical state when it is between 90-95%. Dynamic Host Configuration Protocol (DHCP) is a network management protocol that dynamically assigns IP addresses and other configuration information to devices connected to the network. It helps network administrators to manage the IP address allocation process efficiently. `dnsmasq` is a lightweight, easy to configure DNS forwarder, DHCP server, and TFTP server. It is designed to provide DNS and optionally, DHCP, services to a small-scale network. Dnsmasq can serve the names of local machines which are not in the global DNS. Check the current DHCP lease utilization To see the current percentage of DHCP leases in use, run the following command: ``` cat /var/lib/misc/dnsmasq.leases | wc -l ``` Verify the configured DHCP range Check the `/etc/dnsmasq.conf` file to ensure that the DHCP range is configured correctly: ``` grep -i "dhcp-range" /etc/dnsmasq.conf ``` Make sure that the range provides enough IP addresses for the number of devices in your network. Increase the DHCP range If required, increase the number of available IP addresses within the DHCP range by modifying the `/etc/dnsmasq.conf` file, expanding the range and/or decreasing the lease time. After modifying the configuration, restart the dnsmasq service to apply the changes: ``` sudo systemctl restart dnsmasq ``` Monitor the DHCP lease utilization Keep monitoring the DHCP lease utilization to ensure that the new range and lease settings are sufficient for your network's needs.
Project: Centreon (Observability and Analysis / Observability)
File: statistics.md

This module aims to deal with statistics collection of Centreon Engine and Broker. | Directive | Description | Default value | | : | : | :-- | | brokercachedir | Path to the Centreon Broker statistics directory (local) use to store node's broker statistics | `/var/lib/centreon/broker-stats/` | The configuration needs a cron definition to unsure that statistics collection will be done cyclically. ```yaml name: statistics package: "gorgone::modules::centreon::statistics::hooks" enable: false brokercachedir: "/var/lib/centreon/broker-stats/" cron: id: broker_stats timespec: "/5 *" action: BROKERSTATS parameters: timeout: 10 collect_localhost: false ``` | Event | Description | | :-- | :-- | | STATISTICSREADY | Internal event to notify the core | | BROKERSTATS | Collect Centreon Broker statistics files on node | | Endpoint | Method | | : | :-- | | /centreon/statistics/broker | `GET` | | /centreon/statistics/broker/:id | `GET` | | Header | Value | | :-- | : | | Accept | application/json | | Variable | Description | | :- | : | | id | Identifier of the node | ```bash curl --request POST "https://hostname:8443/api/centreon/statistics/broker" \ --header "Accept: application/json" ``` ```bash curl --request POST "https://hostname:8443/api/centreon/statistics/broker/2" \ --header "Accept: application/json" ```
Project: Weave Scope (Observability and Analysis / Observability)
File: LICENSE.md

Copyright (c) 2014-2015, Philip Hofer Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_publish_errors.md

This alert monitors the number of failed v3/v5 PUBLISH operations in the last minute for VerneMQ, an MQTT broker. If you receive this alert, it means that there is an issue with the MQTT message publishing process in your VerneMQ broker. MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol designed for constrained devices and low-bandwidth, high latency, or unreliable networks. It is based on the publish-subscribe model, where clients (devices or applications) can subscribe and publish messages to topics. VerneMQ is a high-performance, distributed MQTT message broker. It is designed to handle thousands of concurrent clients while providing low latency and high throughput. Check the VerneMQ log files for any error messages or warnings related to the MQTT PUBLISH operation failures. The log files are usually located in the `/var/log/vernemq` directory. ``` sudo tail -f /var/log/vernemq/vernemq.log ``` Check VerneMQ metrics to identify any bottlenecks in the system's performance. You can do this by using the `vmq-admin` tool, which comes with VerneMQ. Run the following command to get an overview of the broker's performance: ``` sudo vmq-admin metrics show ``` Pay attention to the metrics related to PUBLISH operation failures, such as `mqtt.publish.error_code.*`. Assess the performance of connected clients. Use the `vmq-admin` tool to list client connections along with details like the client's state and the number of published messages: ``` sudo vmq-admin session show --clientid --isonline --isauthenticated --sessionpublish_errors ``` Investigate the clients with `sessionpublisherrors` to find out if there's an issue with specific clients. Review your MQTT topic configuration, such as the retained flag, QoS levels, and the permissions for publishing to ensure your setup aligns with the intended behavior. If the issue persists or requires further investigation, consider examining the network conditions, such as latency or connection issues, which might hinder the MQTT PUBLISH operation's efficiency.
Project: Checkmk (Observability and Analysis / Observability)
File: 16446.md

key | value | compatible | yes version | 2.3.0b1 date | 2024-01-25T09:19:59+00:00 level | 1 class | fix component | wato edition | cme If the customer field of a rule pack is configured then - after "save" - it's gone. This bug was introduced with Checkmk 2.2.0 and has been fixed now.
Project: Grafana (Observability and Analysis / Observability)
File: disconnect-values.md

title: Disconnect values Choose whether to set a threshold above which values in the data should be disconnected. {{< figure src="/media/docs/grafana/screenshot-grafana-10-1-disconnect-values.png" max-width="750px" alt="Disconnect values options" >}} Never: Time series data points in the data are never disconnected. Threshold: Specify a threshold above which values in the data are disconnected. This can be useful when desired values in the data are of a known size and/or within a known range, and values outside this range should no longer be connected.
Project: OpenTelemetry (Observability and Analysis / Observability)
File: using-github-extensions.md

In OpenTelemetry it is critically important to preserve code integrity, including copyright. Extensions, apps, or bots that can arbitrarily modify code are NOT allowed. Read-only code access, opening pull requests from another fork, or bug triage bots can be considered to be installed. The default answer for installing third party tools in the org is "NO". Justification needs to be provided and supported by multiple org members. Open an issue at https://github.com/open-telemetry/community/issues Include reasoning and SIG(s) requesting this List permissions required by this extension, app, or bot. If possible: point to other uses of this extensions in OSS. Requests from maintainers typically carry higher weight; please make sure to discuss in the SIG you participate. If a third-party tool is requested for a specific repository, it is recommended to tag that repository's maintainers and ask them to +1 the request, such that there is a consensus among the majority of maintainers on adding the tool. GC member needs to approve with no other GC members raising concerns. It is recommended to discuss each extension, app, or bot that is about to be installed at GC meeting for awareness. Once GC approval received, TC member will install the extension. Many GitHub Action workflows do not require a dedicated GitHub account. Good examples are auto-assign workflows for issues and PRs such as . If your workflow does require a dedicated GitHub account, you should use . See for more details. We didn't encounter these requests yet. The policy will be created once it will become a problem.
Project: Vector (Observability and Analysis / Observability)
File: datadog_agent.md

title: Datadog agent description: Receive logs, metrics, and traces collected by a component_kind: source layout: component tags: ["datadog", "agent", "component", "source", "logs", "metrics", "traces"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Grafana Tempo (Observability and Analysis / Observability)
File: _index.md

title: Troubleshoot Tempo menuTitle: Troubleshoot description: Learn how to troubleshoot operational issues for Grafana Tempo. weight: 700 aliases: ../operations/troubleshooting/ This section helps with day zero operational issues that may come up when getting started with Tempo. The documents walk you through debugging each part of the ingestion and query pipeline to diagnose issues. In addition, the can help with remediating operational issues.
Project: OpenLLMetry (Observability and Analysis / Observability)
File: MAINTAINERS.md

This document contains a list of maintainers in this repo. If you're interested in contributing, and becoming a maintainer, see . | Maintainer | GitHub ID | Email | | -- | | | | Nir Gazit | | nir@traceloop.com | | Gal Kleinman | | gal@traceloop.com | | Tomer Friedman | | tomer@traceloop.com | | Paolo Rechia | | paolorechia@gmail.com |
Project: OpenSearch (Observability and Analysis / Observability)
File: MAINTAINERS.md

This document contains a list of maintainers in this repo. See that explains what the role of maintainer means, what maintainers do in this and other repos, and how they should be doing it. If you're interested in contributing, and becoming a maintainer, see . | Maintainer | GitHub ID | Affiliation | | | - | -- | | Anas Alkouz | | Amazon | | Andrew Ross | | Amazon | | Andriy Redko | | Aiven | | Bukhtawar Khan | | Amazon | | Charlotte Henkle | | Amazon | | Dan Widdis | | Amazon | | Daniel "dB." Doubrovkine | | Amazon | | Gaurav Bafna | | Amazon | | Kunal Kotwani | | Amazon | | Marc Handalian | | Amazon | | Michael Froh | | Amazon | | Nick Knize | | Amazon | | Owais Kazi | | Amazon | | Peter Nied | | Amazon | | Rishikesh Pasham | | Amazon | | Sachin Kale | | Amazon | | Sarat Vemulapalli | | Amazon | | Shweta Thareja | | Amazon | | Sorabh Hamirwasia | | Amazon | | Suraj Singh | | Amazon | | Tianli Feng | | Amazon | | Vacha Shah | | Amazon | | Maintainer | GitHub ID | Affiliation | | | -- | -- | | Megha Sai Kavikondala | | Amazon | | Xue Zhou | | Amazon | | Kartik Ganesh | | Amazon | | Abbas Hussain | | Meta | | Himanshu Setia | | Amazon | | Ryan Bogan | | Amazon | | Rabi Panda | | Independent |