cwielenb/CNCF-Dataset huggingface dataset:
Project: Grafana Tempo (Observability and Analysis / Observability)
File: docker-example.md

title: Quick start for Tempo menuTitle: Quick start for Tempo description: Use Docker to quickly view traces using K-6 and Tempo weight: 600 The Tempo repository provides to help you quickly get started using Tempo and distributed tracing data. Every example has a `docker-compose.yaml` manifest that includes all of the options needed to explore trace data in Grafana, including resource configuration and trace data generation. The Tempo examples running with Docker using docker-compose include a version of Tempo and a storage configuration suitable for testing or development. This quick start guide uses the `local` example running Tempo as a single binary (monolithic). Any data is stored locally in the `tempo-data` folder. To learn more, read the . If you would like to use a demo with Tempo, Mimir, Loki, and Grafana, then try the . `Intro-to-mltp` provides a self-contained environment for learning about Mimir, Loki, Tempo, and Grafana. The project includes detailed explanations of each component and annotated configurations for a single-instance deployment. Data from `intro-to-mltp` can also be pushed to Grafana Cloud. To follow this guide, you need: Git Docker The docker-compose plugin Clone the Tempo repository: ```bash git clone https://github.com/grafana/tempo.git ``` Go into the examples directory: ```bash cd tempo/example/docker-compose/local ``` Start the services defined in the docker-compose file: ```bash docker compose up -d ``` Verify that the services are running using `docker compose ps`. You should see something like: ```console docker compose ps NAME COMMAND SERVICE STATUS PORTS local-grafana-1 "/run.sh" grafana running 0.0.0.0:3000->3000/tcp local-k6-tracing-1 "/k6-tracing run /ex" k6-tracing running local-prometheus-1 "/bin/prometheus --c" prometheus running 0.0.0.0:9090->9090/tcp local-tempo-1 "/tempo -config.file" tempo running 0.0.0.0:3200->3200/tcp, 0.0.0.0:4317-4318->4317-4318/tcp, 0.0.0.0:9411->9411/tcp, 0.0.0.0:14268->14268/tcp ``` As part of the docker compose manifest, Grafana is now accessible on port 3000. Open a browser to localhost:3000 and sign in to Grafana. Once logged in, navigate to the Explore page, select the Tempo data source and select the Search tab. Select Run query to list the recent traces stored in Tempo. Select one to view the trace diagram: <p align="center"><img src="../../setup/assets/setup-linux-run-query.png" alt="Query example"></p> A couple of minutes after Tempo has started up successfully, select the Service graph tab for the Tempo data source in the Explore page. Select Run query to view a service graph, generated by Tempos metrics-generator. <p align="center"><img src="../../setup/assets/setup-linux-node-graph.png" alt="Service graph sample"></p> To stop the services: ``` docker compose down -v ```
Project: DeepFlow (Observability and Analysis / Observability)
File: build.md

Here is the documentation about how to compile agent in Linux system The easiest way is to use our docker image: ```bash git clone --recursive https://github.com/deepflowio/deepflow.git cd deepflow docker run --privileged --rm -it -v \ $(pwd):/deepflow hub.deepflow.yunshan.net/public/rust-build bash -c \ "cd /deepflow/agent && cargo build" ``` Agent compilation requires the following environments: Clang/LLVM: 11/12 rust: 1.61+ Install basic tools: ubuntu, debian, kali, etc. ```bash apt-get install -y clang-11 gcc llvm-11 llvm-11-dev libpcap0.8-dev libelf-dev make ``` fedora ```bash yum install llvm11 gcc libpcap-devel glibc-static elfutils-libelf-devel make yum --releasever=33 install clang # install clang11 ``` Create soft link: ```bash ln -s /usr/bin/clang-11 /usr/bin/clang ln -s /usr/bin/llvm-objdump-11 /usr/bin/llvm-objdump ln -s /usr/bin/llc-11 /usr/bin/llc ln -s /usr/bin/llvm-strip-11 /usr/bin/llvm-strip ``` Compile static libraries: ```bash wget https://github.com/iovisor/bcc/releases/download/v0.25.0/bcc-src-with-submodule.tar.gz tar -xzf bcc-src-with-submodule.tar.gz cd bcc && cmake3 . && make && make install git clone https://github.com/bitdefender/bddisasm cd bddisasm make && make install && make clean ln -s /usr/local/lib/libbddisasm.a /usr/lib/libbddisasm.a wget https://www.zlib.net/fossils/zlib-1.2.12.tar.gz tar -xzf zlib-1.2.12.tar.gz cd zlib-1.2.12 ./configure make && make install && make clean ln -s /usr/local/lib/libz.a /usr/lib/libz.a wget https://github.com/davea42/libdwarf-code/releases/download/v0.4.1/libdwarf-0.4.1.tar.xz tar -xf libdwarf-0.4.1.tar.xz cd libdwarf-0.4.1 CFLAGS="-fpic" ./configure --disable-dependency-tracking make && make install && make clean ln -s /usr/local/lib/libdwarf.a /usr/lib/libdwarf.a wget https://sourceware.org/elfutils/ftp/0.187/elfutils-0.187.tar.bz2 tar -xf elfutils-0.187.tar.bz2 cd elfutils-0.187 ./configure make && make install && make clean ln -s /usr/local/lib/libelf.a /usr/lib/libelf.a wget https://github.com/deepflowio/libGoReSym/archive/refs/tags/v0.0.1-2.tar.gz tar -xzf v0.0.1-2.tar.gz cd libGoReSym-0.0.1-2 make && make install && make clean ``` Compile agent ```bash git clone --recursive https://github.com/deepflowio/deepflow.git cd deepflow/agent cargo build ```
Project: Vector (Observability and Analysis / Observability)
File: archlinux.md

title: Install Vector on Arch Linux short: Arch Linux supported_installers: ["pacman", "Vector installer", "Docker", "Helm"] weight: 2 [Arch Linux] is a lightweight and flexible Linux distribution that tries to Keep It Simple. This page covers installing and managing Vector on the Arch Linux operating system. {{< supported-installers >}}
Project: SkyWalking (Observability and Analysis / Observability)
File: advanced-deployment.md

OAP servers communicate with each other in a cluster environment to do distributed aggregation. In the cluster mode, all OAP nodes are running in Mixed mode by default. The available roles for OAP are, Mixed(default) Receiver Aggregator Sometimes users may wish to deploy cluster nodes with a clearly defined role. They could then use this function. By default, the OAP is responsible for: Receiving agent traces or metrics. L1 aggregation Internal communication (sending/receiving) L2 aggregation Persistence Alarm The OAP is responsible for: Receiving agent traces or metrics. L1 aggregation Internal communication (sending) The OAP is responsible for: Internal communication(receiving from Receiver and Mixed roles OAP) L2 aggregation Persistence Alarm _ These roles are designed for complex deployment requirements on security and network policy. If you are using our native , and you insist to install OAP nodes with a clearly defined role. There should be two deployments for each role, one for receiver OAPs and the other for aggregator OAPs to separate different system environment settings. Then, the `labelSelector` should be set for `Aggregator` role selection rules to choose the right OAP deployment based on your needs.
Project: Vector (Observability and Analysis / Observability)
File: 2020-06-10-consolidate-and-beautify-validate.md

date: "2020-07-13" title: "Beautification of the validate command" description: "A little polish on a useful feature." authors: ["hoverbear"] hideonrelease_notes: false pr_numbers: [2622] release: "0.10.0" badges: type: "enhancement" domains: ["ux"] We gave `vector validate` some touching up to make it look better, and feel nicer to use. This was heavily inspired by the fantastic `linkerd validate` command. Take a gander at the new output on a good valid configuration: ```bash vic@sticky-keyboard-macbook:/git/vectordotdev/vector$ vector validate test.toml Loaded "test.toml" Configuration topology Component configuration Health check `sink0` Validated ``` Now an invalid configuration: ```bash vic@sticky-keyboard-macbook:/git/vectordotdev/vector$ vector validate test.toml Failed to parse "test.toml" x missing field `type` for key `sinks.sink1` ```
Project: Netdata (Observability and Analysis / Observability)
File: PULL_REQUEST_TEMPLATE.md

<!-- Describe the change in summary section, including rationale and design decisions. Include "Fixes #nnn" if you are fixing an existing issue. --> <!-- Provide enough detail so that your reviewer can understand which test cases you have covered, and recreate them if necessary. If our CI covers sufficient tests, then state which tests cover the change. --> <!-- This is usually used to help others understand your motivation behind this change. A step-by-step reproduction of the problem is helpful if there is no related issue. --> <details> <summary>For users: How does this change affect me?</summary> <!-- Describe the PR affects users: Which area of Netdata is affected by the change? Can they see the change or is it an under the hood? If they can see it, where? How is the user impacted by the change? What are there any benefits of the change? --> </details>
Project: Netdata (Observability and Analysis / Observability)
File: postgres_total_connection_utilization.md

This alert monitors the total `connection utilization` of a PostgreSQL database. If you receive this alert, it means that your `PostgreSQL` database is experiencing a high demand for connections. This can lead to performance degradation and, in extreme cases, could potentially prevent new connections from being established. `Connection utilization` refers to the percentage of `database connections` currently in use compared to the maximum number of connections allowed by the PostgreSQL server. A high connection utilization implies that the server is handling a large number of concurrent connections, and its resources may be strained, leading to decreased performance. Check the current connections to the PostgreSQL database: You can use the following SQL query to check the number of active connections for each database: ``` SELECT datname, count(*) FROM pgstatactivity GROUP BY datname; ``` or use the following command to check the total connections to all databases: ``` SELECT count(*) FROM pgstatactivity; ``` Identify the source of increased connections: To find out which user or application is responsible for the high connection count, you can use the following SQL query: ``` SELECT usename, applicationname, count(*) FROM pgstatactivity GROUP BY usename, applicationname; ``` This query shows the number of connections per user and application, which can help you identify the source of the increased connection demand. Optimize connection pooling: If you are using an application server, such as `pgBouncer`, that supports connection pooling, consider adjusting the connection pool settings to better manage the available connections. This can help mitigate high connection utilization. Increase the maximum connections limit: If your server has the necessary resources, you may consider increasing the maximum number of connections allowed by the PostgreSQL server. To do this, modify the `max_connections` configuration parameter in the `postgresql.conf` file and then restart the PostgreSQL service.
Project: Checkmk (Observability and Analysis / Observability)
File: 16381.md

key | value | date | 2024-03-11T13:39:19+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes The plugin previously only considered the status to be OK if the device reported a literal "available,syncd". It now is OK for any combination of (some of) the words "available", "syncd", "snapshot" and "space_efficient".
Project: LinDB (Observability and Analysis / Observability)
File: bug-report.md

name: "\U0001F41B Bug report" about: I want to report a Bug. title: '[bug]:' labels: bug assignees: '' Describe the bug A clear and concise description of what the bug is. To Reproduce (Required) Steps to reproduce the behavior: Expected behavior (Required) A clear and concise description of what you expected to happen. What's your LinDB version? (Required) Insert output of `lind version` here. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here.
Project: Netdata (Observability and Analysis / Observability)
File: sync_freq.md

This alert is triggered when the number of `sync()` system calls is greater than 6. The `sync()` system call writes any data buffered in memory out to disk, including modified superblocks, modified inodes, and delayed reads and writes. A higher number of `sync()` calls indicates that the system is often trying to flush buffered data to disk, which can cause performance issues. Identify the process causing sync events Use `bpftrace` to identify which processes are causing the sync events. Make sure you have `bpftrace` installed on your system; if not, follow the instructions here: Run the `syncsnoop.bt` script from the `bpftrace` tools: ``` sudo bpftrace /path/to/syncsnoop.bt ``` This script will trace sync events and display the process ID (PID), process name, and the stack trace. Analyze the output Focus on processes with a high number of sync events, and investigate whether you can optimize these processes or reduce their impact on the system. Check if these processes are essential to system functionality. Look for potential bugs or misconfigurations that may trigger undue `sync()` calls. Consider modifying the process itself to reduce disk I/O or change how it handles write operations. Monitor your system's I/O performance Keep an eye on overall I/O performance using tools like `iostat`, `iotop`, or `vmstat`. For example, you can use `iostat` to monitor disk I/O: ``` iostat -xz 1 ``` This command displays extended disk I/O statistics with a 1-second sampling interval. Check for high `await` values, which indicate the average time taken for I/O requests to be completed. Look for high `%util` values, representing the percentage of time the device was busy servicing requests.
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: filetop.md

title: Gadget filetop filetop shows reads and writes by file, with container details. The following parameters are supported: interval: Output interval, in seconds. (default 1) max_rows: Maximum rows to print. (default 20) sort_by: The field to sort the results by (runtime.runtimeName,runtime.containerId,runtime.containerName,runtime.containerImageName,runtime.containerImageDigest,k8s.node,k8s.namespace,k8s.pod,k8s.labels,k8s.container,k8s.hostnetwork,mntns,pid,tid,comm,reads,writes,rbytes,wbytes,T,file). (default -reads,-writes,-rbytes,-wbytes) all-files: Show all files. (default false, i.e. show regular files only) ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: filetop namespace: gadget spec: node: ubuntu-hirsute gadget: filetop runMode: Manual outputMode: Stream filter: namespace: default ``` Start filetop gadget ```bash $ kubectl annotate -n gadget trace/filetop \ gadget.kinvolk.io/operation=start ``` Stop filetop gadget ```bash $ kubectl annotate -n gadget trace/filetop \ gadget.kinvolk.io/operation=stop ``` Stream
Project: Loggie (Observability and Analysis / Observability)
File: CHANGESv2.md

A number of changes were made to Tcell for version two, and some of these are breaking. The import path for tcell has changed to `github.com/gdamore/tcell/v2` to reflect a new major version. The type `Style` has changed to a structure, to allow us to add additional data such as flags for color setting, more attribute bits, and so forth. Applications that relied on this being a number will need to be updated to use the accessor methods. The middle mouse button was reported as button 2 on Linux, but as button 3 on Windows, and the right mouse button was reported the reverse way. Tcell now always reports the right mouse button as button 2, and the middle button as button 3. To help make this clearer, new symbols `ButtonPrimary`, `ButtonSecondary`, and `ButtonMiddle` are provided. (Note that which button is right vs. left may be impacted by user preferences. Usually the left button will be considered the Primary, and the right will be the Secondary.) Applications may need to adjust their handling of mouse buttons 2 and 3 accordingly. A number of terminals have been removed. These are mostly ancient definitions unlikely to be used by anyone, such as `adm3a`. Historically terminfo reported function keys with modifiers set as a different function key altogether. For example, Shift-F1 was reported as F13 on XTerm. Tcell now prefers to report these using the base key (such as F1) with modifiers added. This works on XTerm and VTE based emulators, but some emulators may not support this. The new behavior more closely aligns with behavior on Windows platforms. These features are not breaking, but are introduced in version 2. For terminals that appear to behave like the venerable XTerm, tcell automatically adds modifier reporting for ALT, CTRL, SHIFT, and META keys when the terminal reports them. When using a color by its name or palette entry, Tcell now tries to use that palette entry as is; this should avoid some inconsistency and respect terminal themes correctly. When true fidelity to RGB values is needed, the new `TrueColor()` API can be used to create a direct color, which bypasses the palette altogether. For some terminals, if the `Tc` or `RGB` properties are present in terminfo, Tcell will automatically assume the terminal supports 24-bit color. A new color value, `ColorReset` can be used on the foreground or background to reset the color the default used by the terminal. Tcell now has improved support for tmux, when the `$TERM` variable is set to "tmux". Tcell has support for strikethrough when the terminal supports it, using the new `StrikeThrough()` API. Tcell provides the long requested capability to discriminate paste event by using the bracketed-paste capability present in some terminals. This is automatically available on terminals that support XTerm style mouse handling, but applications must opt-in to this by using the new `EnablePaste()` function. A new `EventPaste` type of event will be delivered when starting and finishing a paste operation.
Project: Netdata (Observability and Analysis / Observability)
File: beanstalk_server_buried_jobs.md

This alert is related to the `Beanstalk` message queue system and is triggered when there are buried jobs in the queue across all tubes. A buried job is one that has encountered an issue during processing by the consumer, so it remains in the queue waiting for manual action. This alert is raised in a warning state if there are more than 0 buried jobs and in a critical state if there are more than 10. Buried jobs are tasks that have faced an error or issue during processing by the consumer, and as a result, have been `buried`. This means these jobs remain in the queue, awaiting manual intervention for them to be processed again. The presence of buried jobs does not affect the processing of new jobs in the queue. Identify the buried jobs: Use the `beanstalk-tool` to inspect the Beanstalk server and list the buried jobs in the tubes. If you don't have `beanstalk-tool`, install it using pip: ``` pip install beanstalkc beanstalk-tool <beanstalk server host>:<beanstalk server port> statstube <tubename> ``` Examine the buried jobs: To investigate the cause of the buried jobs, find related logs, either from the Beanstalk server or from the consumer application. Analyzing the logs can lead to the root cause of the problem. Fix the issue: Once you identify the cause, resolve the issue in either the consumer application, or if necessary, in the Beanstalk server configuration. Kick the buried jobs: After resolving the issue, you need to manually kick the buried jobs back into the queue for processing. Use the following command with `beanstalk-tool`: ``` beanstalk-tool <beanstalk server host>:<beanstalk server port> kick <numberofjobstokick> --tube=<tube_name> ``` Monitor the queue: After kicking the buried jobs, monitor the queue and ensure that the jobs are processed without encountering more errors.
Project: Kubecost (Observability and Analysis / Continuous Optimization)
File: README.md

<https://www.opencost.io/docs/>.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0) ](https://www.bestpractices.dev/projects/6219) <img src="./opencost-header.png"/> OpenCost give teams visibility into current and historical Kubernetes and cloud spend and resource allocation. These models provide cost transparency in Kubernetes environments that support multiple applications, teams, departments, etc. It also provides visibility into the cloud costs across multiple providers. OpenCost was originally developed and open sourced by . This project combines a as well as a Golang implementation of these detailed requirements. The web UI is available in the repository. ](https://youtu.be/lCP4Ci9Kcdg) OpenCost UI Walkthrough To see the full functionality of OpenCost you can view . Here is a summary of features enabled: Real-time cost allocation by Kubernetes cluster, node, namespace, controller kind, controller, service, or pod Multi-cloud cost monitoring for all cloud services on AWS, Azure, GCP Dynamic on-demand k8s asset pricing enabled by integrations with AWS, Azure, and GCP billing APIs Supports on-prem k8s clusters with custom CSV pricing Allocation for in-cluster K8s resources like CPU, GPU, memory, and persistent volumes Easily export pricing data to Prometheus with /metrics endpoint () Carbon costs for cloud resources Support for external costs like Datadog through Free and open source distribution () You can deploy OpenCost on any Kubernetes 1.20+ cluster in a matter of minutes, if not seconds! Visit the full documentation for . We :heart: pull requests! See for information on building the project from source and contributing changes. If you need any support or have any questions on contributing to the project, you can reach us on in the channel or attend the biweekly from the to discuss OpenCost development. You can view for a list of commonly asked questions.
Project: Elastic APM (Observability and Analysis / Observability)
File: ARCHITECTURE.md

This document gives a high level overview over the architecture of the main APM Server components. The main purpose of the APM Server is to ingest data. It validates, enriches and transforms data, received from a variety of APM agents, into a dedicated format and passes them on to an output, such as Elasticsearch. High level overview over incoming data and their flow through the APM Server until being passed on to the output publisher pipeline. When configured to output to Elasticsearch, APM Server uses a custom Elasticsearch output called (formerly known as `modelindexer`).
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: store-gateway.md

title: "Pyroscope Store-gateway" menuTitle: "Store-gateway" description: "The store-gateway retrieves profiling data from long-term storeage." weight: 55 The store-gateways in Pyroscope are responsible for looking up profiling data in the bucket. A single store-gateway is responsible for a subset of the blocks in the long-term storage and will be involved by a [querier]. For details about store-gateway configuration, refer to .
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-1-7.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 8.1.7 <!-- Auto generated by update changelog github action --> Alerting: Fix alerts with evaluation interval more than 30 seconds resolving before notification. , Elasticsearch/Prometheus: Fix usage of proper SigV4 service namespace. ,
Project: Checkmk (Observability and Analysis / Observability)
File: 14226.md

key | value | date | 2024-03-08T13:17:45+00:00 version | 2.4.0b1 class | fix edition | cme component | wato level | 1 compatible | yes Activate changes stopped working when initiating a bulk discovery or using the DCD with automatic service discovery.