cwielenb/CNCF-Dataset huggingface dataset:
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: vmware.md

is a cloud computing and virtualization technology company. In EUC (End-user computing), we are transforming to SaaS. And resilience is key to the product success. After searching the chaos engineering tools, we decided to use litmus for below reasons: It has fast release and is well maintained. It is a CNCF project. It is kubernetes friendly. After the the services pass integration testing, the builds are refreshed to the Chaos Stack. Litmus is used to inject chaos to this environment in order to make sure the services can still pass the integration test cases.
Project: OpenTelemetry (Observability and Analysis / Observability)
File: faas.md

The initial goal of this project is to put Lambda monitoring into a consistently good state. Across vendors, customers consistently struggle to instrument their Lambdas and identify the best practices way to monitor a Lambda. Lambda layer behavior differs by language, context propagation is frequently broken, and cold starts are a known issue. This SIG will also look beyond Lambdas and to more broadly Functions as a Service. We want to ensure: The FAAS spec has been reviewed, assessed to apply generically, and stabilized Consistent lambda layer behavior by language and uniform conformance to the spec There is clear community guidance on how to monitor Lambdas End to end context propagation using community protocols / propagation across typical Lambda architectures (e.g async) Cold start data capture and submission The new TelemetryAPI is properly integrated and utilized by OpenTelemetry This SIG will also serve as a working group for all FAAS topics going forward. Stabilized FAAS semantic conventions Updated Lambda Layer extensions that follow consistent trace propagation and have consistent behavior across languages. Cold start processor for the collector The first 2 language implementations will be Node.JS and Python. The following vendors are interested in improving this area.: Lightstep AWS Splunk (@tsloughter) Cisco (@arbiv) Honeycomb (@cartermp) While Lambdas are the focus of this effort we need other Functions As A Service (FAAS) experts to ensure we're building conventions that make sense for the stateless function space in general. GCP or Azure participation would be welcome. Project Lead: @Aneurysm9 Sponsoring TC Members: @carlosalberto TBA Implementation Engineers: @tylerbenson @codeboten Cisco contributors (@arbiv) Honeycomb contributors (@cartermp) @tsloughter @xoscar Implementation Maintainers or Approvers: JavaScript - @mwear Python - @ocelotl Lambda SME(s): @Aneurysm9 to add To deliver the improvements promptly we propose meeting at least 2 days a week for the 6 week planning cycle as specified in the new Semantic Conventions Process Doc Meeting Times: PST Option: Tuesday @ 12 pm PST CET Option: Wednesday @ 7 am PST New working group will be kicked off in January The WG has 6 weeks to propose improvements to the specification and solutions - Beginning of March OTeps and the first implementation in JavaScript will be reviewed by the community - All of March Implementation - we want to start with JavaScript and Python as our first target implementation languages - Beginning of April https://github.com/open-telemetry/opentelemetry-lambda
Project: SkyWalking (Observability and Analysis / Observability)
File: changes-7.0.0.md

SkyWalking discards the supports of JDK 1.6 and 1.7 on the java agent side. The minimal requirement of JDK is JDK8. Support method performance profile. Provide new E2E test framework. Remove AppVeyor from the CI, use GitHub action only. Provide new plugin test tool. Don't support SkyWalking v5 agent in-wire and out-wire protocol. v6 is required. Add lazy injection API in the agent core. Support Servlet 2.5 in the Struts plugin. Fix RestTemplate plugin ClassCastException in the Async call. Add Finagle plugin. Add test cases of H2 and struts. Add Armeria 0.98 plugin. Fix ElasticSearch plugin bug. Fix EHCache plugin bug. Fix a potential I/O leak. Support Oracle SID mode. Update Byte-buddy core. Performance tuning: replace AtomicInteger with AtomicIntegerFieldUpdater. Add AVRO plugin. Update to JDK 1.8 Optimize the ignore plugin. Enhance the gRPC plugin. Add Kotlin Coroutine plugin. Support HTTP parameter collection in Tomcat and SpringMVC plugin. Add @Tag annotation in the application toolkit. Move Lettuce into the default plugin list. Move Webflux into the default plugin list. Add HttpClient 3.x plugin. Support InfluxDB as a new storage option. Add `selector` in the `application.yml`. Make the provider activation more flexible through System ENV. Support sub-topology map query. Support gRPC SSL. Support HTTP protocol for agent. Support Nginx LUA agent. Support skip the instance relationship analysis if some agents doesn't have upstream address, currently for LUA agent. Support metrics entity name in the storage. Optional, default OFF. Merge the HOUR and DAY metrics into MINUTE in the ElasticSearch storage implementation. Reduce the payload for ElasticSearch server. Support change detection mechanism in DCS. Support Daily step in the ElasticSearch storage implementation for low traffic system. Provide profile export tool. Support alarm gRPC hook. Fix PHP language doesn't show up on the instance page. Add more comments in the source codes. Add a new metrics type, multiple linears. Fix thread concurrency issue in the alarm core. Support custom topology definition. Add FAQ about `python2` command required in the compiling. Add doc about new e2e framework. Add doc about the new profile feature. Powered-by page updated. All issues and pull requests are
Project: Graylog (Observability and Analysis / Observability)
File: ExternalLinkButton.md

`ExternalLinkButton`: ```js <ExternalLinkButton href="http://docs.graylog.org/">Graylog documentation</ExternalLinkButton> ``` `ExternalLinkButton` with different size, style and icon: ```js <ExternalLinkButton href="http://docs.graylog.org/" bsStyle="success" bsSize="lg" iconName="help"> Graylog documentation </ExternalLinkButton> ``` `ExternalLinkButton` that is disabled: ```js <ExternalLinkButton href="http://docs.graylog.org/" disabled>Graylog documentation</ExternalLinkButton> ```
Project: Grafana Tempo (Observability and Analysis / Observability)
File: traceql-metrics.md

aliases: [] title: TraceQL metrics menuTitle: TraceQL metrics description: Learn about using TraceQL metrics. weight: 550 keywords: Prometheus TraceQL TraceQL metrics {{< docs/experimental product="TraceQL metrics" >}} Tempo 2.4 introduces the addition of metrics queries to the TraceQL language as an experimental feature. Metric queries extend trace queries by applying a function to trace query results. This powerful feature creates metrics from traces, much in the same way that LogQL metric queries create metrics from logs. Initially, only `countovertime` and `rate` are supported. For example: ``` { resource.service.name = "foo" && status = error } | rate() ``` In this case, we are calculating the rate of the erroring spans coming from the service `foo`. Rate is a `spans/sec` quantity. Combined with the `by()` operator, this can be even more powerful! ``` { resource.service.name = "foo" && status = error } | rate() by (span.http.route) ``` Now, we are still rating the erroring spans in the service `foo` but the metrics have been broken down by HTTP endpoint. This might let you determine that `/api/sad` had a higher rate of erroring spans than `/api/happy`, for example. You can use the TraceQL metrics in Grafana with any existing or new Tempo data source. This capability is available in Grafana Cloud and Grafana (10.4 and newer). To use the metrics generated from traces, you need to: Set the `local-blocks` processor to active in your `metrics-generator` configuration Configure a Tempo data source configured in Grafana or Grafana Cloud Access Grafana Cloud or Grafana 10.4 Once the `local-blocks` processor is enabled in your `metrics-generator` configuration, you can configure it using the following block to make sure it records all spans for TraceQL metrics. Here is an example configuration: ```yaml metrics_generator: processor: local_blocks: filterserverspans: false storage: path: /var/tempo/generator/wal traces_storage: path: /var/tempo/generator/traces ``` Refer to the documentation for more information. Because of their expensive nature, these queries can take a long time to run in different systems. As such, consider increasing the timeouts in various places of the system to allow enough time for the data to be returned. Consider these areas when raising timeouts: Any proxy in front of Grafana Grafana data source for Prometheus pointing at Tempo Tempo configuration `querier.search.query_timeout` `server.httpserverread_timeout` `server.httpserverwrite_timeout` Additionally, a new `query_frontend.metrics` config has been added. The config here will depend on the environment. For example, in a cloud environment, smaller jobs with more concurrency may be desired due to the nature of scale on the backend. ```yaml query_frontend: metrics: concurrent_jobs: 1000 targetbytesper_job: 2.25e+08 # ~225MB interval: 30m0s ``` For an on-prem backend, you can improve query times by lowering the concurrency, while increasing the job size. ```yaml query_frontend: metrics: concurrent_jobs: 8 targetbytesper_job: 1.25e+09 # ~1.25GB ```
Project: Vector (Observability and Analysis / Observability)
File: centos.md

title: Install Vector on CentOS short: CentOS supported_installers: ["YUM", "RPM", "Docker", "Vector installer", "Helm"] weight: 3 [CentOS] is a Linux distribution that is functionally compatible with its upstream source, Red Hat Enterprise Linux. This page covers installing and managing Vector on the CentOS operating system. {{< supported-installers >}}
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_apiProxy.ClusterRequest.md

title: "Interface: ClusterRequest" linkTitle: "ClusterRequest" slug: "libk8sapiProxy.ClusterRequest" .ClusterRequest `Optional` certificateAuthorityData: `string` The certificate authority data _ `Optional` insecureTLSVerify: `boolean` Whether the server's certificate should not be checked for validity _ `Optional` kubeconfig: `string` KubeConfig (base64 encoded) _ `Optional` name: `string` The name of the cluster (has to be unique, or it will override an existing cluster) _ `Optional` server: `string` The cluster URL
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_registry.PluginSettingsDetailsProps.md

title: "Interface: PluginSettingsDetailsProps" linkTitle: "PluginSettingsDetailsProps" slug: "plugin_registry.PluginSettingsDetailsProps" .PluginSettingsDetailsProps Props for PluginSettingsDetailsProps component. `Optional` `Readonly` data: `Object` Data object representing the current state/configuration. readonly - The data object is readonly and cannot be modified. `Optional` onDataChange(`data`): `void` Callback function to be triggered when there's a change in data. | Name | Type | Description | | : | : | : | | `data` | `Object` | The updated data object. | `void`
Project: Grafana Loki (Observability and Analysis / Observability)
File: static_labels.md

title: static_labels menuTitle: description: The 'static_labels' Promtail pipeline stage. aliases: ../../../clients/promtail/stages/static_labels/ weight: The static_labels stage is an action stage that adds static-labels to the label set that is sent to Loki with the log entry. ```yaml static_labels: [ <string>: [<string>] ... ] ``` For the given pipeline: ```yaml json: expressions: stream: stream labels: stream: static_labels: customkey: customval ``` Given the following log line: ``` {"log":"log message\n","stream":"stderr","time":"2019-04-30T02:12:41.8443515Z"} ``` The first stage would extract `stream` into the extracted map with a value of `stderr`. The `labels` stage would turn that key-value pair into a label. The `static_labels` stage would add the provided static labels into the label set. The resulting entry that is sent to Loki will contain `stream="stderr"` and `customkey="customval"` as labels.
Project: Thanos (Observability and Analysis / Observability)
File: logging.md

Thanos supports request logging via flags. Components are either configured using `--request.logging-config-file` to reference to the configuration file or `--request.logging-config` to provide configuration as YAML directly. Configuration can be supplied globally, which applies to both `grpc` and `http`. Alternatively `http` and/or `grpc` can be configured independently. Valid `level` for `options` should be one of `INFO`, `WARNING`, `ERROR` or `DEBUG`. ```yaml options: level: ERROR ``` The request logging is configurable per phase via the `decision`. Valid decision combinations are as follows: Log details only when the request completes - Log level is determined by the status code from the response. ```yaml options: decision: log_start: false log_end: true ``` Log details prior to the request and when the request completes - Pre request log is made at `debug` level. ```yaml options: decision: log_start: true log_end: true ``` Specifying an `http` block enables request logging for each endpoint. ```yaml http: options: level: DEBUG decision: log_start: true log_end: true ``` The log level of the "post request" log is determined by the status code in the response. The following mappings apply: `200 <= status code < 500` = `debug` `status code > 500` = `error` Optionally, additional configuration can be supplied via the `config` block to create an allowlist of endpoint and port combinations. Note that this feature requires an exact match if enabled. ```yaml http: config: path: /api/v1/query port: 10904 path: /api/v1/app_range/metrics port: 3456 ``` Specifying a `grpc` block enables request logging for each service and method name combination. ```yaml grpc: options: level: DEBUG decision: log_start: true log_end: true ``` The log level of the "post request" log is determined by the in the response. The following mappings apply: Codes `2, 12, 13 ,15` = `error` All other codes = `debug` Optionally, additional configuration can be supplied via the `config` block to create an allowlist of service and method combinations. Note that this feature requires an exact match if enabled. ```yaml grpc: config: service: thanos.Store method: Info ``` The following example shows how the logging config can be supplied to the `sidecar` component: ```yaml args: sidecar | --objstore.config=type: GCS config: bucket: <bucket> --prometheus.url=http://localhost:9090 | --request.logging-config=http: config: path: /api/v1/query port: 10904 options: level: DEBUG decision: log_start: true log_end: true grpc: config: service: thanos.Store method: Info options: level: ERROR decision: log_start: false log_end: true --tsdb.path=/prometheus-data ``` Note that in the above example, logs will be emitted at `debug` level. These logs will be filtered unless the flag `--log.level=debug` is set.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: configure-native-histograms-ingestion.md

description: Learn how to configure Grafana Mimir to ingest and query native histograms. menuTitle: Native histograms title: Configure native histograms weight: 160 Prometheus native histograms ingestion is an experimental feature of Grafana Mimir. You can configure native histograms ingestion via the Prometheus endpoint globally or per tenant. {{% admonition type="note" %}} To enable support for querying native histograms together with , make sure that the flag `-query-frontend.query-result-response-format` is set to its default `protobuf` value on query frontends. {{% /admonition %}} To enable ingesting Prometheus native histograms over the endpoint for all tenants, set the flag `-ingester.native-histograms-ingestion-enabled=true` on the ingesters. To limit the number of native histogram buckets per sample, set the `-validation.max-native-histogram-buckets` flag on the distributors. The recommended value is `160` which is the default in the for exponential histograms. Exponential histograms in OpenTelemetry are a similar concept to Prometheus native histograms. At the time of ingestion, samples with more buckets than the limit will be scaled down, meaning that the resolution will be reduced and buckets will be merged until either the number of buckets is under the limit or the minimal resolution is reached. The behavior can be changed to dropping such samples by setting the `-validation.reduce-native-histogram-over-max-buckets` option to `false`. To enable ingesting Prometheus native histograms over the for a tenant, set the `nativehistogramsingestion_enabled` runtime value to `true`. To limit the number of native histogram buckets per sample for a tenant, set the `maxnativehistogram_buckets` runtime value. The recommended value is `160` which is the default in the for exponential histograms. Exponential histograms in OpenTelemetry are a similar concept to Prometheus native histograms. At the time of ingestion, samples with more buckets than the limit will be scaled down, meaning that the resolution will be reduced and buckets will be merged until either the number of buckets is under the limit or the minimal resolution is reached. The behavior can be changed to dropping such samples by setting the `-validation.reduce-native-histogram-over-max-buckets` option to `false`. ```yaml overrides: tenant1: nativehistogramsingestion_enabled: true maxnativehistogram_buckets: 160 ``` To learn more about sending native histograms to Mimir or Grafana Cloud Metrics via Grafana Agent or Prometheus, see or .
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: high-availability.md

sort: 8 weight: 8 title: High Availability menu: docs: parent: "operator" weight: 8 aliases: /operator/high-availability.html High availability is not only important for customer-facing software but if the monitoring infrastructure is not highly available, then there is a risk that operations people are not notified of alerts. Therefore, high availability must be just as thought through for the monitoring stack, as for anything else. VictoriaMetrics operator support high availability for each component of the monitoring stack: More details you can find in the section . VictoriaMetrics operator can be safely scaled horizontally, but only one replica of the operator can process at a time - it uses a leader election mechanism to ensure that only one replica is active at a time. If one of replicas of the operator will be failed, then another replica will be elected as a leader and will continue to work - operator replication affects how quickly this happens. workload is fully distributed among the available operator replicas. In addition, you can safely use for operator such features as (like , , , , etc...) In addition, don't forget about .
Project: M3 (Observability and Analysis / Observability)
File: tracing.md

title: "Tracing" date: 2020-04-21T20:56:40-04:00 draft: true M3DB is integrated with opentracing to provide insight into query performance and errors. To enable Jaeger as the tracing backend, set tracing.backend to "jaeger" (see also our sample local config: tracing: backend: jaeger # enables jaeger with default configs jaeger: ... Jaeger can be run locally with docker as described in https://www.jaegertracing.io/docs/1.9/getting-started/. The default configuration will report traces via udp to localhost:6831; using the all-in-one jaeger container, they will be accessible at http://localhost:16686 N.B.: for production workloads, you will almost certainly want to use sampler.type=remote with adaptive sampling for Jaeger, as write volumes are likely orders of magnitude higher than read volumes in most timeseries systems. To use LightStep as the tracing backend, set tracing.backend to "lightstep" and configure necessary information for your client under lightstep. Any options exposed in lightstep-tracer-go can be set in config. Any environment variables may be interpolated. For example: tracing: serviceName: m3coordinator backend: lightstep lightstep: accesstoken: ${LIGHTSTEPACCESS_TOKEN:""} collector: scheme: https host: my-satellite-address.domain port: 8181 If you'd like additional backends, we'd love to support them! File an issue against M3 and we can work with you on how best to add the backend. The first time's going to be a little rough--opentracing unfortunately doesn't support Go plugins (yet--see https://github.com/opentracing/opentracing-go/issues/133), and glide's update model means that adding dependencies directly will update everything, which isn't ideal for an isolated dependency change. These problems are all solvable though, and we'll work with you to make it happen! Note: all URLs assume a local jaeger setup as described in Jaeger's docs. Finding slow queries To find prom queries longer than , filter for minDuration >= <threshold> on operation="GET /api/v1/query_range". Sample query: http://localhost:16686/search?end=1548876672544000&limit=20&lookback=1h&maxDuration&minDuration=1ms&operation=GET%20%2Fapi%2Fv1%2Fquery_range&service=m3query&start=1548873072544000 Finding queries with errors Search for error=true on operation="GET /api/v1/queryrange" http://localhost:16686/search?operation=GET%20%2Fapi%2Fv1%2Fqueryrange&service=m3query&tags=%7B%22error%22%3A%22true%22%7D Finding 500 (Internal Server Error) responses Search for http.status_code=500. http://localhost:16686/search?limit=20&lookback=24h&maxDuration&minDuration&operation=GET%20%2Fapi%2Fv1%2Fqueryrange&service=m3query&start=1548802430108000&tags=%7B"http.statuscode"%3A"500"%
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-1.3.11.md

Upgrade `netty` from 4.1.91.Final to 4.1.93.Final () Upgrade `spock-core` from 1.3-groovy-2.5 to 2.3-groovy-2.5 () Upgrade `com.google.guava:guava` from 31.0.1-jre to 32.0.1-jre () Upgrade versions of gradle-info-plugin and nebula-publishing-plugin () Upgrade `json-smart` from 2.4.7 to 2.4.11 in plugins/repository-hdfs/ () Upgrade `netty` from 4.1.93.Final to 4.1.94.Final () Fix mapping char_filter when mapping a hashtag () Force nebula plugins to use latest org.bouncycastle:* artifacts ()
Project: SkyWalking (Observability and Analysis / Observability)
File: backend-docker.md

As a quick start, you can use our one-liner script to start ElasticSearch or as the storage, OAP server and Booster UI, please make sure you have installed Docker. Linux, macOS, Windows (WSL) ```shell bash <(curl -sSL https://skywalking.apache.org/quickstart-docker.sh) ``` Windows (Powershell) ```powershell Invoke-Expression ([System.Text.Encoding]::UTF8.GetString((Invoke-WebRequest -Uri https://skywalking.apache.org/quickstart-docker.ps1 -UseBasicParsing).Content)) ``` You will be prompted to choose the storage type, and then the script will start the backend cluster with the selected storage. To tear down the cluster, run the following command: ```shell docker compose --project-name=skywalking-quickstart down ``` ```shell docker run --name oap --restart always -d apache/skywalking-oap-server:9.7.0 ``` ```shell docker run --name oap --restart always -d -e SWSTORAGE=banyandb -e SWSTORAGEBANYANDBTARGETS=banyandb:17912 apache/skywalking-oap-server:9.7.0 ``` ```shell docker run --name oap --restart always -d -e SWSTORAGE=elasticsearch -e SWSTORAGEESCLUSTER_NODES=elasticsearch:9200 apache/skywalking-oap-server:9.7.0 ``` We could set up environment variables to configure this image. They are defined in . If you intend to override or add config files in `/skywalking/config`, `/skywalking/ext-config` is the location for you to put extra files. The files with the same name will be overridden; otherwise, they will be added to `/skywalking/config`. If you want to add more libs/jars into the classpath of OAP, for example, new metrics for OAL. These jars can be mounted into `/skywalking/ext-libs`, then `entrypoint` bash will append them into the classpath. Notice, you can't override an existing jar in classpath.