cwielenb/CNCF-Dataset huggingface dataset:
Project: Weave Scope (Observability and Analysis / Observability)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at i@dario.im. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at
Project: Netdata (Observability and Analysis / Observability)
File: net.inet.icmp.stats.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/integrations/net.inet.icmp.stats.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/metadata.yaml" sidebar_label: "net.inet.icmp.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.inet.icmp.stats <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Collect information about ICMP traffic. 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 ICMP connections statistics. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | ipv4.icmp | received, sent | packets/s | | ipv4.icmp_errors | InErrors, OutErrors, InCsumErrors | packets/s | | ipv4.icmpmsg | InEchoReps, OutEchoReps, InEchos, OutEchos | 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.inet.icmp.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 | |:-|:--|:-|:--:| | IPv4 ICMP packets | Enable or disable IPv4 ICMP packets metric. | yes | no | | IPv4 ICMP error | Enable or disable IPv4 ICMP error metric. | yes | no | | IPv4 ICMP messages | Enable or disable IPv4 ICMP messages metric. | yes | no | </details> There are no configuration examples.
Project: Checkmk (Observability and Analysis / Observability)
File: 16364.md

key | value | date | 2024-01-29T13:13:54+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | no Before this Werk, when creating a tag group, the ident field was used to provide its identification as well as that of the tags associated to the group, however the information was returned in the id field. This Werk unifies the names and now the ident fields are renamed to id. Users should adapt their scripts accordingly. For comptatibility reasons CheckMK 2.2.0 and 2.3.0 will support both id and ident, but ident will be removed on the next version. The following example shows the changes that need to be applied to the payload to use this endpoint: Original payload: ```json { "ident": "test_group", "title": "Test group", "help_text": "My test groupd", "tags": [ {"ident": "test", "title": "Test Tag"} ] } ``` Updated payload: ```json { "id": "test_group", "title": "Test group", "help_text": "My test groupd", "tags": [ {"id": "test", "title": "Test Tag"} ] } ```
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-dashboard_graphs_gets_by_screenid.md

category: DashboardGraph apiurl: '/api/v1/dashboard/graphs/screen/:screen_id' title: 'Gets graphs by screen id' type: 'GET' sample_doc: 'dashboard.html' layout: default Required ```Status: 200``` ``` [ { "counters": [ "value/name=pfc.push.ms" ], "endpoints": [ "laiweiofficemac" ], "falcon_tags": "", "graph_id": 4640, "graph_type": "h", "method": "", "position": 0, "screen_id": 991, "timespan": 3600, "title": "dddd" }, { "counters": [ "aaa" ], "endpoints": [ "xxx" ], "falcon_tags": "", "graph_id": 4641, "graph_type": "h", "method": "SUM", "position": 0, "screen_id": 991, "timespan": 3600, "title": "dddd" } ] ``` For errors responses, see the .
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-0-0.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 8.0.0 <!-- Auto generated by update changelog github action --> AzureMonitor: Require default subscription for workspaces() template variable query. , AzureMonitor: Use resource type display names in the UI. , Dashboard: Remove support for loading and deleting dashboard by slug. , InfluxDB: Deprecate direct browser access in data source. , VizLegend: Add a read-only property. , AzureMonitor: Fix Azure Resource Graph queries in Azure China. , Checkbox: Fix vertical layout issue with checkboxes due to fixed height. , Dashboard: Fix Table view when editing causes the panel data to not update. , Dashboard: Fix issues where unsaved-changes warning is not displayed. , Login: Fixes Unauthorized message showing when on login page or snapshot page. , NodeGraph: Fix sorting markers in grid view. , Short URL: Include orgId in generated short URLs. , Variables: Support raw values of boolean type. , The following endpoints were deprecated for Grafana v5.0 and support for them has now been removed: GET `/dashboards/db/:slug` GET `/dashboard-solo/db/:slug` GET `/api/dashboard/db/:slug` DELETE `/api/dashboards/db/:slug` Issue
Project: OpenTelemetry (Observability and Analysis / Observability)
File: credentials-access.md

-- name: Credential Store Access Request about: Request access to the OpenTelemetry credential store title: 'REQUEST: Credential Store Access for <USERNAME>' labels: area/repo-maintenance assignees: '' <!-- Please remember to change the title of this issue by replacing <USERNAME> with the actual github username --> e.g. https://github.com/open-telemetry/opentelemetry-collector Access to shared repository vaults requires a maintainer from the requested vault to sponsor the request <!-- Tag the current maintainers team here to make them aware of the request. --> @open-telemetry/xxx-maintainers
Project: Checkmk (Observability and Analysis / Observability)
File: 14230.md

key | value | date | 2024-04-10T12:05:48+00:00 version | 2.4.0b1 class | fix edition | cre component | bi level | 1 compatible | yes The configuration option <tt>Escalate downtimes based on aggregated WARN state</tt> did not correctly since version 1.5. The behaviour is now fixed and works like its mentioned in our
Project: SkyWalking (Observability and Analysis / Observability)
File: changes-8.1.0.md

Support Kafka as an optional trace, JVM metrics, profiling snapshots and meter system data transport layer. Support Meter system, including the native metrics APIs and the Spring Sleuth adoption. Support JVM thread metrics. [Core*] Fix the concurrency access bug in the Concurrency ClassLoader Case. [Core*] Separate the config of the plugins from the core level. [Core*] Support instrumented class cached in memory or file, to be compatible with other agents, such as Arthas. Add logic endpoint concept. Could analysis any span or tags flagged by the logic endpoint. Add Spring annotation component name for UI visualization only. Add support to trace `Call procedures` in MySQL plugin. Support GraphQL plugin. Support Quasar fiber plugin. Support InfluxDB java client plugin. Support brpc java plugin Support `ConsoleAppender` in the logback v1 plugin. Enhance vert.x endpoint names. Optimize the code to prevent mongo statements from being too long. Fix WebFlux plugin concurrency access bug. Fix ShardingSphere plugins internal conflicts. Fix duplicated Spring MVC endpoint. Fix lettuce plugin sometimes trace doesnt show span layer. Fix `@Tag` returnedObject bug. Support Jetty Server advanced configurations. Support label based filter in the prometheus fetcher and OpenCensus receiver. Support using k8s configmap as the configuration center. Support OAP health check, and storage module health check. Support sampling rate in the dynamic configuration. Add `endpointrelationsla` and `endpointrelationpercentile` for endpoint relationship metrics. Add components for Python plugins, including Kafka, Tornado, Redis, Django, PyMysql. Add components for Golang SDK. Add Nacos 1.3.1 back as an optional cluster coordinator and dynamic configuration center. Enhance the metrics query for ElasticSearch implementation to increase the stability. Reduce the length of storage entity names in the self-observability for MySQL and TiDB storage. Fix labels are missing in Prometheus analysis context. Fix column length issue in MySQL/TiDB storage. Fix no data in 2nd level aggregation in self-observability. Fix searchService bug in ES implementation. Fix wrong validation of endpoint relation entity query. Fix the bug caused by the OAL debug flag. Fix endpoint dependency bug in MQ and uninstrumented proxy cases. Fix time bucket conversion issue in the InfluxDB storage implementation. Update k8s client to 8.0.0 Support endpoint dependency graph. Support x-scroll of trace/profile page Fix database selector issue. Add the bar chart in the UI templates. Update the user logo wall. Add backend configuration vocabulary document. Add agent installation doc for Tomcat9 on Windows. Add istioctl ALS commands for the document. Fix TTL documentation. Add FAQ doc about thread instrumentation. Fix fuzzy query sql injection in the MySQL/TiDB storage. All issues and pull requests are
Project: Elastic (Observability and Analysis / Observability)
File: bucket.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Creates groups of values - buckets - out of a datetime or numeric input. The size of the buckets can either be provided directly, or chosen based on a recommended count and values range. ``` FROM employees | WHERE hiredate >= "1985-01-01T00:00:00Z" AND hiredate < "1986-01-01T00:00:00Z" | STATS hiredate = MVSORT(VALUES(hiredate)) BY month = BUCKET(hiredate, 20, "1985-01-01T00:00:00Z", "1986-01-01T00:00:00Z") | SORT hire_date ```
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-1.2.2.md

Increment version to 1.2.2 and backport log4j upgrade to 2.16. (#1728) Tue, 14 Dec 2021 19:04:20 -0500 Increment version to 1.2.2. Signed-off-by: dblock &lt;dblock@amazon.com&gt; Upgrade to log4j 2.16.0 (#1721) (#1723) Signed-off-by: Andriy Redko &lt;andriy.redko@aiven.io&gt; Moving DCO to workflows (#1458) Signed-off-by: CEHENKLE &lt;henkle@amazon.com&gt; Co-authored-by: Andriy Redko &lt;andriy.redko@aiven.io&gt; Co-authored-by: CEHENKLE &lt;henkle@amazon.com&gt;
Project: Netdata (Observability and Analysis / Observability)
File: 1m_tcp_accept_queue_overflows.md

This alert presents the average number of overflows in the TCP accept queue over the last minute. This alert gets raised in a warning state when the value is greater than 1 and less than 5. If the overflow average exceeds 5 in the last minute, then the alert gets raised in the critical state. The accept queue holds fully established TCP connections waiting to be handled by the listening application. It overflows when the server application fails to accept new connections at the rate they are coming in. A SYN flood is a form of denial-of-service attack in which an attacker rapidly initiates a connection to a server without finalizing the connection. The server has to spend resources waiting for half-opened connections, which can consume enough resources to make the system unresponsive to legitimate traffic. Increase the queue length Open the /etc/sysctl.conf file and look for the entry " net.ipv4.tcpmaxsyn_backlog". The `tcpmaxsynbacklog` is the maximal number of remembered connection requests (SYNRECV), which have not received an acknowledgment from connecting client. If the entry does not exist, you can append the following default entry to the file; `net.ipv4. tcpmaxsyn_backlog=1280`. Otherwise, adjust the limit to suit your needs. Save your changes and run; ``` sysctl -p ``` Note: Netdata strongly suggests knowing exactly what values you need before making system changes.
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_pubcomp_sent_reason_unsuccessful.md

This alert indicates that the number of unsuccessful v5 PUBCOMP (Publish Complete) packets sent within the last minute has increased. VerneMQ is an MQTT broker, which plays a crucial role in managing and processing the message flow between MQTT clients. If you receive this alert, it implies that there are issues in the message flow, which might affect the communication between MQTT clients and the broker. In MQTT protocol, PUBCOMP is the fourth and final packet in the Quality of Service (QoS) 2 protocol exchange. The flow consists of PUBLISH, PUBREC (Publish Received), PUBREL (Publish Release), and PUBCOMP packets. PUBCOMP is sent by the receiver (MQTT client or broker) to confirm that it has received and processed the PUBREL packet. Unsuccessful PUBCOMP packets indicate that the receiver was not able to process the message properly. Check VerneMQ logs for errors or warnings VerneMQ logs can provide valuable information about issues with the message flow. Locate the log file (usually at `/var/log/vernemq/console.log`) and inspect it for any error messages or warnings related to the PUBCOMP packet or its predecessors (PUBLISH, PUBREC, PUBREL) in the QoS 2 flow. Identify problematic MQTT clients Analyze the logs to identify the MQTT clients that are frequently involved in unsuccessful PUBCOMP packets exchange. These clients might have connection or configuration issues that lead to unsuccessful PUBCOMP packets. Validate MQTT clients configurations Ensure that the MQTT clients involved in unsuccessful PUBCOMP packets have valid configurations and that they are compatible with the broker (VerneMQ). Check parameters such as QoS level, protocol version, authentication, etc. Monitor VerneMQ metrics Use Netdata or other monitoring tools to observe VerneMQ metrics and identify unusual patterns in the broker's performance. Increased load on the broker, high memory or CPU usage, slow response times, or network hiccups might contribute to unsuccessful PUBCOMP packets. Ensure proper MQTT payload size Unsuccessful PUBCOMP packets can be caused by oversized payload or incorrect Message ID. Verify that the payload size respects the Maximum Transmission Unit (MTU) and that the Message ID follows the MQTT protocol specifications.
Project: OpenSearch (Observability and Analysis / Observability)
File: pull_request_template.md

<!-- Thanks for sending a pull request, here are some tips: If this is a fix for an undisclosed security vulnerability, please STOP. All security vulnerability reporting and fixes should be done as per our security policy https://github.com/opensearch-project/OpenSearch/security/policy If this is your first time, please read our contributor guidelines: https://github.com/opensearch-project/OpenSearch/blob/main/CONTRIBUTING.md and developer guide https://github.com/opensearch-project/OpenSearch/blob/main/DEVELOPER_GUIDE.md Ensure you have added or ran the appropriate tests for your PR: https://github.com/opensearch-project/OpenSearch/blob/main/TESTING.md --> [Describe what this change achieves] Resolves #[Issue number to be closed when this PR is merged] <!-- List any other related issues here --> [ ] New functionality includes testing. [ ] All tests pass [ ] New functionality has been documented. [ ] New functionality has javadoc added . ) [ ] Commits are signed per the DCO using --signoff ) By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. For more information on following Developer Certificate of Origin and signing off your commits, please check .
Project: Checkmk (Observability and Analysis / Observability)
File: 16324.md

key | value | date | 2024-01-29T12:15:27+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes Since NetApp has discontinued support for their old API this werk adds datasource program and check plugins for the new NetApp ONTAP REST API. However, the new API does not provide certain metrics that were available in the old API. As a result, the new check plugins have been modified accordingly. The plugins that have been migrated with this werk are the ones that monitor: NetApp aggregates NetApp node's CPUs NetApp disks NetApp sensors of environment and shelves NetApp node's fans NetApp node's interfaces NetApp LUNs NetApp node's ports NetApp power supply units NetApp volumes (and snapshots) NetApp (SVMs) Storage Virtual Machine's (formerly called "vservers) traffic and status These plugins and metrics are under development: NetApp snapvault NetApp qtree quota NetApp FCP NetApp (SVMs) Storage Virtual Machine's (formerly called "vservers) Nfsv3readios (read ops) Nfsv3writeios (write ops) Here is a list of missing metrics and plugins as the corresponding data cannot be found in the new NetApp API: NetApp Disk Summary Parity disks Total number of disks type data Total number of disks type parity Traffic SVM (formerly vServer) Nfsv4readios (read ops) Nfsv4writeios (write ops) System time Missing service
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: README.md

This website is built using , a modern static website generator. You will need to have nodejs installed in your machine to work with the documentation website. Your can start locally the website. Open a terminal and go to the root project of this repository. Launch the command below, it will install the dependencies and run the local server for the documentation. ```shell make watch-doc ``` You can now access the documentation directly in your browser: . Open a terminal and go to the root project of this repository. Launch the command below, it will install the dependencies and build the documentation. ```shell make build-doc ``` If you want to see the result of your build, you can serve it with this command: ```shell make serve-doc ```
Project: Netdata (Observability and Analysis / Observability)
File: vcsa_storage_health.md

The `vcsastoragehealth` alert indicates the health status of the storage components in your VMware vCenter Server Appliance (vCSA). It notifies you when the storage components are experiencing issues or are at risk of failure. Identify the affected component(s): Check the alert details and note the component(s) with the corresponding health codes to determine their status. Access the vCenter Server Appliance Management Interface (VAMI): Open a supported browser and enter the URL: `https://<appliance-IP-address-or-FQDN>:5480`. Log in with the administrator or root credentials. Navigate to the Storage tab: In the VAMI, click on the 'Monitor' tab and then click on 'Storage.' Analyze the storage health: Review the reported storage health status for each component, match the health status with the information in the alert, and identify any issues. Remediate the issue: Depending on the identified problem, take the necessary actions to resolve the issue. Examples include: Check for any hardware faults and replace faulty components. Investigate possible disk space issues and free up space or increase the storage capacity. Verify that the storage subsystem is properly configured, and no misconfigurations are causing the issue. Look for software issues, such as failed updates, and resolve them or rollback changes. Consult VMware support if further assistance is needed. Verify resolution: After resolving the issue, verify that the storage health status has improved by checking the current status in the VAMI Storage tab.