cwielenb/CNCF-Dataset huggingface dataset:
Project: Grafana Loki (Observability and Analysis / Observability)
File: labels.md

title: labels menuTitle: description: The 'labels' Promtail pipeline stage. aliases: ../../../clients/promtail/stages/labels/ weight: The labels stage is an action stage that takes data from the extracted map and modifies the label set that is sent to Loki with the log entry. ```yaml labels: [ <string>: [<string>] ... ] ``` For the given pipeline: ```yaml json: expressions: stream: stream labels: stream: ``` Given the following log line: ``` {"log":"log message\n","stream":"stderr","time":"2019-04-30T02:12:41.8443515Z"} ``` The first stage would extract `stream` into the extracted map with a value of `stderr`. The labels stage would turn that key-value pair into a label, so the log line sent to Loki would include the label `stream` with a value of `stderr`.
Project: Netdata (Observability and Analysis / Observability)
File: uptime.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/integrations/uptime.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/metadata.yaml" sidebar_label: "uptime" 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/freebsd.svg" width="150"/> Plugin: freebsd.plugin Module: uptime <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Show period of time server is up. The plugin calls `clock_gettime` 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. How long the system is running. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | system.uptime | uptime | seconds | 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.loadavg | Enable or disable load average metric. | yes | no | </details> There are no configuration examples.
Project: Checkmk (Observability and Analysis / Observability)
File: 16276.md

key | value | compatible | yes version | 2.3.0b1 date | 2023-12-18T11:39:31+00:00 level | 1 class | fix component | checks edition | cre The services picked the device levels meant for a "less than" comarison, when in fact comparing "less or equal" (as Checkmk usually does). They now pick the levels meant for "less or equal" comparison.
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: CONTRIBUTING.md

title: " Crane " description: " Crane " weight: 10 Welcome to Crane! This document is a guideline about how to contribute to Crane. You can contribute to Crane in several ways. Here are some examples: Contribute to the Crane codebase. Report bugs. Suggest enhancements. Write technical documentation and blog posts, for users and contributors. Organize meetups and user groups in your local area. Help others by answering questions about Crane. For more ways to contribute, check out the . Before submitting a new issue, try to make sure someone hasn't already reported the problem. Look through the for similar issues. Report a bug by submitting a . Make sure that you provide as much information as possible on how to reproduce the bug. If you have an idea to improve Crane, submit an .
Project: KubeSkoop (Observability and Analysis / Observability)
File: SECURITY.md

| Version | Supported | | - | | | 1.0.0 | :whitecheckmark: | | < 1.0.0 | :x: | DO NOT CREATE AN ISSUE to report a security problem. Instead, please send an email to We learn about critical software updates and security threats from these sources GitHub Security Alerts Dependency Updates
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_networkpolicy.NetworkPolicyPort.md

title: "Interface: NetworkPolicyPort" linkTitle: "NetworkPolicyPort" slug: "libk8snetworkpolicy.NetworkPolicyPort" .NetworkPolicyPort `Optional` endPort: `number` _ `Optional` port: `string` \| `number` _ `Optional` protocol: `string`
Project: Vector (Observability and Analysis / Observability)
File: 2021-01-10-kafka-sink-metrics.md

date: "2021-01-10" title: "The `kafka` sink now supports metrics" description: "Send metric events to Kafka" authors: ["binarylogic"] featured: false pr_numbers: [] release: "0.12.0" hideonrelease_notes: false badges: type: "enhancement" domains: ["metrics"] sinks: ["kafka"] The now supports metrics, making it possible to send metric events through Kafka. Metrics events are encoded into a format that mimics our [internal metrics data model], ideal for custom consumers on the other end. Getting started is easy: ```toml [sources.host_metrics] type = "host_metrics" [sinks.kafka] type = "kafka" inputs = ["host_metrics"] encoding.codec = "json" ``` We currently do not support ingesting metric events in the `kafka` source. This is due to the hesitation to introduce yet another metrics format into the world. Instead, we are working to support an open metrics format that the `kafka` source and sink will support. See [issue 5809] for more info.
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-1.3.1.md

Exclude man page symlink in distribution (#2602) Fri, 25 Mar 2022 18:36:36 -0400 This is a short-term solution to unblock the build process for the 1.3 release. A tool used in that process (cpio) is failing on a symlink in the JDK man pages, so this is a hack to just remove that symlink. See issue #2517 for more details. Signed-off-by: Andrew Ross &lt;andrross@amazon.com&gt; Bump the version to 1.3.1 (#2509) Mon, 21 Mar 2022 10:30:00 -0400 Signed-off-by: Zelin Hao &lt;zelinhao@amazon.com&gt;
Project: Checkmk (Observability and Analysis / Observability)
File: 16367.md

key | value | date | 2024-02-09T13:24:13+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | no Since the DELETE method actually archives the audit_log entries, this endpoint is replaced by domain-types/audit_log/actions/archive/invoke The DELETE endpoint is deprecated and will be removed on version 2.4.0. In order to update their scripts, users should replace curl -x DELETE http://host/site/api/1.0/domain-types/audit_log/collections/all with curl -x POST http://host/site/api/1.0/domain-types/audit_log/actions/archive/invoke
Project: Grafana (Observability and Analysis / Observability)
File: configure-request-security.md

aliases: ../../enterprise/request-security/ description: Request security enables you to limit requests from the Grafana server by targeting requests generated by users, such as data source metric queries and alert notifications. labels: products: cloud enterprise title: Configure request security weight: 1100 Request security allows you to limit requests from the Grafana server by targeting requests generated by users, such as data source metric queries and alert notifications. This can be used to limit access to internal systems that the server Grafana runs on can access but that users of Grafana should not be able to access. This feature does not affect traffic from the Grafana users browser. {{% admonition type="note" %}} Available in version 7.4 and later, and . {{% /admonition %}} {{% admonition type="note" %}} Although request security works with backend plugins, you can create a backend plugin that bypasses this security. {{% /admonition %}} You can limit requests based on a hostname, an IP address, or both. Grafana blocks any request to a hostname or IP address on the deny list. If there is at least one entry on the list, then any request to a hostname or IP address not on the list is denied. For example: ```toml [security.egress] hostdenylist = supersecret.internal 192.168.1.10 hostallowlist = prometheus.internal ``` You can set a list of cookies or headers that are to be dropped from outgoing requests. Example: ```toml [security.egress] headerdroplist = user cookiedroplist = session_id ```
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-alarm_events_create.md

category: Alarm apiurl: '/api/v1/alarm/events' title: 'Create Events' type: 'POST' sample_doc: 'alarm.html' layout: default Required Content-type: application/x-www-form-urlencoded Key|Value | endTime|1466628960 eventid|s165_cef145900bf4e2a4a0db8b85762b9cdb startTime|1466611200 ```Status: 200``` ``` [ { "cond": "10.649350649350648 != 66", "eventcaseId": "s165_cef145900bf4e2a4a0db8b85762b9cdb", "id": 635166, "status": 0, "step": 0, "timestamp": "2016-06-23T04:55:00+08:00" }, { "cond": "13.486005089058525 != 66", "eventcaseId": "s165_cef145900bf4e2a4a0db8b85762b9cdb", "id": 635149, "status": 0, "step": 0, "timestamp": "2016-06-23T04:50:00+08:00" } ] ``` For errors responses, see the .
Project: Kuberhealthy (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 ComcastOpenSource_Services@comcast.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and 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: Grafana (Observability and Analysis / Observability)
File: release-notes-8-0-3.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 8.0.3 <!-- Auto generated by update changelog github action --> Alerting: Increase alertmanager_conf column if MySQL. , Time series/Bar chart panel: Handle infinite numbers as nulls when converting to plot array. , TimeSeries: Ensure series overrides that contain color are migrated, and migrate the previous `fieldConfig` when changing the panel type. , ValueMappings: Improve singlestat value mappings migration. , Annotations: Fix annotation line and marker colors. , AzureMonitor: Fix KQL template variable queries without default workspace. , CloudWatch/Logs: Fix missing response data for log queries. , Elasticsearch: Restore previous field naming strategy when using variables. , LibraryPanels: Fix crash in library panels list when panel plugin is not found. , LogsPanel: Fix performance drop when moving logs panel in dashboard. , Loki: Parse log levels when ANSI coloring is enabled. , MSSQL: Fix issue with hidden queries still being executed. , PanelEdit: Display the VisualizationPicker that was not displayed if a panel has an unknown panel plugin. , Plugins: Fix loading symbolically linked plugins. , Prometheus: Fix issue where legend name was replaced with name Value in stat and gauge panels. , State Timeline: Fix crash when hovering over panel. ,
Project: Graphite (Observability and Analysis / Observability)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: enhancement assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: ulidtime.md

`ulidtime` is a tiny tool to parse and print the time embedded in it. Example: ``` $ ulidtime 01FRCN18HV5B638BKNF4H52JP6 01FRCHB3HX5VBE6HJGSC4NW9DG 01FRCFGMP7TAXD2PTNWVW8RYYC 01FRCJHSJX7PQ38VQFQ2T9EF70 01FRCN18HV5B638BKNF4H52JP6 2022-01-02T05:43:41.883Z 01FRCHB3HX5VBE6HJGSC4NW9DG 2022-01-02T04:39:10.141Z 01FRCFGMP7TAXD2PTNWVW8RYYC 2022-01-02T04:07:14.375Z 01FRCJHSJX7PQ38VQFQ2T9EF70 2022-01-02T05:00:17.885Z ``` ``` ulidtime -header -entropy -millis 01H8G30YH46MCFWK10PMXJN2KW 01H8K2R3AZT7N9JSJFF2NDGEA9 01H8N8E7SCB3PBBD6PERMJ7PEJ 01H8QTZPEXGG8TEQFBKY0BPQMF 01H8TDCKH5WM2D56KSGNATE9RT 01H8X1ZFE5BED94C7JX88ZF9K4 01H8ZN7G70Z28DDCXTPF7H8DJ4 01H926WF74G7YFWZ1394S7616G 01H94S30Z0VZQP3GWQX2X2X524 01H97970YAQ4EKCZ6QS1QB4Q27 01H99YVZ0ACNDYXF6FMWM91V4S 01H9CFBYCS0XHYNW10X1HC8NSQ 01H9F454S0KD1VAYW53225D60D 01H9HKGZ8PDWSEJYMPRZBG65YN ULID TIMESTAMP MILLISECONDS RANDOM 01H8G30YH46MCFWK10PMXJN2KW 2023-08-23T02:19:22.532Z 1692757162532 3518fe4c20b53b2a8a7c 01H8K2R3AZT7N9JSJFF2NDGEA9 2023-08-24T06:12:15.839Z 1692857535839 d1ea99664f78aad83949 01H8N8E7SCB3PBBD6PERMJ7PEJ 2023-08-25T02:30:13.036Z 1692930613036 58ecb5b4d6762923d9d2 01H8QTZPEXGG8TEQFBKY0BPQMF 2023-08-26T02:32:48.349Z 1693017168349 8411a75deb9f80bb5e8f 01H8TDCKH5WM2D56KSGNATE9RT 2023-08-27T02:32:54.565Z 1693103574565 e504d29a798555a7271a 01H8X1ZFE5BED94C7JX88ZF9K4 2023-08-28T03:11:13.349Z 1693192273349 5b9a9230f2ea11f7a664 01H8ZN7G70Z28DDCXTPF7H8DJ4 2023-08-29T03:26:08.096Z 1693279568096 f890d6b3bab3cf143644 01H926WF74G7YFWZ1394S7616G 2023-08-30T03:13:09.86Z 1693365189860 81fcfe7c2349327304d0 01H94S30Z0VZQP3GWQX2X2X524 2023-08-31T03:09:47.872Z 1693451387872 dfef61c397e8ba2e9444 01H97970YAQ4EKCZ6QS1QB4Q27 2023-09-01T02:30:05.002Z 1693535405002 b91d367cd7c86eb25c47 01H99YVZ0ACNDYXF6FMWM91V4S 2023-09-02T03:27:00.106Z 1693625220106 655beebccfa72890ec99 01H9CFBYCS0XHYNW10X1HC8NSQ 2023-09-03T02:53:49.849Z 1693709629849 0763eaf020e862c45737 01H9F454S0KD1VAYW53225D60D 2023-09-04T03:35:35.968Z 1693798535968 9b43b57b85188456980d 01H9HKGZ8PDWSEJYMPRZBG65YN 2023-09-05T02:42:41.046Z 1693881761046 6f32e97a96c7d70317d5 ```
Project: SkyWalking (Observability and Analysis / Observability)
File: why_mq_not_involved.md

This is often asked by those who are first introduced to SkyWalking. Many believe that MQ should have better performance and should be able to support higher throughput, like the following: <img src="MQ-involved-architecture.png"/> Here's what we think. This question arises when users consider the circumstances where the OAP cluster may not be powerful enough or becomes offline. But the following issues must first be addressed: Why do you think that the OAP is not powerful enough? Were it not powerful, the speed of data analysis wouldn't have caught up with the producers (or agents). Then what is the point of adding new deployment requirements? Some may argue that the payload is sometimes higher than usual during peak times. But we must consider how much higher the payload really is. If it is higher by less than 40%, how many resources would you use for the new MQ cluster? How about moving them to new OAP and ES nodes? Say it is higher by 40% or more, such as by 70% to 200%. Then, it is likely that your MQ would use up more resources than it saves. Your MQ would support 2 to 3 times the payload using 10%-20% of the cost during usual times. Furthermore, in this case, if the payload/throughput are so high, how long would it take for the OAP cluster to catch up? The challenge here is that well before it catches up, the next peak times would have come. With the analysis above in mind, why would you still want the traces to be 100%, given the resources they would cost? The preferred way to do this would be adding a better dynamic trace sampling mechanism at the backend. When throughput exceeds the threshold, gradually modify the active sampling rate from 100% to 10%, which means you could get the OAP and ES 3 times more powerful than usual, while ignoring the traces at peak times. Even though MQ transport is not recommended from the production perspective, SkyWalking still provides optional plugins named `kafka-reporter` and `kafka-fetcher` for this feature since 8.1.0. Log and trace exporters are using MQ as transport channel. And metrics exporter uses gRPC, as considering the scale.
Project: Netdata (Observability and Analysis / Observability)
File: 10min_fifo_errors.md

Between the IP stack and the Network Interface Controller (NIC) lies the driver queue. This queue is typically implemented as a FIFO ring buffer into the memory space allocated by the driver. The NIC receive frames and place them into memory as skbbuff data structures (SocKet Buffer). We can have queues (ingress queues) and transmitted (egress queues) but these queues do not contain any actual packet data. Each queue has a pointer to the devices associated with it, and to the skbbuff data structures that store the ingress/egress packets. The number of frames this queue can handle is limited. Queues fill up when an interface receives packets faster than kernel can process them. Netdata monitors the number of FIFO errors (number of times an overflow occurs in the ring buffer) for a specific network interface in the last 10 minutes. This alarm is triggered when the NIC is not able to handle the peak load of incoming/outgoing packets with the current ring buffer size. Not all NICs support FIFO queue operations. The SocKet Buffer (SKB), is the most fundamental data structure in the Linux networking code. Every packet sent or received is handled using this data structure. This is a large struct containing all the control information required for the packet (datagram, cell, etc). The struct sk_buff has the following fields to point to the specific network layer headers: transport_header (previously called h) This field points to layer 4, the transport layer (and can include tcp header or udp header or icmp header, and more) network_header (previously called nh) This field points to layer 3, the network layer (and can include ip header or ipv6 header or arp header). mac_header (previously called mac) This field points to layer 2, the link layer. skbnetworkheader(skb), skbtransportheader(skb) and skbmacheader(skb) - These return pointer to the header. Update the ring buffer size To view the maximum RX ring buffer size: ``` ethtool -g enp1s0 ``` If the values in the Pre-set maximums section are higher than in the Current hardware settings section, increase RX (or TX) ring buffer: ``` enp1s0 rx 4080 ``` Verify the change to make sure that you no longer receive the alarm when running the same workload. To make this permanently, you must consult your distribution guides.
Project: Netdata (Observability and Analysis / Observability)
File: consul_raft_leadership_transitions.md

This alert triggers when there is a `leadership transition` in the `Consul` service mesh. If you receive this alert, it means that server `${label:node_name}` in datacenter `${label:datacenter}` has become the new leader. Consul is a service mesh solution that provides service discovery, configuration, and segmentation functionality. It uses the Raft consensus algorithm to maintain a consistent data state across the cluster. A leadership transition occurs when the current leader node loses its leadership status and a different node takes over. Leadership transitions in Consul can be caused by various reasons, such as: Network communication issues between the nodes. High resource utilization on the leader node, causing it to miss heartbeat messages. Nodes crashing or being intentionally shut down. A forced leadership transition triggered by an operator. Frequent leadership transitions may lead to service disruptions, increased latency, and reduced availability. Therefore, it's essential to identify and resolve the root cause promptly. Check the Consul logs for indications of network issues or node failures: ``` journalctl -u consul.service ``` Alternatively, you can check the Consul log file, which is usually located at `/var/log/consul/consul.log`. Inspect the health and status of the Consul cluster using the `consul members` command: ``` consul members ``` This command lists all cluster members and their roles, including the new leader node. Determine if there's high resource usage on the affected nodes by monitoring CPU, memory, and disk usage: ``` top ``` Examine network connectivity between nodes using tools like `ping`, `traceroute`, or `mtr`. If the transitions are forced by operators, review the changes made and their impact on the cluster. Consider increasing the heartbeat timeout configuration to allow the leader more time to respond, especially if high resource usage is causing frequent leadership transitions. Review Consul's documentation on and to gain insights into best practices and ways to mitigate leadership transitions.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_cluster.KubeMetrics.md

title: "Interface: KubeMetrics" linkTitle: "KubeMetrics" slug: "libk8scluster.KubeMetrics" .KubeMetrics metadata: _ status: `Object` | Name | Type | | : | : | | `capacity` | { `cpu`: `string` ; `memory`: `string` } | | `capacity.cpu` | `string` | | `capacity.memory` | `string` | _ usage: `Object` | Name | Type | | : | : | | `cpu` | `string` | | `memory` | `string` |