cwielenb/CNCF-Dataset huggingface dataset:
Project: Beats (Observability and Analysis / Observability)
File: README-developer.md

``` brew install bro ``` Configure it to process network traffic and generate logs. Edit `/usr/local/etc/node.cfg` to use the proper network interfaces. Edit `/usr/local/etc/networks.cfg` to specify local networks accordingly. Set `redef LogAscii::use_json=T;` in `/usr/local/share/bro/site/local.bro` to use JSON output. ``` apt install bro apt install broctl ``` Configure it to process network traffic and generate logs. Edit `/etc/bro/node.cfg` to use the proper network interfaces. Edit `/etc/bro/networks.cfg` to specify local networks accordingly. Set `redef LogAscii::use_json=T;` in `/usr/share/bro/site/local.bro` to use JSON output. ``` sudo broctl deploy ``` Clone and build Filebeat ``` git clone git@github.com:elastic/beats.git cd beats/x-pack/filebeat make mage mage clean update mage build ``` Update filebeat.yml to point to Elasticsearch and Kibana. Setup Filebeat. ``` ./filebeat setup --modules zeek -e -E 'setup.dashboards.directory=build/kibana' ``` Enable the Filebeat zeek module ``` ./filebeat modules enable zeek ``` Start Filebeat ``` ./filebeat -e ``` Now, you should see the Zeek logs and dashboards in Kibana.
Project: Checkmk (Observability and Analysis / Observability)
File: 15721.md

key | value | compatible | yes version | 2.3.0b1 date | 2024-01-19T08:47:31+00:00 level | 1 class | fix component | core edition | cee This change fixes a bug in the Nagios Core edition detection logic which could occur when using the Nagios core with another edition than the Raw Edition. This is a rare use case, but can happen temporarily during the migration from the Raw Edition to an Enterprise Edition. The bug manifests itself by reporting the wrong edition via the livestatus interface. This can be observed with the following query: ``` lq "GET status\nColumns: edition" ``` The edition column was introduced in 2.2.0.
Project: Kubecost (Observability and Analysis / Continuous Optimization)
File: CODE_OF_CONDUCT.md

As contributors and maintainers in the OpenCost community, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. We are committed to making participation in the OpenCost community a harassment-free experience for everyone. 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 behavior that contributes to a positive environment include: Demonstrating empathy and kindness toward others Being respectful of differing opinions, viewpoints, and experiences Giving and gracefully accepting constructive feedback Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience Focusing on what is best not just for us as individuals, but for the overall community Examples of unacceptable behavior include: The use of sexualized language or imagery, and sexual attention or advances of any kind Trolling, insulting or derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or email address, without their explicit permission No solicitation. This is a community to help foster innovation, education, and professional & personal networking. Other conduct which could reasonably be considered inappropriate in a professional setting 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. By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team. Instances of abusive, harassing, or otherwise unacceptable behavior in the OpenCost community may be reported by contacting the project maintainer(s) who will try to resolve incidents without punishment, but may remove people from the project or OpenCost community at their discretion. This Code of Conduct is adapted from the Contributor Covenant (http://contributor-covenant.org), version 2.0 available at http://contributor-covenant.org/version/2/0/codeofconduct/
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_registry.ResourceDetailsViewLoadedEvent.md

title: "Interface: ResourceDetailsViewLoadedEvent" linkTitle: "ResourceDetailsViewLoadedEvent" slug: "plugin_registry.ResourceDetailsViewLoadedEvent" .ResourceDetailsViewLoadedEvent Event fired when a resource is loaded in the details view. data: `Object` | Name | Type | Description | | : | : | : | | `error?` | `Error` | The error, if an error has occurred | | `resource` | `any` | The resource that was loaded. | _ type: `DETAILS_VIEW`
Project: Netdata (Observability and Analysis / Observability)
File: discord.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/integrations/discord.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/metadata.yaml" sidebar_label: "Discord" learn_status: "Published" learnrelpath: "Alerts & Notifications/Notifications/Centralized Cloud Notifications" message: "DO NOT EDIT THIS FILE DIRECTLY, IT IS GENERATED BY THE NOTIFICATION'S metadata.yaml FILE" endmeta--> <img src="https://netdata.cloud/img/discord.png" width="150"/> From the Netdata Cloud UI, you can manage your space's notification settings and enable the configuration to deliver notifications on Discord. <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> A Netdata Cloud account Access to the Netdata Space as an Admin You need to have a Discord server able to receive webhooks integrations. Steps to configure your Discord server to receive from Netdata: Go to `Server Settings` --> `Integrations` Create Webhook or View Webhooks if you already have some defined Specify the Name and Channel on your new webhook Use Webhook URL to add your notification configuration on Netdata UI Click on the Space settings cog (located above your profile icon) Click on the Notification tab Click on the + Add configuration button (near the top-right corner of your screen) On the Discord card click on + Add A modal will be presented to you to enter the required details to enable the configuration: Notification settings* are Netdata specific settings Configuration name - you can optionally provide a name for your configuration you can easily refer to it Rooms - by specifying a list of Rooms you are select to which nodes or areas of your infrastructure you want to be notified using this configuration Notification - you specify which notifications you want to be notified using this configuration: All Alerts and unreachable, All Alerts, Critical only Integration configuration* are the specific notification integration required settings, which vary by notification method. For Discord: Define the type channel you want to send notifications to: Text channel or Forum channel Webhook URL - URL provided on Discord for the channel you want to receive your notifications. Thread name - if the Discord channel is a Forum channel you will need to provide the thread name as well
Project: Netdata (Observability and Analysis / Observability)
File: mysql_galera_cluster_size.md

This alert monitors the Galera cluster size and checks if there is a discrepancy between the current cluster size and the maximum size in the last 2 minutes. A warning is raised if the current size is larger, and a critical alert is raised if the current size is smaller than the maximum size in the last minute. Check the network connectivity: Galera Cluster relies on persistent network connections. Review your system logs for any connectivity issues or network errors. If you find such issues, work with your network administrator to resolve them. Check the status of MySQL nodes: You can use the following query to examine the status of all nodes in the Galera cluster: ``` SHOW STATUS LIKE 'wsrepcluster%'; ``` Look for the `wsrepclustersize` and `wsrepclusterstatus` values, and analyze if there are any inconsistencies or issues. Review Galera logs: Inspect the logs of the Galera cluster for any errors, warnings or issues. The log files are usually located in `/var/log/mysql` or `/var/lib/mysql` directories. Check node synchronization: Ensure that all nodes are synced by checking the `wsreplocalstate_comment` status variable. A value of 'Synced' indicates that the node is in sync with the cluster. ``` SHOW STATUS LIKE 'wsreplocalstate_comment'; ``` If any node is not synced, check its logs to find the cause of the issue and resolve it. Restart nodes if necessary: If you find that a node is not working properly, you can try to restart the MySQL service on the affected node: ``` sudo systemctl restart mysql ``` Keep in mind that restarting a node can cause temporary downtime for applications connecting to that specific node. If the issue persists, consider contacting the Galera Cluster support team for assistance or consult the for further guidance.
Project: Tracetest (Observability and Analysis / Observability)
File: tracetest_completion_powershell.md

Generate the autocompletion script for powershell Generate the autocompletion script for powershell. To load completions in your current shell session: ``` tracetest completion powershell | Out-String | Invoke-Expression ``` To load completions for every new session, add the output of the above command to your powershell profile. ``` tracetest completion powershell [flags] ``` ``` -h, --help help for powershell --no-descriptions disable completion descriptions ``` ``` -c, --config string config file will be used by the CLI (default "config.yml") -o, --output string output format [pretty|json|yaml] -s, --server-url string server url -v, --verbose display debug information ``` - Generate the autocompletion script for the specified shell
Project: Netdata (Observability and Analysis / Observability)
File: platform_info.md

[% if entries %] We build native packages for the following releases: | Version | Support Tier | Native Package Architectures | Notes | |:-:|::|:-:|:-- | [% for e in entries %] | [[ e.version ]] | [[ e.support ]] | [[ ', '.join(e.arches) ]] | [[ e.notes ]] | [% endfor %] [% endif %] On other releases of this distribution, a static binary will be installed in `/opt/netdata`.
Project: Grafana Loki (Observability and Analysis / Observability)
File: 0001-Introduction.md

title: "0001: Introducing LIDs" description: "0001: Introducing LIDs" aliases: ../../lids/0001-introduction/ Author: Danny Kopping (danny.kopping@grafana.com) Date: 01/2023 Sponsor(s): @dannykopping Type: Process Status: Accepted Related issues/PRs: N/A Thread from : N/A As the Grafana Loki project grows, we have seen more and more contributions from external (outside Grafana Labs) contributors. Many of these external contributions are large and complex, and have taken these contributors significant time to implement. Large contributions that are made without prior discussion with maintainers are at risk of being rejected if they are misguided, implemented inefficiently, or simply undesired; this is obviously suboptimal both for the contributors and the maintainers. Aside from external contributions, changes being proposed by Grafana Loki maintainers may also require community engagement before being worked on. It would be preferable to engage with contributors before they make large contributions to ensure that both their and the project's interests are aligned. The community at large must also have a voice when feature or process changes are being proposed, to protect their own interests. We should implement a lightweight process that guides the implementation of major changes to the project. We will continue to attract large, often complex, external contributions that have not be discussed with maintainers prior to the work being put in; this may lead to suboptimal outcomes for the relationship between the project and its community. Inspired by Python's and Kafka's approaches, we should create a process for formally documenting improvements to Loki which are permanently viewable, and document our decisions. Google Docs were considered for this, but they are less useful because: they would need to be owned by the Grafana Labs organisation, so that they remain viewable even if the author closes their account we already have previous in our documentation and, in a recent () community call, the community expressed a preference for this type of approach
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-7-5-6.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 7.5.6 <!-- Auto generated by update changelog github action --> Database: Add isolation level configuration parameter for MySQL. , InfluxDB: Improve measurement-autocomplete behavior. , Instrumentation: Don't consider invalid email address a failed email. , Loki: fix label browser crashing when + typed. , Prometheus: Sanitize PromLink button. ,
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-expression_create.md

category: Expression apiurl: '/api/v1/expression' title: "Create Expression" type: 'POST' sample_doc: 'expression.html' layout: default Required ```{ "right_value": "0", "priority": 2, "pause": 0, "op": "==", "note": "this is a test exp", "max_step": 3, "func": "all(#3)", "expression": "each(metric=agent.alive endpoint=docker-agent)", "action": { "url": "http://localhost:1234/callback", "uic": [ "test" ], "callback": 1, "beforecallbacksms": 1, "beforecallbackmail": 0, "aftercallbacksms": 1, "aftercallbackmail": 0 } }``` ```Status: 200``` ```{"message":"expression created"}```
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-dashboard_graph_create_tmpgraph.md

category: DashboardGraph apiurl: '/api/v1/dashboard/tmpgraph' title: 'Create a tmpgraph' type: 'POST' sample_doc: 'dashboard.html' layout: default Required ``` {"endpoints":["e1", "e2"], "counters":["c1", "c2"]} ``` ```Status: 200``` ``` { "ck": "68c07419dbd7ac65977c97d05d99440d", "counters": "c1|c2", "endpoints": "e1|e2", "id": 365195 } ``` For errors responses, see the .
Project: Netdata (Observability and Analysis / Observability)
File: ioping.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/ioping.plugin/README.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/ioping.plugin/metadata.yaml" sidebar_label: "IOPing" learn_status: "Published" learnrelpath: "Collecting Metrics/Synthetic Checks" 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/syslog.png" width="150"/> Plugin: ioping.plugin Module: ioping.plugin <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Monitor IOPing metrics for efficient disk I/O latency tracking. Keep track of read/write speeds, latency, and error rates for optimized disk operations. Plugin uses `ioping` command. 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 scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | ioping.latency | latency | microseconds | The following alerts are available: | Alert name | On metric | Description | |:|:-|:| | | ioping.latency | average I/O latency over the last 10 seconds | You can install the command by passing the argument `install` to the plugin (`/usr/libexec/netdata/plugins.d/ioping.plugin install`). The configuration file name for this integration is `ioping.conf`. 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 ioping.conf ``` <details><summary>Config options</summary> | Name | Description | Default | Required | |:-|:--|:-|:--:| | update_every | Data collection frequency. | 1s | no | | destination | The directory/file/device to ioping. | | yes | | request_size | The request size in bytes to ioping the destination (symbolic modifiers are supported) | 4k | no | | ioping_opts | Options passed to `ioping` commands. | -T 1000000 | no | </details> This example has the minimum configuration necessary to have the plugin running. <details><summary>Config</summary> ```yaml destination="/dev/sda" ``` </details>
Project: Grafana Mimir (Observability and Analysis / Observability)
File: prettier_rules.md

This files contains rules for prettifying PromQL expressions. Note: The current version of prettier does not preserve comments. `maxcharactersper_line`: Maximum number of characters that will be allowed on a single line in a prettified PromQL expression. A node exceeding the `maxcharactersper_line` will qualify for split unless It is a `MatrixSelector` It is a `VectorSelector`. Label sets in a `VectorSelector` will be in the same line as metric_name, separated by commas and a space Note: Label groupings like `by`, `without`, `on`, `ignoring` will remain on the same line as their parent node Nodes that are nested within another node will be prettified only if they exceed the `maxcharactersper_line` Expressions like `sum(expression) without (labelmatchers)` will be modified to `sum without(labelmatchers) (expression)` Functional call args will be split to different lines if they exceed the `maxcharactersper_line`
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_pubrec_sent_reason_unsuccessful.md

This alert monitors the number of sent unsuccessful v5 PUBREC packets in the last minute in the VerneMQ MQTT broker. If you receive this alert, it means that there is an issue with successfully acknowledging receipt of PUBLISH packets in the MQTT system. In the MQTT protocol, when a client sends a PUBLISH message with Quality of Service (QoS) level 2, it expects an acknowledgment from the server in the form of a PUBREC (Publish Received) message. This confirms the successful receipt of the PUBLISH message by the server. If a PUBREC message is marked as unsuccessful, it indicates a problem with the message acknowledgment process. Check VerneMQ log files for any errors or warnings related to unsuccessful PUBREC messages. VerneMQ logs can be found in `/var/log/vernemq` (by default) or the directory specified in your configuration file. ``` sudo tail -f /var/log/vernemq/console.log sudo tail -f /var/log/vernemq/error.log ``` Verify if any clients are having issues with the MQTT connection, such as intermittent network problems or misconfigured settings. Check the client logs for any issues and take appropriate action. Review the MQTT QoS settings for the clients in the system. If possible, consider lowering the QoS level to 1 or 0, which uses less resources and bandwidth. QoS level 2 might not be necessary for some use cases. Inspect the VerneMQ system and environment for resource bottlenecks or other performance issues. Use tools like `top`, `htop`, `vmstat`, or `iotop` to monitor system resources and identify any potential problems. If the issue persists, consider seeking support from the VerneMQ community or the software vendor for further assistance.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_limitRange.LimitRangeSpec.md

title: "Interface: LimitRangeSpec" linkTitle: "LimitRangeSpec" slug: "libk8slimitRange.LimitRangeSpec" .LimitRangeSpec limits: { `default`: { `cpu`: `string` ; `memory`: `string` } ; `defaultRequest`: { `cpu`: `string` ; `memory`: `string` } ; `max`: { `cpu`: `string` ; `memory`: `string` } ; `min`: { `cpu`: `string` ; `memory`: `string` } ; `type`: `string` }[]
Project: Headlamp (Observability and Analysis / Observability)
File: README.md

This is the default template README for . The description of your plugin should go here. You should also edit the package.json file meta data (like name and description). For more information on developing Headlamp plugins, please refer to: , How to create a new Headlamp plugin. , API documentation for what you can do , pre-existing components you can use when creating your plugin. , Example plugins you can look at to see how it's done.
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_pubrel_received_reason_unsuccessful.md

This alert monitors the number of received `unsuccessful v5 PUBREL` packets in the last minute in the VerneMQ MQTT broker. If you receive this alert, it means that there were unsuccessful PUBREL attempts in VerneMQ, which might indicate an issue during the message delivery process. MQTT (Message Queuing Telemetry Transport) is a lightweight, low-code and low-latency messaging protocol that works with a subscription-based system. It utilizes a broker, like VerneMQ, to facilitate communication. A `PUBREL` packet is the third one in a QoS-2 (Quality of Service level 2) message flow. QoS-2 is the highest available level in MQTT and strives to provide once-and-only-once message delivery to subscribers. The `PUBREL` packet is sent by the publisher to acknowledge its receipt of a `PUBREC` packet and signal that it is OK to release the message. An unsuccessful `PUBREL` packet indicates that the message release process encountered issues and may not have been completed as expected. Check the VerneMQ broker logs for any unusual messages: ``` sudo journalctl -u vernemq ``` Look for errors or warnings that might be related to the unsuccessful `PUBREL` packets. Examine the configuration files of VerneMQ: ``` cat /etc/vernemq/vernemq.conf ``` Check if there are any misconfigurations or unsupported features that could cause issues with QoS-2 message flow. Refer to the for correct configurations. Analyze the clients' logs, which can be publishers or subscribers, for any errors or issues related to MQTT connections and QoS levels. Make sure the clients are using the correct QoS levels and are following the MQTT protocol. Monitor VerneMQ's RAM, CPU, and file descriptor usage to determine if the broker's performance is degraded. Resolve any performance bottlenecks or resource constraints to prevent further unsuccessful `PUBREL` packets. For in-depth analysis, enable VerneMQ's debug logs by setting `log.console.level` to `debug` in its configuration file and restarting the service. Be cautious, as this might generate large amounts of log data. If the issue persists, consider reaching out to the VerneMQ support channels, such as their repository.