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

description: Use the Service Graph and Service Graph view keywords: grafana tempo guide tracing labels: products: cloud enterprise oss menuTitle: Service Graph and Service Graph view title: Service Graph and Service Graph view weight: 500 The Service Graph is a visual representation of the relationships between services. Each node on the graph represents a service such as an API or database. You use the Service Graph to detect performance issues; track increases in error, fault, or throttle rates in services; and investigate root causes by viewing corresponding traces. {{< figure src="/static/img/docs/node-graph/node-graph-8-0.png" class="docs-image--no-shadow" max-width="500px" caption="Screenshot of a Node Graph" >}} or to generate Service Graph data. Link a Prometheus data source in the Tempo data source's settings. Navigate to . Select the Tempo data source. Select the Service Graph query type. Run the query. (Optional) Filter by service name. For details, refer to . Each circle in the graph represents a service. To open a context menu with additional links for quick navigation to other relevant information, click a service. Numbers inside the circles indicate the average time per request and requests per second. Each circle's color represents the percentage of requests in each state: | Color | State | | - | - | | Green | Success | | Red | Fault | | Yellow | Errors | | Purple | Throttled responses | Service graph view displays a table of request rate, error rate, and duration metrics (RED) calculated from your incoming spans. It also includes a node graph view built from your spans. {{< figure src="/static/img/docs/tempo/apm-table.png" class="docs-image--no-shadow" max-width="500px" caption="Screenshot of the Service Graph view" >}} For details, refer to the . To open the Service Graph view: Link a Prometheus data source in the Tempo data source settings. Navigate to . Select the Tempo data source. Select the Service Graph query type. Run the query. (Optional) Filter your results. {{% admonition type="note" %}} Grafana uses the `tracesspanmetricscallstotal` metric to display the name, rate, and error rate columns, and `tracesspanmetricslatencybucket` to display the duration column. These metrics must exist in your Prometheus data source. {{% /admonition %}} To open a query in Prometheus with the span name of that row automatically set in the query, click a row in the rate, error rate, or duration columns. To open a query in Tempo with the span name of that row automatically set in the query, click a row in the links column. {{% docs/reference %}} {{% /docs/reference %}}
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_job.Job.md

title: "Class: Job" linkTitle: "Job" slug: "libk8sjob.Job" .Job `any` `Job` new Job(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeJob\>('Job').constructor `Static` apiEndpoint: `Object` | Name | Type | | : | : | | `scale?` | { `get`: (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> ; `put`: (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> } | | `scale.get` | (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> | | `scale.put` | (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> | _ `Static` className: `string` makeKubeObject<KubeJob\>('Job').className `get` spec(): `any` `any` _ `get` status(): `any` `any` getContainers(): [] [] _ getDuration(): `number` Returns the duration of the job in milliseconds. `number` _ `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeJob\>('Job').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeJob\>('Job').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeJob\>('Job').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeJob\>('Job').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeJob\>('Job').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeJob\>('Job').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeJob\>('Job').useList
Project: SkyWalking (Observability and Analysis / Observability)
File: x-process-propagation-headers-v3.md

Version 3.0 SkyWalking is more akin to an APM system, rather than a common distributed tracing system. SkyWalking's headers are much more complex than those found in a common distributed tracing system. The reason behind their complexity is for better analysis performance of the OAP. You can find many similar mechanisms in other commercial APM systems (some of which are even more complex than ours!). The SkyWalking Cross Process Propagation Headers Protocol v3, also known as the sw8 protocol, is designed for context propagation. The standard header is the minimal requirement for context propagation. Header Name: `sw8`. Header Value: 8 fields split by `-`. The length of header value must be less than 2k (default). Example of the value format: `XXXXX-XXXXX-XXXX-XXXX` Values must include the following segments, and all string type values are in BASE64 encoding. Required: Sample. 0 or 1. 0 means that the context exists, but it could (and most likely will) be ignored. 1 means this trace needs to be sampled and sent to the backend. Trace ID. String(BASE64 encoded). A literal string that is globally unique. Parent trace segment ID. String(BASE64 encoded). A literal string that is globally unique. Parent span ID. Must be an integer. It begins with 0. This span ID points to the parent span in parent trace segment. Parent service. String(BASE64 encoded). Its length should be no more than 50 UTF-8 characters. Parent service instance. String(BASE64 encoded). Its length should be no more than 50 UTF-8 characters. Parent endpoint. String(BASE64 encoded). The operation name of the first entry span in the parent segment. Its length should be less than 150 UTF-8 characters. Target address of this request used on the client end. String(BASE64 encoded). The network address (not necessarily IP + port) used on the client end to access this target service. Sample values: `1-TRACEID-SEGMENTID-3-PARENTSERVICE-PARENTINSTANCE-PARENT_ENDPOINT-IPPORT` The extension header item is designed for advanced features. It provides interaction capabilities between the agents deployed in upstream and downstream services. Header Name: `sw8-x` Header Value: Split by `-`. The fields are extendable. The current value includes fields. Tracing Mode. Empty, 0, or 1. Empty or 0 is the default. 1 indicates that all spans generated in this context will skip analysis, `spanObject#skipAnalysis=true`. This context is propagated to upstream by default, unless it is changed in the tracing process. The timestamp of sending on the client end. This is used in async RPC, such as MQ. Once it is set, the consumer end would calculate the latency between sending and receiving, and tag the latency in the span by using key `transmission.latency` automatically.
Project: Vector (Observability and Analysis / Observability)
File: internal_logs.md

title: Internal logs description: Expose all log and trace messages emitted by the running Vector instance component_kind: source layout: component tags: ["vector", "instance", "local", "internal", "component", "source", "logs"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Netdata (Observability and Analysis / Observability)
File: postgres_acquired_locks_utilization.md

This alert monitors the average `acquired locks utilization` over the last minute in PostgreSQL databases. If you receive this alert, it means that the acquired locks utilization for your system is near or above the warning threshold (15% or 20%). In PostgreSQL, a lock is a mechanism used to control access to shared resources, such as database tables or rows. When multiple users or tasks are working with the database, locks help coordinate their activities and prevent conflicts. Acquired locks utilization refers to the percentage of locks currently in use in the system, compared to the total number of locks available. Identify the most lock-intensive queries: You can use the following SQL query to get the list of most lock-intensive queries running on your PostgreSQL server: ``` SELECT pid, locktype, mode, granted, clientaddr, querystart, now() - query_start AS duration, query FROM pg_locks l JOIN pgstatactivity a ON l.pid = a.pid WHERE query != '<IDLE>' ORDER BY duration DESC; ``` Analyze the problematic queries and look for ways to optimize them, such as: a. Adding missing indexes for faster query execution. b. Updating and optimizing query plans. c. Adjusting lock types or lock levels, if possible. Check the overall health and performance of your PostgreSQL server: a. Monitor the CPU, memory, and disk usage. b. Consider configuring the autovacuum settings to maintain your database's health. Monitor database server logs for any errors or issues. If the problem persists, consider adjusting the warning threshold (`warn` option), or even increasing the available locks in the PostgreSQL configuration (`maxlocksper_transaction`).
Project: Vector (Observability and Analysis / Observability)
File: docker.md

title: Install Vector on Docker short: Docker weight: 1 aliases: ["/docs/setup/installation/containers/docker"] [Docker] is an open platform for developing, shipping, and running applications and services. With Docker, you can manage your infrastructure in the same ways you manage your services. By taking advantage of Docker's methodologies for shipping, testing, and deploying code quickly, you can significantly reduce the delay between writing code and running it in production. This page covers installing and managing Vector on the Docker platform. Pull the Vector image: ```shell docker pull timberio/vector:{{< version >}}-debian ``` {{< success >}} Other available distributions (beyond `debian`): `alpine` `distroless-libc` `distroless-static` {{< /success >}} Vector is an end-to-end observability data pipeline designed to deploy under various roles. You mix and match these roles to create topologies. The intent is to make Vector as flexible as possible, allowing you to fluidly integrate Vector into your infrastructure over time. The deployment section demonstrates common Vector pipelines: {{< jump "/docs/setup/deployment/topologies" >}} Create a new Vector configuration. The below will output dummy logs to stdout. ```shell cat <<-EOF > $PWD/vector.yaml api: enabled: true address: 0.0.0.0:8686 sources: demo_logs: type: demo_logs interval: 1 format: json sinks: console: inputs: demo_logs target: stdout type: console encoding: codec: json EOF ``` ```shell docker run \ -d \ -v $PWD/vector.yaml:/etc/vector/vector.yaml:ro \ -p 8686:8686 \ --name vector \ timberio/vector:{{< version >}}-debian ``` Make sure to substitute out `debian` if you're using a different distribution. ```shell docker stop vector ``` ```shell docker kill --signal=HUP vector ``` ```shell docker restart $(docker ps -aqf "name=vector") ``` To tail the logs from your Vector image: ```shell docker logs -f $(docker ps -aqf "name=vector") ``` To access metrics from your Vector image: ```shell docker exec -ti $(docker ps -aqf "name=vector") vector top ``` ```shell docker rm vector ```
Project: Checkmk (Observability and Analysis / Observability)
File: 15026.md

key | value | date | 2024-03-15T10:37:41+00:00 version | 2.4.0b1 class | fix edition | cre component | wato level | 1 compatible | yes Without the "addormodify_executables" permission users do not have the right to change any executable run by checkmk, either on the site or via the agent. The agent config options "pythonplugins" and "lnxremotealerthandlers" have not yet checked for that permission. In the UI "pythonplugins" and "lnxremotealerthandlers are called "Python agent plugin execution (UNIX)" and "Remote alert handler (Linux)" respectively.
Project: Grafana (Observability and Analysis / Observability)
File: span-filters.md

description: Use span filters to filter spans in the timeline viewer keywords: grafana tempo guide tracing labels: products: cloud enterprise oss menuTitle: Span filters title: Span filters weight: 600 Using span filters, you can filter your spans in the trace timeline viewer. The more filters you add, the more specific are the filtered spans. You can add one or more of the following filters: Service name Span name Duration Tags (which include tags, process tags, and log fields) To only show the spans you have matched, select the `Show matches only` toggle. <!-- Adding these in case they are needed. --> {{% docs/reference %}} {{% /docs/reference %}}
Project: Ddosify (Observability and Analysis / Observability)
File: pull_request_template.md

Please check the relevant boxes by putting an "x" in the appropriate box. [ ] Bug fix (non-breaking change which fixes an issue) [ ] New feature (non-breaking change which adds functionality) [ ] Breaking change (fix or feature that would cause existing functionality to change) [ ] This change requires a documentation update Please provide a brief and concise description of the changes in this pull request, including the problem being solved or the feature being added. Please list any related issues or reference them. Please go through this checklist and make sure all applicable tasks have been done. document. [ ] My code follows the code style of this project. [ ] I have added tests to cover my changes. [ ] All new and existing tests passed. as necessary if there are changes. [ ] I have tested the changes on my local machine before submitting the PR. If applicable, please provide screenshots, video or GIF to help demonstrate the changes.
Project: Netdata (Observability and Analysis / Observability)
File: web_log_1m_internal_errors.md

This alert is generated by the Netdata Agent when monitoring web server logs. This alert is triggered when the web server has experienced an unusually high number of internal errors (HTTP status codes 5xx) within the last minute. Internal errors indicate that there is an issue with the server or the application running on it, which is causing the server to fail in processing client requests. Check the web server logs: Inspect the web server logs to identify the specific internal errors and any patterns that might be causing the issue. Depending on the web server you are using (e.g., Apache, Nginx, etc.), the log files will be located in different directories. You can usually find the logs in the following locations: Apache: `/var/log/apache2/` (Debian/Ubuntu) or `/var/log/httpd/` (RHEL/CentOS) Nginx: `/var/log/nginx/` To view the logs in real-time, you can use the `tail` command: ``` tail -f /path/to/your/log/directory/access.log ``` Analyze the application logs: If you have an application running on the web server (e.g., PHP, Node.js, Python), check the application logs for any errors or issues that might be causing the internal errors. Verify server resources: Ensure that your server has enough resources (CPU, RAM, disk space) to handle the current workload. High resource utilization can lead to internal errors. You can use Netdata's dashboard to monitor the server resources in real-time. Check server configuration: Review the web server's configuration files for any misconfigurations or settings that may be causing the issue. For example, incorrect permissions, wrong file paths, or improper configurations can lead to internal errors. Inspect application code: Review your application code to identify any bugs, memory leaks, or issues that could be causing the internal errors. If you recently deployed new code or made changes, consider rolling back to a previous version to see if the issue persists. Monitor web server metrics: Keep an eye on the web server's metrics, such as response times and request rates, to identify any performance bottlenecks or potential issues that may be causing the internal errors.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: v5.2.md

title: "Grafana Mimir Helm chart version 5.2 release notes" menuTitle: "V5.2 release notes" description: "Release notes for Grafana Mimir Helm chart version 5.2" weight: 300 Grafana Labs is excited to announce version 5.2 of the Grafana Mimir Helm chart, which is compatible with Grafana Mimir v2.11 or Grafana Enterprise Metrics (GEM) v2.11. The `mimir-distributed` Helm chart is the best way to install Mimir on Kubernetes. The highlights that follow include the top features, enhancements, and bugfixes in this release. For a comprehensive list of changes, see the . The default timeout used for index-queries caches is increased from `200ms` to `450ms` to reduce the number of connections opened under increased load. The default `clusterDomain` is changed from `cluster.local` to `cluster.local.` to reduce the number of DNS lookups performed. Notable enhancements are as follows: The lifecycle management of persistent volumes belonging to compactor, ingester, store-gateway and alertmanager components can now be configured via the parameters `enableRetentionPolicy`, `whenScaled` and `whenDeleted`. The chart now supports the option to use a plain `Ingress` resource instead of a gateway service. : Revert , introduced in 5.2.0, which broke installations relying on the default value of `blocksstorage.backend: s3`. If `mimir.structuredConfig.blocksstorage.backend: s3` wasn't explicitly set, then Mimir would fail to connect to S3 and will instead try to read and write blocks to the local filesystem. : Update GEM to v2.11.2 : Fix crashloop in GEM admin-cache container
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_statefulSet.StatefulSet.md

title: "Class: StatefulSet" linkTitle: "StatefulSet" slug: "libk8sstatefulSet.StatefulSet" .StatefulSet `any` `StatefulSet` new StatefulSet(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeStatefulSet\>('StatefulSet').constructor `Static` apiEndpoint: `Object` | Name | Type | | : | : | | `scale?` | { `get`: (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> ; `put`: (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> } | | `scale.get` | (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> | | `scale.put` | (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> | _ `Static` className: `string` makeKubeObject<KubeStatefulSet\>('StatefulSet').className `get` spec(): `any` `any` _ `get` status(): `any` `any` getContainers(): [] [] _ `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeStatefulSet\>('StatefulSet').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeStatefulSet\>('StatefulSet').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeStatefulSet\>('StatefulSet').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeStatefulSet\>('StatefulSet').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeStatefulSet\>('StatefulSet').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeStatefulSet\>('StatefulSet').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeStatefulSet\>('StatefulSet').useList
Project: Netdata (Observability and Analysis / Observability)
File: consul_service_health_check_status.md

This alert is triggered when the `health check status` of a service in a `Consul` service mesh changes to a `warning` or `critical` state. It occurs when a service health check for a specific service `${label:servicename}` fails on a server `${label:nodename}` in a datacenter `${label:datacenter}`. `Consul` is a service mesh solution developed by HashiCorp that can be used to connect and secure services across dynamic, distributed infrastructure. It maintains a registry of service instances, performs health checks, and offers a flexible and high-performance service discovery mechanism. A service health check is a way to determine whether a particular service in a distributed system is running correctly, reachable, and responsive. It is an essential component of service discovery and can be used to assess the overall health of a distributed system. Check the health status of the service that triggered the alert in the Consul UI. Access the Consul UI and navigate to the affected service's details page. Look for the health status information and the specific health check that caused the alert. Inspect the logs of the service that failed the health check. Access the logs of the affected service and look for any error messages or events that might have caused the health check to fail. Depending on the service, this might be application logs, system logs, or container logs (if the service is running in a container). Identify and fix the issue causing the health check failure. Based on the information from the logs and your knowledge of the system, address the issue that's causing the health check to fail. This might involve fixing a bug in the service, resolving a connection issue, or making a configuration change. Verify that the health check status has returned to a healthy state. After addressing the issue, monitor the service in the Consul UI and confirm that its health check status has returned to a healthy state. If the issue persists, continue investigating and resolving any underlying causes until the health check is successful.