cwielenb/CNCF-Dataset huggingface dataset:
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: common-tunables-for-node-experiments.md

It contains tunables, which are common for all the node experiments. These tunables can be provided at `.spec.experiment[*].spec.components.env` in chaosengine. It defines the name of the target node subjected to chaos. The target node can be tuned via `TARGET_NODE` ENV. It contains only a single node name. `NOTE`: It is supported by [node-drain, node-taint, node-restart, kubelet-service-kill, docker-service-kill] experiments. Use the following example to tune this: ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: "active" annotationCheck: "false" chaosServiceAccount: node-drain-sa experiments: name: node-drain spec: components: env: name: TARGET_NODE value: 'node01' name: TOTALCHAOSDURATION value: '60' ``` It defines the comma-separated name of the target nodes subjected to chaos. The target nodes can be tuned via `TARGET_NODES` ENV. `NOTE`: It is supported by [node-cpu-hog, node-memory-hog, node-io-stress] experiments Use the following example to tune this: ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: "active" annotationCheck: "false" chaosServiceAccount: node-cpu-hog-sa experiments: name: node-cpu-hog spec: components: env: name: TARGET_NODES value: 'node01,node02' name: TOTALCHAOSDURATION value: '60' ``` It defines the labels of the targeted node(s) subjected to chaos. The node labels can be tuned via `NODE_LABEL` ENV. It is mutually exclusive with the `TARGETNODE(S)` ENV. If `TARGETNODE(S)` ENV is set then it will use the nodes provided inside it otherwise, it will derive the node name(s) with matching node labels. Use the following example to tune this: ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: "active" annotationCheck: "false" chaosServiceAccount: node-cpu-hog-sa experiments: name: node-cpu-hog spec: components: env: name: NODE_LABEL value: 'key=value' name: TOTALCHAOSDURATION value: '60' ``` It defines the percentage of nodes subjected to chaos with matching node labels. It can be tuned with `NODESAFFECTEDPERC` ENV. If `NODESAFFECTEDPERC` is provided as `empty` or `0` then it will target a minimum of one node. It is supported by [node-cpu-hog, node-memory-hog, node-io-stress] experiments. The rest of the experiment selects only a single node for the chaos. Use the following example to tune this: ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: "active" annotationCheck: "false" chaosServiceAccount: node-cpu-hog-sa experiments: name: node-cpu-hog spec: components: env: name: NODESAFFECTEDPERC value: '100' name: NODE_LABEL value: 'key=value' name: TOTALCHAOSDURATION value: '60' ```
Project: Vector (Observability and Analysis / Observability)
File: 2020-03-23-rename-gcp_stackdriver_logging-sink-to-gcp_stackdriver_logs.md

date: "2020-07-13" title: "The `gcpstackdriverlogging` sink has been renamed to `gcpstackdriverlogs`" description: "This brings the sink naming inline with consistent naming pattern" authors: ["binarylogic"] pr_numbers: [2121] release: "0.9.0" hideonrelease_notes: false badges: type: "breaking change" domains: ["sinks"] sinks: ["splunk_hec"] We've renamed the `gcpstackdriverlogging` sink to `gcpstackdriverlogs` to bring it in-line with consistent naming patterns. Migration is easy. ```diff title="vector.toml" [sinks.stackdriver] type = "gcpstackdriverlogging" type = "gcpstackdriverlogs" ```
Project: HertzBeat (Observability and Analysis / Observability)
File: debian.md

id: debian title: Monitoring Debian System Monitoring sidebar_label: Debian keywords: [Open Source Monitoring System, Operating System Monitoring, Debian Monitoring] Collect and monitor general performance metrics of the Debian system. | Parameter Name | Metric help description | | -- | -- | | Target Host | The monitored destination IPV4, IPV6, or domain name. Note: no protocol header (e.g., https://, http://). | | Task Name | A unique name to identify this monitoring task. | | Port | SSH port of the Debian system, default: 22 | | Timeout | Timeout for the connection, in milliseconds, default: 6000 milliseconds. | | Connection Reuse | Whether to reuse the SSH connection, default: false. False means a new connection will be created for each query. | | Username | Server username | | Password | Server password | | Collector | Configure which collector to use for scheduling this monitoring. | | Monitoring Period | The interval for periodically collecting data, in seconds, with a minimum interval of 30 seconds. | | Binding Tags | Used for categorizing and managing monitoring resources. | | Metric help description | Additional notes and Metric help descriptions for this monitoring, users can add notes here. | | Key | Key required to connect to the server. | | Metric Name | Metric Unit | Metric help description | | -- | -- | | | Host Name | N/A | Host name | | System Version | N/A | Operating system version | | Uptime | N/A | Boot time | | Metric Name | Metric Unit | Metric help description | | -- | -- | -- | | Info | N/A | Model | | Cores | N/A | Number of cores | | Interrupt | N/A | Number of interrupts | | Load | N/A | Load | | Context Switch | N/A | Context switches | | Usage | % | Usage rate | | Metric Name | Metric Unit | Metric help description | | - | -- | - | | Total Memory | Mb | Total memory capacity | | User Program Memory | Mb | Memory used by user programs | | Free Memory | Mb | Free memory capacity | | Buff Cache Memory | Mb | Memory used by cache | | Available Memory | Mb | Available memory | | Memory Usage | % | Memory usage rate | | Metric Name | Metric Unit | Metric help description | | - | -- | -- | | Disk Num | N/A | Total number of disks | | Partition Num | N/A | Total number of partitions | | Block Write | N/A | Number of disk blocks written | | Block Read | N/A | Number of disk blocks read | | Write Rate | iops | Disk write rate | Statistics for all network interface cards, including interface name, incoming data traffic, and outgoing data traffic. Metric Unit: Mb Statistics for all mounted file systems. Statistics include: file system, usage, available space, usage rate, mount point. Metric Unit: Usage: Mb Available Space: Mb Usage Rate: % Statistics for the top 10 processes by CPU usage. Statistics include: process ID, CPU usage rate, memory usage rate, command being executed. Metric Unit: CPU Usage Rate: % Memory Usage Rate: % Statistics for the top 10 processes by memory usage. Statistics include: process ID, memory usage rate, CPU usage rate, command being executed. Metric Unit: Memory Usage Rate: % CPU Usage Rate: %
Project: Netdata (Observability and Analysis / Observability)
File: configuration.md

Metrics streaming configuration for both Netdata Children and Parents is done via `stream.conf`. `netdata.conf` and `stream.conf` have the same `ini` format, but `netdata.conf` is considered a non-sensitive file, while `stream.conf` contains API keys, IPs and other sensitive information that enable communication between Netdata agents. `stream.conf` has 2 main sections: The `[stream]` section includes options for the sending Netdata (ie Netdata Children, or Netdata Parents that stream to Grand Parents, or to other sibling Netdata Parents in a cluster). The rest includes multiple sections that define API keys for the receiving Netdata (ie. Netdata Parents). To edit `stream.conf`, run this on your terminal: ```bash cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata sudo ./edit-config stream.conf ``` Your editor will open, with defaults and commented `stream.conf` options. To enable the reception of metrics from Netdata Children, generate a random API key with this command: ```bash uuidgen ``` Then, copy the UUID generated, , find the section that reads like the following and replace `API_KEY` with the UUID you generated: ```ini [API_KEY] enabled = yes ``` Save the file and restart Netdata. To enable streaming metrics to a Netdata Parent, , and at the `[stream]` section at the top, set: ```ini [stream] enabled = yes destination = PARENTIPADDRESS:19999 api key = API_KEY ``` Save the file and restart Netdata. While encrypting the connection between your parent and child nodes is recommended for security, it's not required to get started. This example uses self-signed certificates. Note This section assumes you have read the documentation on . <!-- here we need link to the section that will contain the restarting instructions --> Parent node To generate an SSL key and certificate using `openssl`, take a look at the related section around in our Documentation. Child node Update `stream.conf` to enable SSL/TLS and allow self-signed certificates. Append ':SSL' to the destination and uncomment 'ssl skip certificate verification'. ```conf [stream] enabled = yes destination = 203.0.113.0:SSL ssl skip certificate verification = yes api key = 11111111-2222-3333-4444-555555555555 ``` Restart the Netdata Agent on both the parent and child nodes, to stream encrypted metrics using TLS/SSL. You can find any issues related to streaming at Netdata logs. Netdata logs to systemd-journald by default, and its logs are available at the `Logs` tab of the UI. At the `MESSAGE_ID` field look for `Netdata connection from child` and `Netdata connection to parent`. On the Parents: ```bash journalctl -r --namespace=netdata MESSAGE_ID=ed4cdb8f1beb4ad3b57cb3cae2d162fa ``` On the Children: ```bash journalctl -r --namespace=netdata MESSAGE_ID=6e2e3839067648968b646045dbf28d66 ```
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: network-graph.md

title: Gadget network-graph The network-graph gadget monitors the network activity in the specified pods and records the list of TCP connections and UDP streams. ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: network-graph namespace: gadget spec: node: albantyphoon-worker000003 gadget: network-graph filter: namespace: demo runMode: Manual outputMode: Stream ``` Start network-graph ```bash $ kubectl annotate -n gadget trace/network-graph \ gadget.kinvolk.io/operation=start ``` Stop network-graph ```bash $ kubectl annotate -n gadget trace/network-graph \ gadget.kinvolk.io/operation=stop ``` Stream
Project: Vector (Observability and Analysis / Observability)
File: appsignal.md

title: AppSignal description: Deliver events to component_kind: sink layout: component tags: ["appsignal", "component", "sink", "logs", "metrics"] aliases: ["/docs/reference/configuration/sinks/appsignal"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: fluentbit-flow-control.md

Resources: https://docs.fluentbit.io/manual/administration/backpressure https://docs.fluentbit.io/manual/administration/buffering-and-storage https://docs.fluentbit.io/manual/pipeline/inputs/tail#sqlite-and-write-ahead-logging https://docs.fluentbit.io/manual/administration/monitoring https://docs.fluentbit.io/manual/administration/troubleshooting#dump-internals-signal Let's consider we have multiple separate inputs, each sending data to their respective dedicated outputs (using tenant ids in the tags). According to the referenced resources we need `storage.type filesystem` for every input where we want to avoid losing data. If we just enable this option, there will be no limit on how many data fluent-bit should keep on disk. Note: we also have to configure the position db to avoid fluent-bit reading the same files from the beginning after a restart The limit that is applied by default is `storage.maxchunksup 128` on the service which is a global limit. But this only means, that even if fluent-bit writes all chunks to disk, there is a limit on how many chunks it can read up and handle in memory at the same time. Without any further configuration fluent-bit will write chunks to disk indefinitely and this setting will only affect the overall throughput. In case we want to limit the actual disk usage we need to set `storage.totallimitsize` for every output individually. This sounds good, but the problem with this option is that it doesn't cause any backpressure, rather just starts to discard the oldest data, which obviously results in data loss, so this option should be used with care. Backpressure can be enabled using `storage.pauseonchunks_overlimit on` on the input which is great, but one important caveat again: the limit this setting considers as the trigger event is `storage.maxchunksup` which is a global limit. Going back to our main scenario, when one of the outputs is down (tenant is down), chunks for that output start to pile up on disk and in memory. When there are more than `storage.maxchunksup` chunks in memory globally, fluent-bit pauses inputs that tries to load additional chunks. It's not clear how fluent-bit decides which output should be paused, but based on our observations (using `config/samples/multitenant-routing` for example) this works as expected as only the input that belongs to the faulty output is paused and when the output gets back online, the input is resumed immediately. Also based on fluent-bit's metrics, if an output is permanently down, the chunks that are waiting for that output to be sent are not kept in memory, so other input/output pairs are not limited by the throughput. In case we configure `storage.pauseonchunks_overlimit` in the inputs we can make sure the disk usage is bounded. As long as pods are not restarting, the backpressure can prevent log loss, but keep in mind, that since the input is paused, data in log files that gets deleted by the container runtime during the output's downtime will get lost.
Project: Netdata (Observability and Analysis / Observability)
File: windows_ram_in_use.md

The `windowsramin_use` alert is triggered when memory utilization on a Windows system reaches the specified warning or critical thresholds. If you receive this alert, it means that your Windows system is running low on available memory. Memory utilization refers to the percentage of a system's RAM that is currently being used by applications, processes, and the operating system. High memory utilization can lead to performance issues and may cause applications to crash or become unresponsive. Check current memory usage on the system Press `Ctrl + Shift + Esc` to open Task Manager. Click on the `Performance` tab. View the `Memory` section to see the total memory usage and available memory. Identify high memory usage processes In Task Manager, click on the `Processes` tab. Click on the `Memory` column to sort processes by memory usage. Identify processes that are using a high percentage of memory. Optimize memory usage Close unnecessary applications and processes to free up memory. Investigate if running processes have a known memory leak issue. Consider upgrading the system's RAM if memory usage is consistently high. Monitor memory usage over time Use Windows Performance Monitor to create a Data Collector Set that collects memory usage metrics. Analyze the collected data to identify trends and potential issues.
Project: Grafana Loki (Observability and Analysis / Observability)
File: pull_request_template.md

What this PR does / why we need it: Which issue(s) this PR fixes: Fixes #<issue number> Special notes for your reviewer: Checklist guide (required) [ ] Documentation added [ ] Tests updated - Note that Promtail is considered to be feature complete, and future development for logs collection will be in . As such, `feat` PRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior. [ ] Changes that require user attention or interaction to upgrade are documented in `docs/sources/setup/upgrade/_index.md`
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: syslog-ng-date-parser.md

By default, the syslog-ng aggregator uses the time when a message has been received on its input source as the timestamp. In case we want to use the timestamp written in the message metadata, we should use a . To enable the timestamps written by the container runtime (cri or docker) and parsed by fluentbit automatically, we just have to define the `sourceDateParser` in the syslog-ng spec. ``` kind: Logging metadata: name: example spec: syslogNG: sourceDateParser: {} ``` In case we want to define our own parser format and template we can also do so (these are the default values): ``` kind: Logging metadata: name: example spec: syslogNG: sourceDateParser: format: "%FT%T.%f%z" template: "${json.time}" ```
Project: SkyWalking (Observability and Analysis / Observability)
File: micrometer-observations.md

Micrometer Observation is part of the Micrometer project and contains the Observation API. SkyWalking integrates its MicroMeter 1.10 APIs so that it can send metrics to the SkyWalking . Follow Java agent to set up agent in the Spring first. Make sure to enable meter receiver in `application.yml`. ```yaml receiver-meter: selector: ${SWRECEIVERMETER:default} default: ``` Configure the meter config file. It already has the . If you have a customized meter at the agent side, please configure the meter using the steps set out in the . Enable Spring sleuth config in `application.yml`. ```yaml agent-analyzer: selector: ${SWAGENTANALYZER:default} default: meterAnalyzerActiveFiles: ${SWMETERANALYZERACTIVEFILES:spring-micrometer} ``` SkyWalking provides the Spring Sleuth dashboard by default under the general service instance, which contains the metrics provided by Spring Sleuth by default. Once you have added customized metrics in the application and configuration the meter config file in the backend. Please following the to add the metrics in the dashboard. Three types of information are supported: Application, System, and JVM. Application: HTTP request count and duration, JDBC max/idle/active connection count, and Tomcat session active/reject count. System: CPU system/process usage, OS system load, and OS process file count. JVM: GC pause count and duration, memory max/used/committed size, thread peak/live/daemon count, and classes loaded/unloaded count.
Project: M3 (Observability and Analysis / Observability)
File: binaries.md

linktitle: "Binaries" title: Creating a Single Node M3 Cluster with Binaries weight: 3 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 M3 cluster is a great way to experiment with M3 and get an idea of what it has to offer, but is not designed for production use. To run M3 in clustered mode, with a separate M3Coordinator . {{% /notice %}} M3 has pre-built binaries available for Linux and macOS. . {{< fileinclude file="build_prerequisites.md" >}} ```shell make m3dbnode ``` By default the binary configures a single M3 instance 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. An M3Coordinator instance for writing and querying tagged metrics, as well as managing cluster topology and runtime configuration. It exposes three 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 M3Coordinator The command below starts the node using the specified configuration file. {{< tabs name="start_container" >}} {{% tab name="Pre-built binary" %}} . ```shell ./m3dbnode -f /{FILE_LOCATION}/m3dbnode-local-etcd.yml ``` {{% notice info %}} Depending on your operating system setup, you might need to prefix the command with `sudo`. {{% /notice %}} {{% /tab %}} {{% tab name="Self-built binary" %}} ```shell ./bin/m3dbnode -f ./src/dbnode/config/m3dbnode-local-etcd.yml ``` {{% notice info %}} Depending on your operating system setup, you might need to prefix the command with `sudo`. {{% /notice %}} {{% /tab %}} {{% tab name="Output" %}} <!-- TODO: Perfect image, pref with terminalizer --> <!-- TODO: Update image --> {{% /tab %}} {{< /tabs >}} {{% notice info %}} When running the command above on macOS you may see errors about "too many open files." To fix this in your current terminal, use `ulimit` to increase the upper limit, for example `ulimit -n 10240`. {{% /notice %}} This example uses this by default. The file groups configuration into `coordinator` or `db` sections that represent the `M3Coordinator` and `M3DB` instances of single-node cluster. {{% notice tip %}} You can find more information on configuring M3DB in the . {{% /notice %}} {{< fileinclude file="quickstart-common-steps.md" >}}
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: progressive.md

A progressive rollout allows you to increase the percentage of your flag over time. You can select a release ramp where the percentage of your flag will increase progressively between the start date and the end date. ``` yaml progressive-flag: true: "B" false: "A" default: "Default" rollout: progressive: percentage: initial: 0 end: 100 releaseRamp: start: 2021-03-20T00:00:00.10-05:00 end: 2021-03-21T00:00:00.10-05:00 ``` ``` json { "progressive-flag": { "true": "B", "false": "A", "default": "Default", "rollout": { "progressive": { "percentage": { "initial": 0, "end": 100 }, "releaseRamp": { "start": "2021-03-20T05:00:00.100Z", "end": "2021-03-21T05:00:00.100Z" } } } } } ``` ``` toml [progressive-flag] true = "B" false = "A" default = "Default" [progressive-flag.rollout] [progressive-flag.rollout.progressive] [progressive-flag.rollout.progressive.percentage] initial = 0.0 end = 100.0 [progressive-flag.rollout.progressive.releaseRamp] start = 2021-03-20T05:00:00.100Z end = 2021-03-21T05:00:00.100Z ``` :::info The dates are in the format supported natively by your flag file format. ::: | Field | Description | |-|--| | `releaseRamp` | It contains the time slot where we will progressively increase the percentage of the flag.<ul><li>Before the `start` date we will serve the `percentage.initial` percentage of the flag.</li><li>Between `start` and `end` we will serve a percentage of the flag corresponding of the actual time.</li><li>After the `end` date we will serve the `percentage.end` percentage of the flag.</li></ul><p>If you have no date in your `releaseRamp` we will not do any progressive rollout and use the top level percentage you have configured (0% in our example).</p> | | `percentage` | (optional)<br/>It represents the ramp of progress, at which level the flag starts (`initial`) and at which level it ends (`end`).<br/>Default: `initial` = `0` and `end` = `100` |
Project: Grafana Mimir (Observability and Analysis / Observability)
File: query-step-alignment-analysis.md

This tools allow to parse the query stats log messages of query-frontends to understand the impact toggling query-step-alignment. This requires a working Loki and logcli setup for the Mimir cluster ``` $ logcli query '{namespace="mimir", container="query-frontend"} |="path=/prometheus/api/v1/query_range" | logfmt' --limit 1000000 --output jsonl | go run main.go time-frame: 2022-01-27 09:35:52.108468366 +0000 UTC to 2022-01-27 10:35:51.62229847 +0000 UTC total queries: 192338 cachable-today: 86232 44.83% cachable-without-step-align: 85372 44.39% step-aligned: 168402 87.56% ```
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-7-5-0.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 7.5.0 <!-- Auto generated by update changelog github action --> Alerting: Add ability to include aliases with hyphen in InfluxDB. , CloudWatch: Use latest version of aws sdk. , Alerting: Add ability to include aliases with hyphen in InfluxDB. , DashboardSettings: Fixes issue with tags list not updating changes are made. , DashboardSettings: Fixes issue with tags list not updating changes are made. , Loki: Fix text search in Label browser. ,