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

title: Troubleshooting description: A guide to debugging and troubleshooting Vector author_github: binarylogic domain: operations weight: 4 tags: ["troubleshooting", "level up", "guides", "guide"] This guide covers troubleshooting Vector. The sections are intended to be followed in order. If you'd like to troubleshoot by inspecting events flowing through your pipeline, please check out the [Vector tap] guide. First, we're sorry to hear that you're having trouble with Vector! Reliability and operator friendliness are very important to us, and we urge you to to let us know what's going on. This helps us improve Vector. Start by searching . You can filter to the specific component via the `label` filter. We've taken great care to ensure that Vector's logs are high quality and helpful. In most cases the logs will surface the issue: {{< tabs default="Manual" >}} {{< tab title="Manual" >}} If you aren't using a service manager and you're redirecting Vector's output to a file, you can use a utility like `tail` to access your logs: ```shell tail /var/log/vector.log ``` {{< /tab >}} {{< tab title="Systemd" >}} Tail logs: ```shell sudo journalctl -fu vector ``` {{< /tab >}} {{< tab title="Initd" >}} Tail logs: ```shell tail -f /var/log/vector.log ``` {{< /tab >}} {{< tab title="Homebrew" >}} Tail logs: ```shell tail -f /usr/local/var/log/vector.log ``` {{< /tab >}} {{< /tabs >}} {{< info >}} You can skip to the if you don't have an exception in your logs. {{< /info >}} If you see an exception in Vector's logs then we've clearly found the issue. Before you report a bug, please enable backtraces: ```bash RUST_BACKTRACE=full vector --config=/etc/vector/vector.yaml ``` Backtraces are critical for debugging errors. Once you have the backtrace please . If you don't see an error in your Vector logs and the Vector logs appear to be frozen, then you'll want to drop your log level to `debug`: {{< info >}} Vector rate limits logs in the hot path. As a result, dropping to the `debug` level is safe for production environments. {{< /info >}} {{< tabs default="Env Var" >}} {{< tab title="Env Var" >}} ```shell VECTOR_LOG=debug vector --config=/etc/vector/vector.yaml ``` {{< /tab >}} {{< tab title="Flag" >}} ```bash vector --verbose --config=/etc/vector/vector.yaml ``` {{< /tab >}} {{< /tabs >}} At this point, we recommend reaching out to the community for help. If you've encountered a bug, please If you've identified a missing feature, please . If you need help, . You can post a question and search previous questions.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_cluster.LabelSelector.md

title: "Interface: LabelSelector" linkTitle: "LabelSelector" slug: "libk8scluster.LabelSelector" .LabelSelector `Optional` matchExpressions: { `key`: `string` ; `operator`: `string` ; `values`: `string`[] }[] _ `Optional` matchLabels: `Object`
Project: Netdata (Observability and Analysis / Observability)
File: ipmi_events.md

This alert is triggered when there are events recorded in the IPMI System Event Log (SEL). These events can range from critical, warning, and informational events. The alert enters a warning state when the number of events in the IPMI SEL exceeds 0, meaning there are recorded events that may require your attention. The Intelligent Platform Management Interface (IPMI) System Event Log (SEL) is a log that records events related to hardware components and firmware on a server. These events can provide insight into potential issues with the server's hardware or firmware, which could impact the server's overall performance or stability. Use `ipmitool` to view the IPMI SEL events: You can view the System Event Log using the `ipmitool` command. If you don't have `ipmitool` installed, you might need to install it first. Once `ipmitool` is installed, use the following command to list the SEL events: ``` ipmitool sel list ``` This command will display the recorded events with their respective timestamp, event ID, and a brief description. Identify and resolve issues: Analyze the events listed to identify any critical or warning events that may require immediate attention. You may need to refer to your server's hardware documentation or firmware updates to resolve the issue. Clear the IPMI SEL events (optional): If you have resolved the issues or if the events listed are no longer relevant, you can clear the IPMI SEL events using the following command: ``` ipmitool sel clear ``` Note: Clearing the SEL events may cause you to lose important historical information related to your hardware components and firmware. Be cautious when using this command, and ensure that you have resolved any critical issues before clearing the event log.
Project: M3 (Observability and Analysis / Observability)
File: m3coordinator.md

title: "M3 Coordinator" weight: 3 M3 Coordinator is a service that coordinates reads and writes between upstream systems, such as Prometheus, and downstream systems, such as M3DB. It also provides management APIs to setup and configure different parts of M3. The coordinator is generally a bridge for read and writing different types of metrics formats and a management layer for M3. Note: M3DB by default includes the M3 Coordinator accessible on port 7201. For production deployments it is recommended to deploy it as a dedicated service to ensure you can scale the write coordination role separately and independently to database nodes as an isolated application separate from the M3DB database role.
Project: Netdata (Observability and Analysis / Observability)
File: linux_power_supply_capacity.md

The `linuxpowersupply_capacity` alert is triggered when the remaining power supply capacity of a Linux system is low. A warning state occurs when the capacity falls below 10%, and a critical state occurs when it falls below 5%. This alert indicates that the system may run out of power and shut down soon. Restore power: Connect the system to a power source to recharge the battery and prevent an unexpected shutdown. Check battery health: Inspect the health of the system's battery. If the capacity is consistently low or degrading, consider replacing the battery. Consider a UPS: If your system experiences frequent power interruptions, you may want to integrate an uninterruptible power supply (UPS) to provide temporary power and prevent system shutdowns. Monitor power supply metrics: Keep an eye on power supply metrics, such as remaining capacity and charge/discharge rate, to ensure the system is functioning optimally.
Project: Netdata (Observability and Analysis / Observability)
File: unbound_request_list_overwritten.md

The `unboundrequestlist_overwritten` alert is triggered when Unbound, a popular DNS resolver, overwrites old queued requests because its request queue is full. This alert can indicate a Denial of Service (DoS) attack or network saturation. When the request queue is full, Unbound starts overwriting the oldest requests in the queue with newer incoming requests. This is done to handle increasing load, but it may also lead to dropped or lost queries. Check the Unbound log file for any unusual events or error messages. The default log file location is `/var/log/unbound.log`. You may find more information about the cause of the request queue overload, such as a high number of incoming queries or sudden spikes in traffic. Monitor Unbound's real-time statistics using the `unbound-control` command, which allows you to view various metrics related to the performance of the Unbound server: ``` sudo unbound-control stats_noreset ``` Look for the `num.query.list` and `num.query.list.overwritten` values to determine how many queries are in the request queue and how many of them are being overwritten. Analyze the incoming DNS queries to check for suspicious patterns, such as high query rates from specific clients or repeated queries for the same domain. You can use tools like `tcpdump` to capture and inspect DNS traffic: ``` sudo tcpdump -i any -nn -s0 -w dns_traffic.pcap 'port 53' ``` You can then analyze the captured data using packet analyzers like Wireshark or tshark. Increase the request queue length by adjusting the `num-queries-per-thread` value in the Unbound configuration file (`/etc/unbound/unbound.conf`), which determines the maximum number of queries that can be queued per thread before overwriting begins. Increasing this value may help to accommodate higher incoming query loads: ``` server: num-queries-per-thread: 4096 ``` Remember to restart the Unbound service for the changes to take effect (`sudo systemctl restart unbound`). Consider implementing rate limiting to prevent a single client from overloading the server. Unbound supports rate limiting using the `ratelimit` configuration option: ``` server: ratelimit: 1000 ``` This example sets a limit of 1000 queries per second, but you should tune it according to your environment.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: view-exemplar-data.md

aliases: ../../operators-guide/use-exemplars/viewing-exemplar-data/ ../../operators-guide/using-exemplars/viewing-exemplar-data/ ../../operators-guide/use-exemplars/view-exemplar-data/ description: Learn how to view exemplar data in Grafana Mimir. menuTitle: View exemplar data title: View exemplar data in Grafana Explore weight: 40 Grafana Explore visualizes exemplar traces as highlighted points alongside metrics data. For more information, see topic in Grafana OSS documentation.
Project: Micrometer (Observability and Analysis / Observability)
File: bug_report.md

name: Bug report about: Report a bug in Micrometer title: '' labels: 'waiting-for-triage' assignees: '' Describe the bug A clear and concise description of what the bug is. Environment <!-- In what environment did the bug happen? --> <!-- If you are not using the latest patch version of a supported Micrometer line, please upgrade to see if the issue happens on the latest patch version for that line (e.g. 1.6.x). See https://micrometer.io/support/ --> Micrometer version [e.g. 1.7.1] Micrometer registry [e.g. prometheus] OS: [e.g. macOS] Java version: [e.g. output of `java -version`] To Reproduce How to reproduce the bug: <!-- If possible, please provide a test case or minimal sample application that reproduces the problem. This makes it much easier for us to diagnose the problem and to verify that we have fixed it. --> Expected behavior A clear and concise description of what you expected to happen. Additional context Add any other context about the problem here, e.g. related issues.
Project: Kepler (Observability and Analysis / Observability)
File: RELEASE.md

The `yaml` Project is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
Project: Elastic (Observability and Analysis / Observability)
File: mv_zip.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Combines the values from two multivalued fields with a delimiter that joins them together. ``` ROW a = ["x", "y", "z"], b = ["1", "2"] | EVAL c = mv_zip(a, b, "-") | KEEP a, b, c ```
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_cluster.KubeContainerStatus.md

title: "Interface: KubeContainerStatus" linkTitle: "KubeContainerStatus" slug: "libk8scluster.KubeContainerStatus" .KubeContainerStatus `Optional` containerID: `string` _ image: `string` _ imageID: `string` _ lastState: `Partial`<\> _ name: `string` _ ready: `boolean` _ restartCount: `number` _ `Optional` started: `boolean` _ state: `Partial`<\>
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-admin_delete_user.md

category: Admin apiurl: '/api/v1/admin/delete_user' title: 'Delete User' type: 'DELETE' sample_doc: 'admin.html' layout: default Required `Admin` usage ```{"user_id": 31}``` ```Status: 200``` ```{"message":"user 31 has been delete, affect row: 1"}```
Project: Grafana (Observability and Analysis / Observability)
File: frontend-data-requests.md

handles all outgoing HTTP requests from Grafana. This document explains the high-level concepts used by `BackendSrv`. This section describes how canceling requests work in Grafana. While data sources can implement their own cancellation concept, we recommend that you use the method we describe here. A data request can take a long time to finish. During the time between when a request starts and finishes, the user can change context. For example, the user may navigate away or issue the same request again. If we wait for canceled requests to complete, it might create unnecessary load on data sources. Grafana uses a concept called request cancellation to cancel any ongoing request that Grafana doesn't need. Before Grafana can cancel any data request, it has to identify that request. Grafana identifies a request using the property `requestId` when you use . The cancellation logic is as follows: When an ongoing request discovers that an additional request with the same `requestId` has started, then Grafana will cancel the ongoing request. When an ongoing request discovers that the special "cancel all requests" `requestId` was sent, then Grafana will cancel the ongoing request. Grafana 7.2 introduced an additional way of canceling requests using . To support the new cancellation functionality, the data source needs to use the new `fetch` function in . Migrating the core data sources to the new `fetch` function If Grafana isn't configured to support HTTP/2, browsers connecting with HTTP 1.1 enforce a limit of 4 - 8 parallel requests (the specific limit varies). Because of this limit, if some requests take a long time, they will block later requests and make interacting with Grafana very slow. allows far more parallel requests. Not supported. Grafana uses a request queue to process all incoming data requests in order while reserving a free "spot" for any requests to the Grafana API. Since the first implementation of the request queue doesn't take into account what browser the user uses, the request queue limit for parallel data source requests is hard-coded to 5. Note: Grafana instances will have a hard coded limit of 1000.
Project: Teletrace (Observability and Analysis / Observability)
File: demo.md

This demo provides an overview of how to use OpenTelemetry in a sample application to trace and monitor distributed systems via Teletrace. forked from repository and contains the OpenTelemetry Astronomy Shop, a microservice-based distributed system intended to illustrate the implementation of OpenTelemetry in a near real-world environment. Before using the Teletrace OpenTelemetry Demo, ensure that you have the following prerequisites: Git Docker Docker Compose 4 GB of RAM for the application <!-- prettier-ignore-start --> Follow the steps below to get started with the Teletrace OpenTelemetry Demo: Clone the Teletrace OpenTelemetry Demo repository: ```sh git clone https://github.com/teletrace/opentelemetry-demo.git ``` Navigate to opentelemetry demo folder ```sh cd opentelemetry-demo ``` Run docker compose ```sh docker compose up --no-build ``` View traces and metrics: The OpenTelemetry Demo includes a set of observability tools, such as Teletrace, and Grafana, to visualize and analyze the traces and metrics generated by your application. Teletrace: <http://localhost:18080/> Grafana: <http://localhost:8080/grafana/> Explore OpenTelemetry features: The OpenTelemetry Demo provides examples of different OpenTelemetry features, such as distributed tracing, context propagation, custom instrumentation. Explore the demo code and the OpenTelemetry documentation to learn more about these features and how to use them in your application. <!-- prettier-ignore-end --> Happy tracing and monitoring!
Project: Checkmk (Observability and Analysis / Observability)
File: 16649.md

key | value | date | 2024-04-03T05:33:49+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes When running the nagios core the `libexec` folder for active checks has not been conisdered when creating the core configuration.
Project: Graylog (Observability and Analysis / Observability)
File: Spacings.md

All spacing options are available via the ThemeProvider `theme.spacings` prop ```jsx noeditor import React, { useEffect } from 'react'; import styled, { useTheme } from 'styled-components'; const { spacings } = useTheme(); const SpacingExample = () => ( <> {Object.keys(spacings).map((space) => space !== 'px' && ( <div key={space} style={{display:'flex',alignItems: 'center', marginBottom: 12}}> <div key={space} style={{height: spacings[space], width:spacings[space], backgroundColor: '#eee'}} /> <span style={{paddingLeft: 12}}>spacings.{space} ({spacings[space]} / {spacings.px[space] || space}px)</span> </div> ))} </> ); <SpacingExample /> ```
Project: Grafana Tempo (Observability and Analysis / Observability)
File: polling.md

title: Use polling to monitor the backend status menuTitle: Use polling to monitor backend status description: Monitor backend status for Tempo using polling. weight: 30 aliases: /docs/tempo/operations/polling ../polling Tempo maintains knowledge of the state of the backend by polling it on regular intervals. There are currently only two components that need this knowledge and, consequently, only two that poll the backend: compactors and queriers. To reduce calls to the backend, only a small subset of compactors actually list all blocks and build what's called a tenant index. The tenant index is a gzip'ed JSON file located at `/<tenant>/index.json.gz` containing an entry for every block and compacted block for that tenant. This is done once every `blocklist_poll` duration. All other compactors and all queriers then rely on downloading this file, unzipping it and using the contained list. Again, this is done once every `blocklist_poll` duration. Due to this behavior, a given compactor or querier often have an out-of-date blocklist. During normal operation, it will stale by at most twice the configured `blocklist_poll`. {{< admonition type="note" >}} For details about configuring polling, refer to . {{% /admonition %}} Refer to the Jsonnet for example and related to polling. If you are building your own dashboards or alerts, here are a few relevant metrics: `tempodbblocklistpollerrorstotal` A holistic metric that increments for any error with polling the blocklist. Any increase in this metric should be reviewed. `tempodbblocklistpolldurationseconds` Histogram recording the length of time in seconds to poll the entire blocklist. `tempodbblocklistlength` Total blocks as seen by this component. `tempodbblocklisttenantindexerrors_total` A holistic metrics that indcrements for any error building the tenant index. Any increase in this metric should be reviewed. `tempodbblocklisttenantindexbuilder` A gauge that has the value 1 if this compactor is attempting to build the tenant index and 0 if it is not. At least one compactor must have this value set to 1 for the system to be working. `tempodbblocklisttenantindexage_seconds` The age of the last loaded tenant index. now() minus this value indicates how stale this components view of the blocklist is.
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: MAINTAINERS.md

The following are the main/default maintainers: Anton Kolesnikov () Christian Simon () Cyril Tovena () Dmitry Filimonov - () Ryan Perry - () Some parts of the codebase have other maintainers, the package paths also include all sub-packages: `docs`: Eve Meelan - () `ebpf`: Tolya Korniltsev - ()
Project: Netdata (Observability and Analysis / Observability)
File: alerts.md

[% if entry.alerts %] The following alerts are available: | Alert name | On metric | Description | |:|:-|:| [% for alert in entry.alerts %] | ]]) | [[ strfy(alert.metric) ]] | [[ strfy(alert.info) ]] | [% endfor %] [% else %] There are no alerts configured by default for this integration. [% endif %]
Project: Checkmk (Observability and Analysis / Observability)
File: 16589.md

key | value | date | 2024-03-06T16:44:06+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes You can now monitor Redfish compatible management boards / BMCs with Checkmk. To do so, please enable the natively shipped MKP redfish in Setup --> Extension packages (in commercial editions of Checkmk) or via the command line tool `mkp` (in Checkmk Raw). This will enable a new datasource program under Setup --> Other integrations --> Redfish Compatible Management Controller. This is an experimental integration created by the Checkmk community (Andreas Dhler from Bechtle), which has already been tested in many environments. However, due to the diverse nature of server hardware, we plan to integrate it entirely for Checkmk 2.4.0, once we have gathered further feedback.
Project: Checkmk (Observability and Analysis / Observability)
File: 16618.md

key | value | date | 2024-04-04T14:24:50+00:00 version | 2.4.0b1 class | security edition | cre component | wato level | 1 compatible | yes Prior to this Werk a service name with html tags lead to cross site scripting in the graph rendering. We found this vulnerability internally. Affected Versions: Only 2.3.0 is affected, older versions are NOT affected. Vulnerability Management: We have rated the issue with a CVSS Score of 4.6 (Medium) with the following CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N`. We assigned CVE-2024-2380 to this vulnerability. Changes: This Werk changes the encoding engine to use our customized JSON encoder.
Project: SkyWalking (Observability and Analysis / Observability)
File: New-ElasticSearch-storage-option-explanation-in-9.2.0.md

Since v9.2.0, SkyWalking OAP provides 2 storage options for all data, including metadata, metrics, traces, logs, events, profiling data, etc.. OAP exposes a system environment variable (`SWSTORAGEESLOGICSHARDING`) to control the running mode. This is the new mode introduced in 9.2.0. It prefers to keep data with similar properties in one index template, such as all metrics and metadata. OAP merges all metrics/meter and records(without super datasets, such as segments) indices into one physical index template `metrics-all` and `records-all`. The logic index name would be present in columns `metrictable` or `recordtable`. If the logic column name has an alias (configured through `@ElasticSearch.Column()`), the alias would be the real physical column name. The super dataset would not be affected by this, such as traces and logs. OAP shard metrics/meter indices into multi-physical indices as in the previous versions(one index template per metric/meter aggregation function). Records and metrics without configuring aggregation functions with `@MetricsFunction` or `@MeterFunction` annotation would not be merged. They would be kept in a separate index template. The shard template name would be `metrics-aggregation function name` or `meter-aggregation function name` such as `metrics-count`, and the logic index name would be present in column `metric_table`. The OAP would not use the column alias, the logic column name would be the real physical column name. _ Notice: Users still could choose to adjust ElasticSearch's shard number(`SWSTORAGEESINDEXSHARDS_NUMBER`) to scale out in either mode.