cwielenb/CNCF-Dataset huggingface dataset:
Project: Netdata (Observability and Analysis / Observability)
File: applications.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/apps.plugin/integrations/applications.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/apps.plugin/metadata.yaml" sidebar_label: "Applications" 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/applications.svg" width="150"/> Plugin: apps.plugin Module: apps <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Monitor Applications for optimal software performance and resource usage. 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 application group. Labels: | Label | Description | |:--|:-| | app_group | The name of the group defined in the configuration. | Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | app.cpu_utilization | user, system | percentage | | app.cpuguestutilization | guest | percentage | | app.cpucontextswitches | voluntary, involuntary | switches/s | | app.mem_usage | rss | MiB | | app.memprivateusage | mem | MiB | | app.vmem_usage | vmem | MiB | | app.mempagefaults | minor, major | pgfaults/s | | app.swap_usage | swap | MiB | | app.diskphysicalio | reads, writes | KiB/s | | app.disklogicalio | reads, writes | KiB/s | | app.processes | processes | processes | | app.threads | threads | threads | | app.fdsopenlimit | limit | percentage | | app.fds_open | files, sockets, pipes, inotifies, event, timer, signal, eventpolls, other | fds | | app.uptime | uptime | seconds | | app.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: M3 (Observability and Analysis / Observability)
File: docker.md

linkTitle: "Docker" title: Creating a Single Node M3 Cluster with Docker weight: 1 This guide shows how to install and configure M3, create a single-node cluster, and read and write metrics to it. {{% notice warning %}} Deploying a single-node cluster is a great way to experiment with M3 and get an idea of what it has to offer, but isn't designed for production use. To run M3 in clustered mode with a separate M3 Coordinator, . {{% /notice %}} Docker: You don't need to run M3DB, but it's the simplest and quickest way. If you use Docker Desktop, we recommend the following minimum Resources settings. CPUs: 2 Memory: 8GB Swap: 1GB Disk image size: 16GB JQ: This example uses to format the output of API calls. It isn't essential for using M3DB. curl: This example uses curl for communicating with M3DB endpoints. You can also use alternatives such as and HTTPie. By default the official M3 Docker image configures a single instance as one binary containing: An M3DB storage instance for time series storage. It includes an embedded tag-based metrics index and an etcd server for storing the cluster topology and runtime configuration. A M3 Coordinator instance for writing and querying tagged metrics, as well as managing cluster topology and runtime configuration. The Docker container exposes two ports: `7201` to manage the cluster topology, you make most API calls to this endpoint `7203` for Prometheus to scrape the metrics produced by M3DB and M3 Coordinator The command below creates a persistent data directory on the host operating system to maintain durability and persistence between container restarts. {{< tabs name="start_container" >}} {{% tab name="Command" %}} ```shell docker run -p 7201:7201 -p 7203:7203 --name m3db -v $(pwd)/m3db_data:/var/lib/m3db quay.io/m3db/m3dbnode:{{% docker-version %}} ``` {{% /tab %}} {{% tab name="Output" %}} <!-- TODO: Perfect image, pref with terminalizer --> {{% /tab %}} {{< /tabs >}} {{% notice info %}} When running the command above on Docker for Mac, Docker for Windows, and some Linux distributions you may see errors about settings not being at recommended values. Unless you intend to run M3 in production on macOS or Windows, you can ignore these warnings. {{% /notice %}} The single-node cluster Docker image uses this by default. The file groups configuration into `coordinator` or `db` sections that represent the `M3Coordinator` and `M3DB` instances of single-node cluster. <!-- TODO: Replicate relevant sections --> {{% notice tip %}} You can find more information on configuring M3 in the . {{% /notice %}} {{< fileinclude file="quickstart-common-steps.md" >}}
Project: Netdata (Observability and Analysis / Observability)
File: btrfs_device_write_errors.md

This alert is triggered when BTRFS (B-tree file system) encounters write errors on your system. BTRFS is a modern copy-on-write (COW) filesystem designed to address various weaknesses in traditional Linux file systems. If you receive this alert, it means that there have been issues with writing data to the file system. BTRFS write errors can occur when there are problems with the underlying storage devices, such as bad disks or data corruption. These errors may result in data loss or the inability to write new data to the file system. It is important to address these errors to prevent potential data loss and maintain the integrity of your file system. Check the BTRFS system status Execute the following command to get the current status of your BTRFS system: ``` sudo btrfs device stats [Mount point] ``` Replace `[Mount point]` with the actual mount point of your BTRFS file system. Examine system logs for potential issues Check the system logs for any signs of issues with the BTRFS file system or underlying storage devices: ``` sudo journalctl -u btrfs ``` Check the health of the storage devices Use the `smartctl` tool to assess the health of your storage devices. For example, to check the device `/dev/sda`, use the following command: ``` sudo smartctl -a /dev/sda ``` Repair the BTRFS file system If there are issues with the file system, run the following command to repair it: ``` sudo btrfs check --repair [Mount point] ``` Replace `[Mount point]` with the actual mount point of your BTRFS file system. WARNING: The `--repair` option should be used with caution, as it may result in data loss under certain circumstances. It is recommended to back up your data before attempting to repair the file system.
Project: Netdata (Observability and Analysis / Observability)
File: apcupsd_ups_charge.md

This alert is related to the charge level of your American Power Conversion (APC) uninterruptible power supply (UPS) device. When the UPS charge level drops below a certain threshold, you receive an alert indicating that the system is running on battery and may shut down if external power is not restored soon. Warning state: UPS charge < 100% Critical state: UPS charge < 50% The main purpose of a UPS is to provide a temporary power source to connected devices in case of a power outage. As the battery charge decreases, you need to either restore the power supply or prepare the equipment for a graceful shutdown. Check the UPS charge level and status To investigate the current status and charge level of the UPS, you can use the `apcaccess` command which provides information about the APC UPS device. ``` apcaccess ``` Look for the `STATUS` and `BCHARGE` fields in the output. Restore the power supply (if possible) If the power outage is temporary or local (e.g. due to a tripped circuit breaker), try to restore the power supply to the UPS by fixing the issue or connecting the UPS to a different power source. Prepare for a graceful shutdown If you cannot restore power to the UPS, or if the battery charge is critically low, you should immediately prepare your machine and any connected devices for a graceful shutdown. This will help to avoid data loss or system corruption due to an abrupt shutdown. For Linux systems, you can execute the following command to perform a graceful shutdown: ``` sudo shutdown -h +1 "UPS battery is low. The system will shut down in 1 minute." ``` For Windows systems, open a command prompt with admin privileges and execute the following command to perform a graceful shutdown: ``` shutdown /s /t 60 /c "UPS battery is low. The system will shut down in 1 minute." ``` Monitor UPS and system logs Keep an eye on UPS and system logs to detect any issues with the power supply or UPS device. This can help you stay informed about the system's status and troubleshoot any potential problems.
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: idlenode-recommendation.md

title: "IdleNode Recommendation" description: "Introduce for IdleNode Recommendation" weight: 15 By scanning the status and utilization of nodes, the idle node recommendation helps users to find idle Kubernetes nodes. In Kubernetes cluster, some nodes often idle due to such factors as node taint, label selector, low packing rate and low utilization rate, which wastes a lot of costs. IdleNode recommendation tries to help users find these nodes to reduce cost. ```yaml kind: Recommendation apiVersion: analysis.crane.io/v1alpha1 metadata: name: idlenodes-rule-idlenode-5jxn9 namespace: crane-system labels: analysis.crane.io/recommendation-rule-name: idlenodes-rule analysis.crane.io/recommendation-rule-recommender: IdleNode analysis.crane.io/recommendation-rule-uid: 8921a198-7082-11ed-8b7b-246e960a8d8c analysis.crane.io/recommendation-target-kind: Node analysis.crane.io/recommendation-target-name: worker-node-1 analysis.crane.io/recommendation-target-version: v1 beta.kubernetes.io/arch: amd64 beta.kubernetes.io/instance-type: bareMetal beta.kubernetes.io/os: linux ownerReferences: apiVersion: analysis.crane.io/v1alpha1 kind: RecommendationRule name: idlenodes-rule uid: 8921a198-7082-11ed-8b7b-246e960a8d8c controller: false blockOwnerDeletion: false spec: targetRef: kind: Node name: worker-node-1 apiVersion: v1 type: IdleNode completionStrategy: {} status: targetRef: {} action: Delete lastUpdateTime: '2022-11-30T07:46:57Z' ``` In this sample Recommendation's TargetRef Point to Nodeworker-node-1 Recommendation type is IdleNode action is Deletebut offline a node is a complicated operation, we only give recommended advise. How to create a IdleNode recommendation please refer to Perform the following steps to complete a recommendation process for idle nodes: Scan all nodes and pods in the cluster If all Pods on a node are DaemonSet pods, the node is considered to be idle
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: concat.md

title: Concat weight: 200 generated_file: true Fluentd Filter plugin to concatenate multiline log separated in multiple events. The regexp to match continuous lines. This is exclusive with n_lines. The number of seconds after which the last received event log is flushed. If set to 0, flushing is disabled (wait for next line forever). If true, keep partial_key in concatenated records Default: False If true, keep partial metadata Specify field name in the record to parse. If you leave empty the Container Runtime default will be used. The regexp to match ending of multiline. This is exclusive with n_lines. The regexp to match beginning of multiline. This is exclusive with n_lines. The number of lines. This is exclusive with multilinestartregex. The key name that is referred to concatenate records on cri log The key name that is referred to detect stream name on cri log The field name that is the reference to concatenate records Input format of the partial metadata (fluentd or journald docker log driver)( docker-fluentd, docker-journald, docker-journald-lowercase) The value stored in the field specified by partial_key that represent partial log The separator of lines. (default: "\n") Default: \"\\n\" The key to determine which stream an event belongs to. The label name to handle events caused by timeout. Use timestamp of first record when buffer is flushed. Default: False Use cri log tag to concatenate multiple records Use partial metadata to concatenate multiple records {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: Flow metadata: name: demo-flow spec: filters: concat: partialkey: "partialmessage" separator: "" n_lines: 10 selectors: {} localOutputRefs: demo-output {{</ highlight >}} Fluentd config result: {{< highlight xml >}} <filter > @type concat @id test_concat key message n_lines 10 partialkey partialmessage </filter> {{</ highlight >}}
Project: Centreon (Observability and Analysis / Observability)
File: legacycmd.md

This module aims to mimick the behaviour of the antique centcore daemon. As for centcore, it reads a file (called command file) and process every commands that it knows of. The module relies on the following modules to process commands: | Directive | Description | Default value | | : | :-- | :- | | cmd_file | Command file to read commands from | `/var/lib/centreon/centcore.cmd` | | cmd_dir | Directory where to watch for command files | `/var/lib/centreon/` | | cache_dir | Directory where to process Centreon configuration files | `/var/cache/centreon/` | | cachedirtrap | Directory where to process Centreontrapd databases | `/etc/snmp/centreon_traps/` | | remote_dir | Directory where to export Remote Servers configuration | `/var/cache/centreon/config/remote-data/` | | bulkexternalcmd | Bulk external commands (DOWNTIME, ACK,...) | `50` | | bulkexternalcmd_sequential | Order bulk external commands and other commands (Eg. RELOAD) | `1` | ```yaml name: legacycmd package: "gorgone::modules::centreon::legacycmd::hooks" enable: true cmd_file: "/var/lib/centreon/centcore.cmd" cmd_dir: "/var/lib/centreon/" cache_dir: "/var/cache/centreon/" cachedirtrap: "/etc/snmp/centreon_traps/" remote_dir: "/var/cache/centreon/config/remote-data/" ``` | Event | Description | | :- | :-- | | LEGACYCMDREADY | Internal event to notify the core | No API endpoints.
Project: HertzBeat (Observability and Analysis / Observability)
File: mysql-change.md

id: mysql-change title: Use MYSQL Replace H2 Database to Store Metadata(Optional) sidebar_label: Use MYSQL Instead of H2 MYSQL is a reliable relational database. In addition to default built-in H2 database, HertzBeat allow you to use MYSQL to store structured relational data such as monitoring information, alarm information and configuration information. If you have the MYSQL environment, can be directly to database creation step. Download and install the Docker environment Docker tools download refer to After the installation you can check if the Docker version normally output at the terminal. ``` $ docker -v Docker version 20.10.12, build e91ed57 ``` Install MYSQl with Docker ``` $ docker run -d --name mysql -p 3306:3306 -v /opt/data:/var/lib/mysql -e MYSQLROOTPASSWORD=123456 mysql:5.7 ``` `-v /opt/data:/var/lib/mysql` is local persistent mount of mysql data directory. `/opt/data` should be replaced with the actual local directory. use ```$ docker ps``` to check if the database started successfully Enter MYSQL or use the client to connect MYSQL service `mysql -uroot -p123456` Create database named hertzbeat `create database hertzbeat default charset utf8mb4 collate utf8mb4generalci;` Check if hertzbeat database has been successfully created `show databases;` Configure HertzBeat's configuration file Modify `hertzbeat/config/application.yml` configuration file NoteThe docker container way need to mount application.yml file locally, while you can use installation package way to unzip and modify `hertzbeat/config/application.yml` Replace `spring.database` data source parameters, URL account and password. ```yaml spring: datasource: driver-class-name: org.h2.Driver username: sa password: 123456 url: jdbc:h2:./data/hertzbeat;MODE=MYSQL ``` Specific replacement parameters are as follows and you need to configure account according to the mysql environment: ```yaml spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver username: root password: 123456 url: jdbc:mysql://localhost:3306/hertzbeat?useUnicode=true&characterEncoding=utf-8&useSSL=false ``` Start HertzBeat visit http://ip:1157/ on the browser You can use HertzBeat monitoring alarm, default account and password are admin/hertzbeat
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_unsubscribe_error.md

This alert monitors the number of failed v3/v5 `UNSUBSCRIBE` operations in VerneMQ in the last minute. If you receive this alert, it means that there is a significant number of failed `UNSUBSCRIBE` operations, which may impact the MQTT messaging on your system. VerneMQ is a high-performance, distributed MQTT message broker. It provides scalable and reliable communication for Internet of Things (IoT) systems and applications. An `UNSUBSCRIBE` operation in MQTT protocol is a request sent by a client to the server to remove one or more topics from the subscription list. It allows clients to stop receiving messages for particular topics. Check VerneMQ logs for any error messages or indications of issues with the `UNSUBSCRIBE` operation: ``` sudo journalctl -u vernemq ``` Alternatively, you may find the logs in `/var/log/vernemq/` directory, if using the default configuration: ``` cat /var/log/vernemq/console.log cat /var/log/vernemq/error.log ``` Review the VerneMQ configuration to ensure it is properly set up. The default configuration file is located at `/etc/vernemq/vernemq.conf`. Make sure that the settings are correct, especially those related to the MQTT protocol version and the supported QoS levels. Monitor the VerneMQ metrics using the `vmq-admin metrics show` command. This will provide you with an overview of the broker's performance and help you identify any abnormal metrics that could be related to the failed `UNSUBSCRIBE` operations: ``` sudo vmq-admin metrics show ``` Pay attention to the `mqtt.unsubscribe_error` metric, which indicates the number of failed `UNSUBSCRIBE` operations. Check the MQTT clients that are sending the `UNSUBSCRIBE` requests. It is possible that the client itself is misconfigured or has some faulty logic in its communication with the MQTT broker. Review the client's logs and configuration to identify any issues.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: oss.md

title: Alibaba Cloud weight: 200 generated_file: true Fluent OSS output plugin buffers event logs in local files and uploads them to OSS periodically in background threads. This plugin splits events by using the timestamp of event logs. For example, a log '2019-04-09 message Hello' is reached, and then another log '2019-04-10 message World' is reached in this order, the former is stored in "20190409.gz" file, and latter in "20190410.gz" file. Fluent OSS input plugin reads data from OSS periodically. This plugin uses MNS on the same region of the OSS bucket. We must setup MNS and OSS event notification before using this plugin. shows how to setup MNS and OSS event notification. This plugin will poll events from MNS queue and extract object keys from these events, and then will read those objects from OSS. For details, see . Your access key id Your access secret key desc 'Create OSS bucket if it does not exists Default: false Your bucket name Check bucket if exists or not Default: true Check object before creation Default: true Download crc enabled Default: true OSS endpoint to connect to' The length of `%{hex_random}` placeholder(4-16) Default: 4 `sprintf` format for `%{index}` Default: %d The format of OSS object keys Default: `%{path}/%{timeslice}%{index}%{threadid}.%{file_extension}` Timeout for open connections Default: 10 OSS SDK log directory Default: /var/log/td-agent Overwrite already existing path Default: false Path prefix of the files on OSS Default: fluent/logs Timeout for read response Default: 120 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 a warning message and increases the `fluentdoutputstatusslowflush_count` metric. Archive format on OSS: gzip, json, text, lzo, lzma2 Default: gzip Upload crc enabled Default: true Given a threshold to treat events as delay, output warning logs if delayed events were put into OSS
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: PULL_REQUEST_TEMPLATE.md

<!-- Please add a description of what your pull request is doing. What was the problem? How it is resolved? How can we test the change? If there are breaking changes, please describe them in detail and why we cannot avoid them. --> <!-- Please add the id of the issue this pull request is resolving. We try to have an issue for every PR it is easier to talk about the feature/fix that way. --> Resolve # [ ] I have tested this code [ ] I have added unit test to cover this code [ ] I have updated the documentation (`README.md` and `/website/docs`)
Project: Netdata (Observability and Analysis / Observability)
File: vm.stats.vm.v_pgfaults.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/integrations/vm.stats.vm.v_pgfaults.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/metadata.yaml" sidebarlabel: "vm.stats.vm.vpgfaults" 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/memory.svg" width="150"/> Plugin: freebsd.plugin Module: vm.stats.vm.v_pgfaults <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Collect memory page faults events. 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. The number of page faults happened on host. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | mem.pgfaults | memory, iorequiring, cow, cowoptimized, in_transit | page faults/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 options</summary> | Name | Description | Default | Required | |:-|:--|:-|:--:| | vm.stats.vm.v_pgfaults | Enable or disable Memory page fault metric. | yes | no | </details> There are no configuration examples.