cwielenb/CNCF-Dataset huggingface dataset:
Project: SkyWalking (Observability and Analysis / Observability)
File: dashboards-so11y-satellite.md

SkyWalking Satellite collects and exports metrics in Prometheus format and SkyWalking metrics service protobuffer format for consuming, it also provides a dashboard to visualize the Satellite metrics. SkyWalking Satellite collects metrics data internally and pushes the metrics to SkyWalking OAP. The SkyWalking OAP Server parses the expression with to filter/calculate/aggregate and store the results. Set up . Config SkyWalking . Self observability monitoring provides monitoring of the status and resources of the OAP server itself. `oap-server` is a `Service` in OAP, and land on the `Layer: SO11Y_OAP`. | Monitoring Panel | Unit | Metric Name | Description | Data Source | |--||--|--|--| | | Count | satelliteservicegrpcconnectcount | Connection Count | SkyWalking Satellite | | | Percentage | satelliteserviceservercpuutilization | CPU (%) | SkyWalking Satellite | | | Count | satelliteservicequeueusedcount | The used count of queue of pipeline | SkyWalking Satellite | | | Count | satelliteservicereceiveeventcount | Receive count of event from downstream | SkyWalking Satellite | | | Count | satelliteservicefetcheventcount | Fetch count of event from downstream | SkyWalking Satellite | | | Count | satelliteservicequeueinputcount | The event count of push to the queue | SkyWalking Satellite | | | Count | satelliteservicesendeventcount | The event count of push data to the upstream | SkyWalking Satellite | You can customize your own metrics/expression/dashboard panel. The self observability dashboard panel configurations are found in `/config/ui-initialized-templates/so11y_satellite/so11y-root.json`.
Project: Elastic (Observability and Analysis / Observability)
File: right.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Return the substring that extracts 'length' chars from 'str' starting from the right. ``` FROM employees | KEEP last_name | EVAL right = RIGHT(last_name, 3) | SORT last_name ASC | LIMIT 5 ```
Project: Pinpoint (Observability and Analysis / Observability)
File: CONTRIBUTING.md

Thank you very much for choosing to share your contribution with us. Please read this page to help us better realize your goals. Feel free to open issues on just about anything related to Pinpoint. These can be anything from bug report to feature proposal. A few points to consider before opening a new issue: Please make sure you've searched through the documentation and existing issues to see if what you're posting has already been addressed. If your build fails, please take a look at to check our current build status. If something is not working, please be as detailed as possible in your description. The more information you provide, the easier it will be for us to provide you with a solution. If something not directly related to Pinpoint is not working (such as HBase), try and see if it's something you can get fixed. Chances are, you might be much better equipped to solve the problem. Even if nothing works, being able to share everything you've tried with us will help resolve the issue a lot quicker. For quick questions, or issues that aren't directly related to the code base, please consider posting them to . Apart from trivial fixes such as typo or formatting, all pull requests should have a corresponding issue associated with them. It is always helpful to know what people are working on, and different (often better) ideas may pop up while discussing them. Please keep these in mind before you create a pull request: Every new java file must have a copy of the license comment. You may copy this from an existing file. Make sure you've tested your code thoroughly. For plugins, please try your best to include integration tests if possible. Before submitting your code, make sure any changes introduced by your code does not break the build, or any tests. Clean up your commit log into logical chunks of work to make it easier for us to figure out what and why you've changed something. (`git rebase -i` helps) Please try best to keep your code updated against the master branch before creating a pull request. Make sure you create the pull request against our master branch. If you've created your own plugin, please take a look at . Please make sure you've signed the before contributing your code. This isn't a copyright - it gives us (Naver) permission to use and redistribute your code as part of the project.
Project: Graylog (Observability and Analysis / Observability)
File: BootstrapModalConfirm.md

```js import createReactClass from 'create-react-class'; import { Button } from 'components/bootstrap'; const BootstrapModalConfirmExample = createReactClass({ getInitialState() { return { showModal: false, confirmed: undefined, }; }, openConfirmation() { this.setState({ showModal: true }); }, onCancel() { this.setState({ confirmed: false, showModal: false }); }, onConfirm(callback) { this.setState({ confirmed: true, showModal: false }); callback(); }, render() { const { confirmed, showModal } = this.state; return ( <div> <p className={confirmed ? 'bg-success' : 'bg-danger'}> {confirmed === undefined ? 'You did not open the confirmation yet' : confirmed ? 'You confirmed the action' : 'You did not confirm the action' } </p> <Button onClick={this.openConfirmation}>Open confirmation</Button> <BootstrapModalConfirm showModal={showModal} title="Confirm this" onConfirm={this.onConfirm} onCancel={this.onCancel}> Are you sure you want to do this? </BootstrapModalConfirm> </div> ); } }); <BootstrapModalConfirmExample /> ```
Project: Grafana Tempo (Observability and Analysis / Observability)
File: cross_tenant_query.md

title: Cross-tenant query federation menuTitle: Cross-tenant query description: Cross-tenant query federation weight: 70 aliases: /docs/tempo/operations/cross-tenant-query {{< admonition type="note" >}} You need to enable `multitenancy_enabled: true` in the cluster for multi-tenant querying to work. Refer to for more details and implications of `multitenancy_enabled: true`. {{% /admonition %}} Tempo supports multi-tenant queries for search, search-tags, and trace-by-ID search operations. To perform multi-tenant queries, send tenant IDs separated by a `|` character in the `X-Scope-OrgID` header, for example, `foo|bar`. By default, cross-tenant query is enabled and can be controlled using `multitenantqueries_enabled` configuration setting. ```yaml query_frontend: multitenantqueries_enabled: true ``` For more information on configuration options, refer to . Queries performed using the cross-tenant configured data source, in either Explore or inside of dashboards, are performed across all the tenants that you specified in the X-Scope-OrgID header. TraceQL queries that compare multiple spansets may not correctly return all traces in a cross-tenant query. For instance, ``` { span.attr1 = "bar" } && { span.attr2 = "foo" } ``` TraceQL evaluates a contiguously stored trace. If these two conditions are satisfied in separate tenants, then Tempo doesn't correctly return the trace.
Project: SkyWalking (Observability and Analysis / Observability)
File: log-otlp.md

SkyWalking can receive logs exported from OpenTelemetry collector, the data flow is: ```mermaid graph LR B[OpenTelemetry SDK 1] C[FluentBit/FluentD, etc.] K[Other sources that OpenTelemetry supports ...] D[OpenTelemetry Collector] E[SkyWalking OAP Server] B --> D C --> D K --> D D -- exporter --> E ``` Recommend to use to forward collected logs to OAP server in OTLP format, and SkyWalking OAP is responsible for transforming the data format into native log format with analysis support powered by . _ Deprecated: unmaintained and not recommended to use, will be removed. was first added into `open-telemetry/opentelemetry-collector-contrib` before OAP OTLP support. It transforms the logs to SkyWalking format before sending them to SkyWalking OAP. Currently, from OTLP community, it is not well maintained, and already being marked as `unmaintained`, and may be removed in 2024. _ By using this exporter, you can send any log data to SkyWalking OAP as long as the data is in OTLP format, no matter where the data is generated. To enable this exporter, make sure the `receiver-otel` is enabled and the `otlp-logs` value is in the `receiver-otel/default/enabledHandlers` configuration section: ```yaml receiver-otel: selector: ${SWOTELRECEIVER:default} default: enabledHandlers: ${SWOTELRECEIVERENABLEDHANDLERS:"otlp-metrics,otlp-logs"} ``` Also, because most of the language SDKs of OpenTelemetry do not support logging feature (yet) or the logging feature is experimental, it's your responsibility to make sure the reported log data contains the following attributes, otherwise SkyWalking is not able to consume them: `service.name`: the name of the service that generates the log data. And several attributes are optional as add-on information for the logs before analyzing. `service.layer`: the layer of the service that generates the logs. The default value is `GENERAL` layer, which is 100% sampled defined by `service.instance`: the instance name that generates the logs. The default value is empty. Note, that these attributes should be set manually through OpenTelemetry SDK or through .
Project: Netdata (Observability and Analysis / Observability)
File: collector.md

Plugin: [[ entry.meta.plugin_name ]] Module: [[ entry.meta.module_name ]] [[ entry.overview.datacollection.metricsdescription ]] [[ entry.overview.datacollection.methoddescription ]] [% if entry.overview.supported_platforms.include %] This collector is only supported on the following platforms: [% for platform in entry.overview.supported_platforms.include %] [[ platform ]] [% endfor %] [% elif entry.overview.supported_platforms.exclude %] This collector is supported on all platforms except for the following platforms: [% for platform in entry.overview.supported_platforms.exclude %] [[ platform ]] [% endfor %] [% else %] This collector is supported on all platforms. [% endif %] [% if entry.overview.multi_instance %] This collector supports collecting metrics from multiple instances of this integration, including remote instances. [% else %] This collector only supports collecting metrics from a single instance of this integration. [% endif %] [% if entry.overview.additional_permissions.description %] [[ entry.overview.additional_permissions.description ]] [% endif %] [% if related %] [[ entry.meta.name ]] can be monitored further using the following other integrations: [% for res in related %] {% relatedResource id="[[ res.id ]]" %}[[ res.name ]]{% /relatedResource %} [% endfor %] [% endif %] [% if entry.overview.defaultbehavior.autodetection.description %] [[ entry.overview.defaultbehavior.autodetection.description ]] [% else %] This integration doesn't support auto-detection. [% endif %] [% if entry.overview.default_behavior.limits.description %] [[ entry.overview.default_behavior.limits.description ]] [% else %] The default configuration for this integration does not impose any limits on data collection. [% endif %] [% if entry.overview.defaultbehavior.performanceimpact.description %] [[ entry.overview.defaultbehavior.performanceimpact.description ]] [% else %] The default configuration for this integration is not expected to impose a significant performance impact on the system. [% endif %]
Project: Netdata (Observability and Analysis / Observability)
File: system.ram.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/integrations/system.ram.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/metadata.yaml" sidebar_label: "system.ram" learn_status: "Published" learnrelpath: "Collecting Metrics/FreeBSD" most_popular: False message: "DO NOT EDIT THIS FILE DIRECTLY, IT IS GENERATED BY THE COLLECTOR'S metadata.yaml FILE" endmeta--> <img src="https://netdata.cloud/img/memory.svg" width="150"/> Plugin: freebsd.plugin Module: system.ram <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Show information about system memory usage. The plugin calls `sysctl` function to collect necessary data. This collector is supported on all platforms. This collector supports collecting metrics from multiple instances of this integration, including remote instances. This integration doesn't support auto-detection. The default configuration for this integration does not impose any limits on data collection. The default configuration for this integration is not expected to impose a significant performance impact on the system. Metrics grouped by scope. The scope defines the instance that the metric belongs to. An instance is uniquely identified by a set of labels. This metric shows RAM usage statistics. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | system.ram | free, active, inactive, wired, cache, laundry, buffers | MiB | | mem.available | avail | MiB | The following alerts are available: | Alert name | On metric | Description | |:|:-|:| | | system.ram | system memory utilization | | | system.ram | system memory utilization | | | mem.available | percentage of estimated amount of RAM available for userspace processes, without causing swapping | | | mem.available | percentage of estimated amount of RAM available for userspace processes, without causing swapping | No action required. The configuration file name for this integration is `netdata.conf`. Configuration for this specific integration is located in the `[plugin:freebsd]` section within that file. The file format is a modified INI syntax. The general structure is: ```ini [section1] option1 = some value option2 = some other value [section2] option3 = some third value ``` You can edit the configuration file using the `edit-config` script from the Netdata . ```bash cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata sudo ./edit-config netdata.conf ``` <details><summary>Config options</summary> | Name | Description | Default | Required | |:-|:--|:-|:--:| | system.ram | Enable or disable system RAM metric. | yes | no | </details> There are no configuration examples.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: monolithic.md

title: Monolithic deployment description: Set up a Tempo deployment in monolithic mode menuTitle: Monolithic deployment weight: 500 aliases: /docs/tempo/operator/monolithic The `TempoMonolithic` Custom Resource (CR) creates a Tempo deployment in . In this mode, a single container has all components of the Tempo deployment, including the compactor, distributor, ingester, querier, and query-frontend. This type of deployment is ideal for small deployments, demo, and test setups, and supports storing traces in memory, in a Persistent Volume and in object storage. {{< admonition type="note" >}} The monolithic deployment of Tempo doesn't scale horizontally. If you require horizontal scaling, use the `TempoStack` CR for a Tempo deployment in . {{< /admonition >}} The following manifest creates a Tempo monolithic deployment with trace ingestion over OTLP/gRPC and OTLP/HTTP, storing traces in a 2 GiB `tmpfs` volume (in-memory storage). ```yaml apiVersion: tempo.grafana.com/v1alpha1 kind: TempoMonolithic metadata: name: sample spec: storage: traces: backend: memory size: 2Gi ``` After the Pod is ready, you can send traces to `tempo-sample:4317` (OTLP/gRPC) and `tempo-sample:4318` (OTLP/HTTP) inside the cluster. To configure a Grafana data source, use the URL `http://tempo-sample:3200` (available inside the cluster). A manifest with all available configuration options is available here: . {{< admonition type="note" >}} This file is auto-generated and does not constitute a valid CR. {{< /admonition >}} It provides an overview of the structure, the available configuration options and help texts.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: enable-service-graphs.md

aliases: /docs/tempo/latest/serversidemetrics/service_graphs/ /docs/tempo/latest/metrics-generator/service_graphs/ title: Enable service graphs description: Learn how to enable service graphs weight: 300 Service graphs are generated in Tempo and pushed to a metrics storage. Then, they can be represented in Grafana as a graph. You will need those components to fully use service graphs. {{< admonition type="note" >}} Cardinality can pose a problem when you have lots of services. To learn more about cardinality and how to perform a dry run of the metrics generator, see the . {{% /admonition %}} To enable service graphs in Tempo/GET, enable the metrics generator and add an overrides section which enables the `service-graphs` generator. For more information, refer to the . To enable service graphs when using Grafana Agent, refer to the . {{< admonition type="note" >}} Since Grafana 9.0.4, service graphs have been enabled by default. Prior to Grafana 9.0.4, service graphs were hidden under the `tempoServiceGraph`. {{% /admonition %}} Configure a Tempo data source's service graphs by linking to the Prometheus backend where metrics are being sent: ``` apiVersion: 1 datasources: name: Prometheus type: prometheus uid: prometheus url: <prometheus-url> jsonData: httpMethod: GET version: 1 name: Tempo type: tempo uid: tempo url: <tempo-url> jsonData: httpMethod: GET serviceMap: datasourceUid: 'prometheus' version: 1 ```
Project: Grafana Mimir (Observability and Analysis / Observability)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: Trickster (Observability and Analysis / Observability)
File: negative-caching.md

Negative Caching means to cache undesired HTTP responses for a very short period of time, in order to prevent overwhelming a system that would otherwise scale normally when desired, cacheable HTTP responses are being returned. For example, Trickster can be configured to cache `404 Not Found` or `500 Internal Server Error` responses for a short period of time, to ensure that a thundering herd of HTTP requests for a non-existent object, or unexpected downtime of a critical service, do not create an i/o bottleneck in your application pipeline. Trickster supports negative caching of any status code >= 300 and < 600, on a per-Backend basis. In your Trickster configuration file, associate the desired Negative Cache Map to the desired Backend config. See the , or refer to the snippet below for more information. The Negative Cache Map must be an all-inclusive list of explicit status codes; there is currently no wildcard or status code range support for Negative Caching entries. By default, the Negative Cache Map is empty for all backend configs. The Negative Cache only applies to Cacheable Objects, and does not apply to Proxy-Only configurations. For any response code handled by the Negative Cache, the response object's effective cache TTL is explicitly overridden to the value of that code's Negative Cache TTL, regardless of any response headers provided by the Backend concerning cacheability. All response headers are left in-tact and unmodified by Trickster's Negative Cache, such that Negative Caching is transparent to the client. The `X-Trickster-Result` response header will indicate a response was served from the Negative Cache by providing a cache status of `nchit`. Multiple negative cache configurations can be defined, and are referenced by name in the backend config. By default, a backend will use the 'default' Negative Cache config, which, by default is empty. The default can be easily populated in the config file, and additional configs can easily be added, as demonstrated below. The format of a negative cache map entry is `'statuscode': ttlin_ms`. ```yaml negative_caches: default: '404': 3000 # cache 404 responses for 3 seconds foo: '404': 3000 '500': 5000 '502': 5000 backends: default: provider: rpc another: provider: rpc negativecachename: foo ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16683.md

key | value | date | 2024-04-17T16:10:14+00:00 version | 2.4.0b1 class | fix edition | cee component | setup level | 1 compatible | no When upgrading from an Enterprise to another edition is performed, the site will start a new trial period, even if licensing credentials had already been configured. To license the product, a license verification needs to be performed (on the licensing page: Setup > Maintenance > Licensing > Online/Offline verification).
Project: Checkmk (Observability and Analysis / Observability)
File: 16403.md

key | value | date | 2024-02-13T10:08:20+00:00 version | 2.4.0b1 class | fix edition | cre component | wato level | 1 compatible | yes A `rulespec` may have an `item_spec` without a title. In changed it so that if this title is missing the the following crash occurs. ``` assert self.rulespec.itemname is not None ``` The occured if one navigates to the parameters via `Parameters for this service` and clicks `Parameters`. It is now fixed.
Project: SkyWalking (Observability and Analysis / Observability)
File: dynamic-config-zookeeper.md

is also supported as a Dynamic Configuration Center (DCC). To use it, please configure it as follows: ```yaml configuration: selector: ${SW_CONFIGURATION:zookeeper} zookeeper: period: ${SWCONFIGZK_PERIOD:60} # Unit seconds, sync period. Default fetch every 60 seconds. namespace: ${SWCONFIGZK_NAMESPACE:/default} hostPort: ${SWCONFIGZKHOSTPORT:localhost:2181} baseSleepTimeMs: ${SWCONFIGZKBASESLEEPTIMEMS:1000} # initial amount of time to wait between retries maxRetries: ${SWCONFIGZKMAXRETRIES:3} # max number of times to retry ``` The namespace is the ZooKeeper path. The config key and value are the properties of the `namespace` folder. ``` znode.path = {namespace}/configKey configValue = znode.data ``` e.g. The config is: ``` {agent-analyzer.default.slowDBAccessThreshold}:{default:200,mongodb:50} ``` If `namespace = /default` the config in zookeeper is: ``` znode.path = /default/agent-analyzer.default.slowDBAccessThreshold znode.data = default:200,mongodb:50 ``` ``` znode.path = {namespace}/configKey znode.child1.path = {znode.path}/subItemkey1 znode.child2.path = {znode.path}/subItemkey2 ... subItemValue1 = znode.child1.data subItemValue2 = znode.child2.data ... ``` e.g. The config is: ``` {core.default.endpoint-name-grouping-openapi}:|{customerAPI-v1}:{value of customerAPI-v1} |{productAPI-v1}:{value of productAPI-v1} |{productAPI-v2}:{value of productAPI-v2} ``` If `namespace = /default` the config in zookeeper is: ``` znode.path = /default/core.default.endpoint-name-grouping-openapi znode.customerAPI-v1.path = /default/core.default.endpoint-name-grouping-openapi/customerAPI-v1 znode.productAPI-v1.path = /default/core.default.endpoint-name-grouping-openapi/productAPI-v1 znode.productAPI-v2.path = /default/core.default.endpoint-name-grouping-openapi/productAPI-v2 znode.customerAPI-v1.data = value of customerAPI-v1 znode.productAPI-v1.data = value of productAPI-v1 znode.productAPI-v2.data = value of productAPI-v2 ```