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

This alert is triggered when there is a high number of outbound errors on a specific network interface in the last 10 minutes on a FreeBSD system. When you receive this alert, it means that the network interface is facing transmission-related issues, such as aborted, carrier, FIFO, heartbeat, or window errors. Identify the network interface with the problem Use `ifconfig` to get a list of all network interfaces and their error count: ``` ifconfig -a ``` Check the "Oerrs" (Outbound errors) field for each interface to find the one with the issue. Check the interface speed and duplex settings The speed and duplex settings may mismatch between the network interface and the network equipment (like switches and routers) that it is connected to. Use `ifconfig` or `ethtool` to check these settings. With `ifconfig`: ``` ifconfig <interface_name> ``` If required, adjust the speed and duplex settings using `ifconfig`: ``` ifconfig <interfacename> media <mediatype> ``` `<media_type>` can be one of the following: 10baseT/UTP, 100baseTX, 1000baseTX, etc., and can include half-duplex or full-duplex. Example: ``` ifconfig em0 media 1000baseTX mediaopt full-duplex ``` Ensure both the network interface and the connected device use the same settings. Check network cables and devices Check the physical connections of the network cable to both the network interface and the network equipment it connects to. Replace the network cable if necessary. Additionally, verify if the issue is related to the connected network equipment (switches and routers). Analyze network traffic Use tools like `tcpdump` or `Wireshark` to analyze the network traffic on the affected interface. This can give you insights into the root cause of the errors and help in troubleshooting device or network-related issues. )
Project: Grafana Mimir (Observability and Analysis / Observability)
File: helm-chart.md

description: Learn how to deploy Mimir with Helm. menuTitle: Deploy with Helm title: Deploy Mimir with Helm weight: 10 The for Grafana Mimir and Grafana Enterprise Metrics allows you to configure, install, and upgrade Grafana Mimir or Grafana Enterprise Metrics within a Kubernetes cluster. To deploy Mimir using the `mimir-distributed` Helm chart, see .
Project: Hubble (Observability and Analysis / Observability)
File: LICENSE.md

Copyright (c) 2013-2020, Frank Schroeder All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: pole_emploi.md

is the public employment service in France. Its roles are, on the one hand, to compensate job seekers and help them find a job, and on the other hand, to guide companies in their recruitment. In order to do that, Ple emploi's agents are mobilized on a daily basis to anticipate trends, innovate and bring together key players and relays in the field. With around 5.6 millions end-users, and applications that generate hudge traffic and datas, the resiliency of our apps and infrastructures is a must-have! Litmus is OPEN SOURCE Litmus is designed for Kubernetes Litmus is easy to deploy ( helm chart ) Litmus is extendable ( experiments libs, predefined workflows, private hubs ) We explored Litmus to validate and increase the resiliency of our private and public Kubernetes clouds. Testing resiliency of Kubernetes Infrastructure Components Testing resiliency of Public applications hosted on Kubernetes Testing resiliency of Private applications hosted on Kubernetes Litmus allowed us to identify and work on the observability, configuration, and high availability of certain components which were not resilient. With the history of experiences, the Reliability score system, and all the statistics on the chaos tests, using random recurring tests, litmus allows us to audit, over time, the resilience of our platforms, and to have a global vision of the state of it.
Project: Netdata (Observability and Analysis / Observability)
File: geth_chainhead_diff_between_header_block.md

The `gethchainheaddiffbetweenheader_block` alert is generated by the Netdata Agent when monitoring an Ethereum node using the Geth client. The alert is triggered when there is a significant difference between the chain head header and the actual block number. This indicates that your Ethereum node is out of sync with the rest of the network, and you may experience issues when trying to interact with the blockchain. Check the sync status of your Ethereum node: To determine the current sync status of your Ethereum node, execute the following command in the Geth console: ``` eth.syncing ``` If your node is syncing, you'll see information about the syncing progress. If it's not syncing, the command will return `false`. Restart Geth: If your node is not syncing, try restarting Geth with the appropriate command for your operating system. For example: ``` sudo systemctl restart geth ``` If Geth isn't running as a system service, you may need to restart it manually. Ensure you're using the correct command-line flags and options. Check Geth logs: Inspect the Geth logs for any issues or errors that may provide insight into the problem. You can find the logs in the default log directory or use the `--log-dir` flag to specify a custom log directory. To view the logs in real-time, run: ``` tail -f /path/to/your/log/directory/geth.log ``` Ensure your system time is accurate: An incorrect system time can cause syncing issues. Make sure your system clock is accurate and synchronized with an NTP server: ``` sudo ntpdate -s time.nist.gov ``` Upgrade Geth: Ensure you are running the latest version of Geth. Upgrading to the latest version can resolve issues and improve synchronization. You can find the latest release on the . Check your network connection: Verify that your node has a stable and reliable network connection. If you're on a shared network, consider increasing the bandwidth or moving the node to a dedicated network.
Project: Netdata (Observability and Analysis / Observability)
File: vm.stats.sys.v_intr.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/integrations/vm.stats.sys.v_intr.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/metadata.yaml" sidebarlabel: "vm.stats.sys.vintr" 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: vm.stats.sys.v_intr <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Device interrupts 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 metric show device interrupt frequency. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | system.dev_intr | interrupts | interrupts/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 option</summary> | Name | Description | Default | Required | |:-|:--|:-|:--:| | vm.stats.sys.v_intr | Enable or disable device interrupts metric. | yes | no | </details> There are no configuration examples.
Project: Vector (Observability and Analysis / Observability)
File: 2020-05-05-add-support-for-include-exclude-units.md

date: "2020-07-14" title: "Journald Unit Filtering Exclusions" description: "The journald source can now exclude units." authors: ["hoverbear"] hideonrelease_notes: false pr_numbers: [2540] release: "0.10.0" badges: type: "new feature" sources: ["journald"] Often when you tap into the Journald source you're only really interested in a subset of the units, previously, Vector supported this. However, sometimes you just want to exclude one or two. Now, Vector can practice selective listening on Journald, ignoring units. Vector filters these directly at the source, offering better performance and easier use. You can find the old `units` option lives at `includeunits` now, while a new `excludeunits` option now exists. You can make the following changes in your `vector.toml` file: ```diff title="vector.toml" [sources.mysourceid] type = "journald" # required currentbootonly = true # optional, default units = ["sshd", "ircd"] exclude_units = ["zulip"] # optional, default include_units = ["sshd", "ircd"] # optional, default ```
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: about-tenant-ids.md

aliases: /docs/phlare/latest/operators-guide/configuring/about-tenant-ids/ /docs/phlare/latest/configure-server/about-tenant-ids/ description: Learn about tenant ID restrictions. menuTitle: About tenant IDs title: About Grafana Pyroscope tenant IDs weight: 40 Grafana Pyroscope is a multi-tenant system where tenants can query profiles that include their tenant ID. Within a Grafana Pyroscope cluster, the tenant ID is the unique identifier of a tenant. The query takes the tenant ID from the `X-Scope-OrgID` parameter that exists in the HTTP header of each request, for example `X-Scope-OrgID: <TENANT-ID>`. To push profiles to Grafana Pyroscope for a specific tenant, refer to . By default, multi-tenancy is disabled, the tenant ID is ignored and all profiles are stored and retrieved with the same tenant (`anonymous`). To enable multi-tenancy, add the `multitenancy_enabled` parameter to the Grafana Pyroscope configuration file and set it to `true`. Alternatively you can also use command line arguments to enable multi-tenancy, for example `--auth.multitenancy-enabled=true`. Tenant IDs cannot be longer than 150 bytes or characters in length and can only include the following supported characters: Alphanumeric characters `0-9` `a-z` `A-Z` Special characters Exclamation point (`!`) Hyphen (`-`) Underscore (`_`) Single period (`.`) Asterisk (`*`) Single quote (`'`) Open parenthesis (`(`) Close parenthesis (`)`) Note: For security reasons, `.` and `..` are not valid tenant IDs. All other characters, including slashes and whitespace, are not supported.
Project: Chaos Toolkit (Observability and Analysis / Chaos Engineering)
File: CODE_OF_CONDUCT.md

Chaos Toolkit adopts Debian project's Code Of Conduct for its participants and contributors. In the Chaos Toolkit project, inevitably there will be people with whom you may disagree, or find it difficult to cooperate. Accept that, but even so, remain respectful. Disagreement is no excuse for poor behaviour or personal attacks, and a community in which people feel threatened is not a healthy community. Chaos Toolkit contributors have many ways of reaching our common goal of an open API for Chaos Engineering which may differ from your ways. Assume that other people are working towards this goal. Note that many of our Contributors are from around the globe, not native English speakers and may have different cultural backgrounds. Chaos Toolkit is a large project; there is always more to learn within it. It's good to ask for help when you need it. Similarly, offers for help should be seen in the context of our shared goal of improving Chaos Toolkit. When you make something for the benefit of the project, be willing to explain to others how it works, so that they can build on your work to make it even better. Keep in mind that what you write once will be read by hundreds of people. Writing a short email means people can understand the conversation as efficiently as possible. When a long explanation is necessary, consider adding a summary. Try to bring new arguments to a conversation so that each mail adds something unique to the thread, keeping in mind that the rest of the thread still contains the other messages with arguments that have already been made. Try to stay on topic, especially in discussions that are already fairly large. Most ways of communication used within Chaos Toolkit allow for public and private communication. You should use public methods of communication for Chaos Toolkit related messages, unless posting something sensitive. While this code of conduct should be adhered to by participants, we recognize that sometimes people may have a bad day, or be unaware of some of the guidelines in this code of conduct. When that happens, you may reply to them and point out this code of conduct. Instances of otherwise unacceptable behavior may be reported by contacting team at contact@chaostoolkit.org. All complaints will be reviewed and investigated and will result in a response that is appropriate to the circumstances. This Code of Conduct is adapted from the , version 1.0
Project: Kuberhealthy (Observability and Analysis / Observability)
File: proposal.md

name: Proposal about: Suggest an idea for this project title: '' labels: proposal assignees: '' Describe the solution you would like to see happen A clear and concise description of what you want to happen. How do you propose we build it? Include any gory development or architecture details about how you would like to see this get done. Additional context Add any other context or screenshots about the feature request here.
Project: M3 (Observability and Analysis / Observability)
File: m3query_intro.md

M3 Query is a distributed query engine for querying realtime and historical data stored in M3DB nodes, supporting several query languages. It is designed to support both low latency realtime queries and queries that can take longer to execute, aggregating over larger datasets for analytical use cases. For example, if you are using the Prometheus remote write endpoint with , you can use M3 Query instead of the Prometheus remote read endpoint. By doing so, you get all the benefits of M3 Query's engine such as . As M3 Query provides a Prometheus compatible API, you can use 3rd party graphing and alerting solutions like Grafana.
Project: Vector (Observability and Analysis / Observability)
File: 2020-04-07-vector-to-vector-metrics.md

date: "2020-04-14" title: "The Vector Source Now Accepts Metrics" description: "It's not possible to forward metrics between Vector instances" authors: ["binarylogic"] pr_numbers: [2245] release: "0.9.0" hideonrelease_notes: true badges: type: "new feature" domains: ["sources"] sources: ["vector"] Until recently the only accepted . Supporting metrics was blocked by pending metric data model development, as well as topology improvements. removes that limitation enabling you to truly build observability pipelines that can process both logs and metrics, such as the .
Project: M3 (Observability and Analysis / Observability)
File: headers_optional_read_write.md

`M3-Metrics-Type`: If this header is set, it determines what type of metric to store this metric value as. Otherwise by default, metrics will be stored in all namespaces that are configured. You can also disable this default behavior by setting `downsample` options to `all: false` for a namespace in the coordinator config, for more see . Must be one of: `unaggregated`: Write metrics directly to configured unaggregated namespace. `aggregated`: Write metrics directly to a configured aggregated namespace (bypassing any aggregation), this requires the `M3-Storage-Policy` header to be set to resolve which namespace to write metrics to. `M3-Storage-Policy`: If this header is set, it determines which aggregated namespace to read/write metrics directly to/from (bypassing any aggregation). The value of the header must be in the format of `resolution:retention` in duration shorthand. e.g. `1m:48h` specifices 1 minute resolution and 48 hour retention. Valid time units are "ns", "us" (or "s"), "ms", "s", "m", "h".<br /><br /> Here is of querying metrics from a specific namespace.
Project: Netdata (Observability and Analysis / Observability)
File: ipfw.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/integrations/ipfw.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/metadata.yaml" sidebar_label: "ipfw" 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/firewall.svg" width="150"/> Plugin: freebsd.plugin Module: ipfw <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Collect information about FreeBSD firewall. The plugin uses RAW socket to communicate with kernel and collect 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. Theese metrics show FreeBSD firewall statistics. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | ipfw.mem | dynamic, static | bytes | | ipfw.packets | a dimension per static rule | packets/s | | ipfw.bytes | a dimension per static rule | bytes/s | | ipfw.active | a dimension per dynamic rule | rules | | ipfw.expired | a dimension per dynamic rule | rules | 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:ipfw]` 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 | |:-|:--|:-|:--:| | counters for static rules | Enable or disable counters for static rules metric. | yes | no | | number of dynamic rules | Enable or disable number of dynamic rules metric. | yes | no | | allocated memory | Enable or disable allocated memory metric. | yes | no | </details> There are no configuration examples.
Project: Grafana (Observability and Analysis / Observability)
File: preferences.md

aliases: ../../http_api/preferences/ canonical: /docs/grafana/latest/developers/http_api/preferences/ description: Grafana HTTP API keywords: grafana http documentation api preferences labels: products: enterprise oss title: 'HTTP Preferences API ' Keys: theme - One of: `light`, `dark`, or an empty string for the default theme homeDashboardId - The numerical `:id` of a favorited dashboard, default: `0` timezone - One of: `utc`, `browser`, or an empty string for the default Omitting a key will cause the current value to be replaced with the system default value. `GET /api/user/preferences` Example Request: ```http GET /api/user/preferences HTTP/1.1 Accept: application/json Content-Type: application/json Authorization: Bearer eyJrIjoiT0tTcG1pUlY2RnVKZTFVaDFsNFZXdE9ZWmNrMkZYbk ``` Example Response: ```http HTTP/1.1 200 Content-Type: application/json { "theme": "", "homeDashboardId": 217, "homeDashboardUID": "jcIIG-07z", "timezone": "utc", "weekStart": "", "navbar": { "savedItems": null }, "queryHistory": { "homeTab": "" } } ``` `PUT /api/user/preferences` Example Request: ```http PUT /api/user/preferences HTTP/1.1 Accept: application/json Content-Type: application/json Authorization: Bearer eyJrIjoiT0tTcG1pUlY2RnVKZTFVaDFsNFZXdE9ZWmNrMkZYbk { "theme": "", "homeDashboardUID":"home", "timezone":"utc" } ``` Example Response: ```http HTTP/1.1 200 Content-Type: text/plain; charset=utf-8 {"message":"Preferences updated"} ``` Update one or more preferences without modifying the others. `PATCH /api/user/preferences` Example Request: ```http PATCH /api/user/preferences HTTP/1.1 Accept: application/json Content-Type: application/json Authorization: Bearer eyJrIjoiT0tTcG1pUlY2RnVKZTFVaDFsNFZXdE9ZWmNrMkZYbk { "theme": "dark" } ``` Example Response: ```http HTTP/1.1 200 Content-Type: text/plain; charset=utf-8 {"message":"Preferences updated"} ``` `GET /api/org/preferences` Example Request: ```http GET /api/org/preferences HTTP/1.1 Accept: application/json Content-Type: application/json Authorization: Bearer eyJrIjoiT0tTcG1pUlY2RnVKZTFVaDFsNFZXdE9ZWmNrMkZYbk ``` Example Response: ```http HTTP/1.1 200 Content-Type: application/json { "theme": "", "homeDashboardId": 0, "timezone": "", "weekStart": "", "navbar": { "savedItems": null }, "queryHistory": { "homeTab": "" } } ``` `PUT /api/org/preferences` Example Request: ```http PUT /api/org/preferences HTTP/1.1 Accept: application/json Content-Type: application/json Authorization: Bearer eyJrIjoiT0tTcG1pUlY2RnVKZTFVaDFsNFZXdE9ZWmNrMkZYbk { "theme": "", "homeDashboardUID":"home", "timezone":"utc" } ``` Example Response: ```http HTTP/1.1 200 Content-Type: text/plain; charset=utf-8 {"message":"Preferences updated"} ``` Update one or more preferences without modifying the others. `PATCH /api/org/preferences` Example Request: ```http PATCH /api/org/preferences HTTP/1.1 Accept: application/json Content-Type: application/json Authorization: Bearer eyJrIjoiT0tTcG1pUlY2RnVKZTFVaDFsNFZXdE9ZWmNrMkZYbk { "theme": "dark" } ``` Example Response: ```http HTTP/1.1 200 Content-Type: text/plain; charset=utf-8 {"message":"Preferences updated"} ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16088.md

key | value | compatible | yes version | 2.3.0b1 date | 2023-09-27T16:54:11+00:00 level | 1 class | feature component | setup edition | cre For each category of crash dumps (base, check, ec, gui, rest_api, section), add the latest dump to the Support Diagnostics dump.