cwielenb/CNCF-Dataset huggingface dataset:
Project: Grafana Tempo (Observability and Analysis / Observability)
File: max-trace-limit-reached.md

title: Distributor refusing spans description: Troubleshoot distributor refusing spans weight: 471 aliases: ../operations/troubleshooting/max-trace-limit-reached/ The two most likely causes of refused spans are unhealthy ingesters or trace limits being exceeded. Unhealthy ingesters can be caused by failing OOMs or scale down events. If you have unhealthy ingesters, your log line will look something like this: ``` msg="pusher failed to consume trace data" err="at least 2 live replicas required, could only find 1" ``` In this case, you may need to visit the ingester at `/ingester/ring` on the Distributors and "Forget" the unhealthy ingesters. This will work in the short term, but the long term fix is to stabilize your ingesters. In high volume tracing environments, the default trace limits are sometimes not sufficient. These limits exist to protect Tempo and prevent it from OOMing, crashing or otherwise allow tenants to not DOS each other. If you are refusing spans due to limits, you will see logs like this at the distributor: ``` msg="pusher failed to consume trace data" err="rpc error: code = FailedPrecondition desc = TRACETOOLARGE: max size of trace (52428800) exceeded while adding 15632 bytes to trace a0fbd6f9ac5e2077d90a19551dd67b6f for tenant single-tenant" msg="pusher failed to consume trace data" err="rpc error: code = FailedPrecondition desc = LIVETRACESEXCEEDED: max live traces per tenant exceeded: per-user traces limit (local: 60000 global: 0 actual local: 60000) exceeded" msg="pusher failed to consume trace data" err="rpc error: code = ResourceExhausted desc = RATE_LIMITED: ingestion rate limit (15000000 bytes) exceeded while adding 10 bytes" ``` You will also see the following metric incremented. The `reason` label on this metric will contain information about the refused reason. ``` tempodiscardedspans_total ``` In this case, use available configuration options to .
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: memberlist-and-the-gossip-protocol.md

title: "Pyroscope memberlist and gossip protocol" menuTitle: "Memberlist and gossip protocol" description: "Memberlist manages Pyroscope cluster membership and node detection failure." weight: 80 is a Go library that manages cluster membership, node failure detection, and message passing using a gossip-based protocol. Memberlist is eventually consistent and network partitions are partially tolerated by attempting to communicate to potentially dead nodes through multiple routes. Pyroscope uses memberlist to implement the data structures between instances. Each instance maintains a copy of the hash rings. Each Pyroscope instance updates a hash ring locally and uses memberlist to propagate the changes to other instances. Updates generated locally and updates received from other instances are merged together to form the current state of the ring on the instance. To configure memberlist, refer to . When using a memberlist-based KV store, every Pyroscope instance propagates the hash ring data structures to other instances using the following techniques: Propagating only the differences introduced in recent changes. Propagating the full hash ring data structure. Every `-memberlist.gossip-interval` an instance randomly selects a subset of all Pyroscope cluster instances configured by `-memberlist.gossip-nodes` and sends the latest changes to the selected instances. This operation is performed frequently and it's the primary technique used to propagate changes. In addition, every `-memberlist.pullpush-interval` an instance randomly selects another instance in the Pyroscope cluster and transfers the full content of the KV store, including all hash rings (unless `-memberlist.pullpush-interval` is zero, which disables this behavior). After this operation is complete, the two instances have the same content as the KV store. This operation is computationally more expensive, and as a result, it's performed less frequently. The operation ensures that the hash rings periodically reconcile to a common state.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: demo.md

`kubectl get pods -w ` `kubectl apply -f ChaosExperiment/experiments-k8.yaml` `kubectl get chaosexperiments` `kubectl apply -f ChaosExecution/rbac-chaos-admin.yaml` `kubectl apply -f ChaosExecution/engine-nginx-count-admin.yaml` `argo submit Argo/argowf-chaos-admin.yaml -pappLabel=kiam -pappNamespace=kube-system -pfileName=pod-app-kill-health.json --watch` `argo submit Argo/argowf-perf-chaos-admin.yaml -plimit=2 --watch`
Project: Trickster (Observability and Analysis / Observability)
File: tracing.md

Trickster instruments Distributed Tracing with , which is a currently emergent, comprehensive observability stack that is in Public Beta. We import the to instrument support for tracing. As OpenTelemetry evolves to support additional exporter formats, we will work to extend Trickster to support those as quickly as possible. We also make a best effort to update our otel package imports to the latest releases, whenever we publish a new Trickster release. You can check the file to see which release of opentelemetry-go we are is using. In this view, to see which version of otel a specific Trickster release imports, use the branch selector dropdown to switch to the tag corresponding to that version of Trickster. Jaeger Jaeger Agent Zipkin Console/Stdout (printed locally by the Trickster process) Trickster allows the operator to configure multiple tracing configurations, which can be associated into each Backend configuration by name. The has exhaustive examples of configuring Trickster for distributed tracing. Trickster can insert several spans to the traces that it captures, depending upon the type and cacheability of the inbound client request, as described in the table below. | Span Name | Observes when Trickster is: | | - | - | | request | initially handling the client request by a Backend | | QueryCache | querying the cache for an object | | WriteCache | writing an object to the cache | | DeltaProxyCacheRequest | handling a Time Series-based client request | | FastForward | making a Fast Forward request for time series data | | ProxyRequest | communicating with an Origin server to fulfill a client request | | PrepareFetchReader | preparing a client response from a cached or Origin response | | CacheRevalidation | revalidating a stale cache object against its Origin | | FetchObject | retrieving a non-time-series object from an Origin | Trickster supports adding custom tags to every span via the configuration. Depending upon your preferred tracing backend, these may be referred to as attributes. See the for examples of adding custom attributes. Trickster also supports omitting any tags that Trickster inserts by default. The list of default tags are below. For example on the "request" span, an `http.url` tag is attached with the current full URL. In deployments where that tag may introduce too much cardinality in your backend trace storage system, you may wish to omit that tag and rely on the more concise `path` tag. Each tracer config can be provided a string list of tags to omit from traces. `http.url` - the full HTTP request URL `backend.name` `backend.provider` `cache.name` `cache.provider` `router.path` - request path trimmed to the route match path for the request (e.g., `/api/v1/query`), good for aggregating when there are large variations in the full URL path `cache.status` - the lookup status of cache query. See the for a description of the attribute values. `isRange` - is true if the client request includes an HTTP `Range` header `isPCF` - is true if the origin is configured for
Project: Netdata (Observability and Analysis / Observability)
File: 10min_cpu_usage.md

This alarm calculates an average on CPU utilization over a period of 10 minutes, excluding `iowait`, `nice` and `steal` values. *Note that on FreeBSD, the alert excludes only `nice`. `iowait` is the percentage of time the CPU waits on a disk for an I/O; it happens when the former is getting bottlenecked by the latter. At this point the CPU is being idle, waiting only on the I/O. `nice` value of a processor is the time it has spent on running low priority processes. Low priority processes are those with a 'nice' value greater than 0 (on UNIX-like systems, a higher nice value indicates a lower priority). `steal`, in a virtual machine, is the percentage of time that particular virtual CPU has to wait for an available host CPU to run on. If this metric goes up, it means that your VM is not getting the processing power it needs. Processes slowing down your CPU There are two primary cases in which this alarm is raised, and determining which applies to you requires understanding your own scenario. High CPU utilization with high `nice` value means that the system is running through all the low priority processes, and if some high priority process needs CPU time, it can get it at any time. High CPU utilization with low `nice` value means that the CPU is used on high priority processes and new ones will not be able to take CPU time, and they will have to wait. The latter scenario is worth investigating if there is a process slowing down your CPU. We suggest you go to your node on Netdata Cloud and click the `nice` dimension under the `Total CPU Utilization` chart to see the value. You can then check per process CPU usage using `top`: If you're using Linux: ``` root@netdata~ # top -o +%CPU -i ``` And for FreeBSD: ``` root@netdata~ # top -o cpu -I ``` Here, you can see which processes are the main cpu consumers on the `CPU` column. It would be helpful to close any of the main consumer processes, but Netdata strongly suggests knowing exactly what processes you are closing and being certain that they are not necessary.
Project: Checkmk (Observability and Analysis / Observability)
File: 16606.md

key | value | date | 2024-04-10T12:26:35+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes The agent did not handle the cases where shelves had no fans, temperature sensors or PSUs. This led to crashes during the agent execution. With this werk we now correctly handle these scenarios and the corresponding services are not discovered if no items are found.
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: issue--bug-report.md

name: Bug Report about: Create a report to help us improve Pyroscope. title: '' labels: '' assignees: '' A clear and concise description of what the bug is. Steps to reproduce the behavior: Start Pyroscope (SHA or version) Perform Operations(Read/Write/Others) A clear and concise description of what you expected to happen. Infrastructure: [e.g., Kubernetes, bare-metal, laptop] Deployment tool: [e.g., helm, jsonnet] <!-- Additional relevant info which can help us debug this issue easily like logs, configuration etc. -->
Project: DeepFlow (Observability and Analysis / Observability)
File: README.md

Response of tempo api: ``` { // The resource for the spans in this message. // If this field is not set then no resource info is known. "resource":{ "attributes":[ { "key":"service.name", "value":{ "stringValue":"xxx" } }, { "key":"xxx", "value":{ "stringValue":"xxx" } } ... ] }, // The instrumentation library information for the spans in this message. // Semantically when InstrumentationLibrary isn't set, it is equivalent with // an empty instrumentation library name (unknown). "instrumentationLibrarySpans":{ "instrumentationLibrary":{ "name":"xxx", "version":"xxx" }, "spans":[ { // A unique identifier for a trace. All spans from the same trace share // the same `trace_id`. The ID is a 16-byte array. An ID with all zeroes // is considered invalid. // // This field is semantically required. Receiver should generate new // random traceid if empty or invalid traceid was received. // // This field is required. "traceId":"WTqtr7BlQGzwAyzVaQhnqA= // A unique identifier for a span within a trace, assigned when the span // is created. The ID is an 8-byte array. An ID with all zeroes is considered // invalid. // // This field is semantically required. Receiver should generate new // random spanid if empty or invalid spanid was received. // // This field is required. "spanId":"thJE5jAyatg // The `span_id` of this span's parent span. If this is a root span, then this // field must be empty. The ID is an 8-byte array. "parentSpanId":"AdJrrVtdU9g // A description of the span's operation. // // For example, the name can be a qualified method name or a file name // and a line number where the operation is called. A best practice is to use // the same display name at the same call point in an application. // This makes it easier to correlate spans in different traces. // // This field is semantically required to be set to non-empty string. // Empty value is equivalent to an unknown span name. // // This field is required. "name":"proxy0.getStoc // Distinguishes between spans generated in a particular context. For example, // two spans with the same name may be distinguished using `CLIENT` (caller) // and `SERVER` (callee) to identify queueing latency associated with the span. "kind":"SPANKINDINTERNA "startTimeUnixNano":"1668391014669291592", "endTimeUnixNano":"166839101466938600 // attributes is a collection of key/value pairs. Note, global attributes // like server name can be set using the resource API. Examples of attributes: // // "/http/useragent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 1014_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36" // "/http/server_latency": 300 // "abc.com/myattribute": true // "abc.com/score": 10.239 // // The OpenTelemetry API specification further restricts the allowed value types: // https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/common.md#attributes // Attribute keys MUST be unique (it is not allowed to have more than one // attribute with the same key). "attributes":[ { "key":"xxx", "value":{ "stringValue":"xxx" } }, ... ], "status":{ } } ] } } ```
Project: Fluentd (Observability and Analysis / Observability)
File: ISSUE_TEMPLATE.md

Check first and here is the list to help us investigate the problem. Got a question or problem? RESOURCES of and may help you. If you have further questions about Fluentd and plugins, please direct these to . Don't use Github issue for asking questions. Here are examples: I installed xxx plugin but it doesn't work. Why? Fluentd starts but logs are not sent to xxx. Am I wrong? I want to do xxx. How to realize it with plugins? We may close such questions to keep clear repository for developers and users. Github issue is mainly for submitting a bug report or feature request. See below. If you can't judge your case is a bug or not, use mailing list or slack first.
Project: Checkmk (Observability and Analysis / Observability)
File: 16424.md

key | value | date | 2024-04-18T16:06:48+00:00 version | 2.4.0b1 class | fix edition | cre component | omd level | 1 compatible | yes With this Werk, `omd start` will no longer create a new redis process if redis is already started. This aligns the behaviour with the other services of a site.
Project: SkyWalking (Observability and Analysis / Observability)
File: benchmark.md

JMH is a Java harness for building, running, and analysing nano/micro/milli/macro benchmarks written in Java and other languages targeting the JVM. We have a module called `microbench` which performs a series of micro-benchmark tests for JMH testing. Make new JMH tests extend the `org.apache.skywalking.oap.server.microbench.base.AbstractMicrobenchmark` to customize runtime conditions (Measurement, Fork, Warmup, etc.). You can build the jar with command `./mvnw -Dmaven.test.skip -DskipTests -pl :microbench package -am -Pbenchmark`. JMH tests could run as a normal unit test. And they could run as an independent uber jar via `java -jar benchmark.jar` for all benchmarks, or via `java -jar /benchmarks.jar exampleClassName` for a specific test. Output test results in JSON format, you can add `-rf json` like `java -jar benchmarks.jar -rf json`, if you run through the IDE, you can configure the `-DperfReportDir=savePath` parameter to set the JMH report result save path, a report results in JSON format will be generated when the run ends. More information about JMH can be found here: .
Project: Netdata (Observability and Analysis / Observability)
File: consul_license_expiration_time.md

This alert checks the Consul Enterprise license expiration time. It triggers a warning if the license expiration time is less than 14 days, and critical if it's less than 7 days. consul.licenseexpirationtime: Monitors the remaining time in seconds until the Consul Enterprise license expires. Consul is a service mesh solution that enables organizations to discover services and safely process network traffic across dynamic, distributed environments. Check the current license expiration time You can check the remaining license expiration time for your Consul Enterprise instance using the Consul API: ``` curl http://localhost:8500/v1/operator/license ``` Look for the `ExpirationTime` field in the returned JSON output. Renew the license If your license is about to expire, you will need to acquire a new license. Contact to obtain and renew the license key. Apply the new license You can apply the new license key either by restarting Consul with the new key specified via the `CONSULLICENSE` environment variable or the `licensepath` configuration option, or by updating the license through the Consul API: ``` curl -X PUT -d @new_license.json http://localhost:8500/v1/operator/license ``` Replace `new_license.json` with the path to a file containing the new license key in JSON format. Verify the new license expiration time After applying the new license, you can check the new license expiration time using the Consul API again: ``` curl http://localhost:8500/v1/operator/license ``` Ensure that the `ExpirationTime` field shows the new expiration time.
Project: Teletrace (Observability and Analysis / Observability)
File: SECURITY.md

This document outlines security procedures and general policies for the Teletrace project. The Teletrace team and community take all security bugs in Teletrace seriously. Thank you for improving the security of Teletrace. We appreciate your efforts and responsible disclosure and will make every effort to acknowledge your contributions. Report security bugs by emailing `oss-security@cisco.com`. The lead maintainer will acknowledge your email within 48 hours, and will send a more detailed response within 48 hours indicating the next steps in handling your report. After the initial reply to your report, the security team will endeavor to keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance. When the security team receives a security bug report, they will assign it to a primary handler. This person will coordinate the fix and release process, involving the following steps: Confirm the problem and determine the affected versions. Audit code to find any potential similar problems. Prepare fixes for all releases still under maintenance. These fixes will be released as quickly as possible. If you have suggestions on how this process could be improved please submit a pull request.
Project: Graylog (Observability and Analysis / Observability)
File: SplitButton.md

```js import { MenuItem } from 'components/bootstrap'; const styles = ['Primary', 'Danger', 'Warning', 'Success', 'Info', 'Link', 'Default']; styles.map((style) => { const styleName = style.toLowerCase(); return ( <span key={`split-button-${styleName}`}> <SplitButton title={style} bsStyle={styleName} id={`split-button-${styleName}`}> <MenuItem header>Header</MenuItem> <MenuItem eventKey="1">Default</MenuItem> <MenuItem eventKey="2" active>Active</MenuItem> <MenuItem eventKey="4" disabled>Disabled</MenuItem> <MenuItem divider /> <MenuItem eventKey="5">Separated</MenuItem> </SplitButton>{' '} </span> ) }) ```
Project: Pixie (Observability and Analysis / Observability)
File: bug_report.md

name: Bug report about: Create a report to help us improve Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: Go to '...' Click on '....' Scroll down to '....' See error Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Please make sure the screenshot does not contain any sensitive information such as API keys or access tokens. Logs Please attach the logs by running the following command: ``` ./px collect-logs ``` App information (please complete the following information): Pixie version K8s cluster version Node Kernel version Browser version Additional context Add any other context about the problem here.
Project: Elastic (Observability and Analysis / Observability)
File: date_parse.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Returns a date by parsing the second argument using the format specified in the first argument. ``` ROW date_string = "2022-05-06" | EVAL date = DATEPARSE("yyyy-MM-dd", datestring) ```
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: neudesic.md

has assembled a fully-managed partner ecosystem of leading cloud and independent software partners that provide us maximum flexibility to architect technology, strategies and solutions that drive business growth. Neudesic offers decades of experience, proven frameworks and a disciplined approach to quickly deliver reliable, quality solutions that help you go to market faster and get a leg up on your competition. We are using litmus chaos to inject faults in our aks environments. Before arriving at litmus we explored other tools , but found litmus to be the most well rounded one and the one that aligned closest to the principles of chaos We are using litmus in our pre prod environments in the ci cd stage as a gate for releases The chaos gated deployments make use of the in-built git ops integration in litmus