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

Krkn recently replaced PowerfulSeal with its own internal pod scenarios using a plugin system. You can run pod scenarios by adding the following config to Krkn: ```yaml kraken: chaos_scenarios: plugin_scenarios: path/to/scenario.yaml ``` You can then create the scenario file with the following contents: ```yaml id: kill-pods config: namespace_pattern: ^kube-system$ label_selector: k8s-app=kube-scheduler krknpodrecovery_time: 120 ``` Please adjust the schema reference to point to the . This file will give you code completion and documentation for the available options in your IDE. The following are the components of Kubernetes/OpenShift for which a basic chaos scenario config exists today. | Component | Description | Working | | |-| -- | | | Kill a pod. | :heavycheckmark: | | | Kills a single/multiple etcd replicas. | :heavycheckmark: | | | Kills a single/multiple kube-apiserver replicas. | :heavycheckmark: | | | Kills a single/multiple apiserver replicas. | :heavycheckmark: | | | Kills a single/multiple prometheus replicas. | :heavycheckmark: | | | Kills random pods running in the OpenShift system namespaces. | :heavycheckmark: |
Project: Trickster (Observability and Analysis / Observability)
File: per-query-instructions.md

Beginning with Trickster v1.1, certain features like Fast Forward can be toggled a per-query basis, to assist with compatibility in your environment. This allows the drafters of a query to have some say over toggling these features on queries they find to have issues running through Trickster. This is done by adding directives via query comments. For example, in Prometheus, you can end any query with `# any comment following a hashtag`, so you can place the per-query instructions there. Instruction `trickster-fast-forward` Supported for: Prometheus (other time series do not currently implement Fast Forward) Usage: `go_goroutines{job="trickster"} # trickster-fast-forward:off` Notes: This can only be used to disable fast forward. A value of `on` will have no effect. Instruction `trickster-backfill-tolerance` Supported for: All time series backends Usage: `SELECT time, count(*) FROM table # trickster-backfill-tolerance:120` Notes: This overrides the backfill tolerance value for this query by the specified value (in seconds). Only integers are accepted.
Project: Botkube (Observability and Analysis / Observability)
File: botkube_telemetry_disable.md

title: botkube telemetry disable Disable Botkube telemetry ``` botkube telemetry disable [flags] ``` ``` botkube telemetry disable ``` ``` -h, --help help for disable ``` ``` -v, --verbose int/string[=simple] Prints more verbose output. Allowed values: 0 - disable, 1 - simple, 2 - trace (default 0 - disable) ``` - Configure collection of anonymous analytics
Project: Elastic (Observability and Analysis / Observability)
File: pow.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Returns the value of `base` raised to the power of `exponent`. ``` ROW base = 2.0, exponent = 2 | EVAL result = POW(base, exponent) ``` Note: It is still possible to overflow a double result here; in that case, null will be returned.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-dashboard_graph_delete.md

category: DashboardGraph apiurl: '/api/v1/dashboard/graph/:id' title: 'Delete a DashboardGraph' type: 'DELETE' sample_doc: 'dashboard.html' layout: default Required ```Status: 200``` ```{"message":"ok"}``` For errors responses, see the .
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: relabel.md

title: Relabel weight: 200 generated_file: true Available in Logging Operator version 4.2 and later. The relabel output uses the to route events back to a specific Flow, where they can be processed again. This is useful, for example, if you need to preprocess a subset of logs differently, but then do the same processing on all messages at the end. In this case, you can create multiple flows for preprocessing based on specific log matchers and then aggregate everything into a single final flow for postprocessing. The value of the `label` parameter of the relabel output must be the same as the value of the `flowLabel` parameter of the Flow (or ClusterFlow) where you want to send the messages. For example: ```yaml apiVersion: logging.banzaicloud.io/v1beta1 kind: ClusterOutput metadata: name: final-relabel spec: relabel: label: '@final-flow' apiVersion: logging.banzaicloud.io/v1beta1 kind: Flow metadata: name: serviceFlow1 namespace: namespace1 spec: filters: [] globalOutputRefs: final-relabel match: select: labels: app: service1 apiVersion: logging.banzaicloud.io/v1beta1 kind: Flow metadata: name: serviceFlow2 namespace: namespace2 spec: filters: [] globalOutputRefs: final-relabel match: select: labels: app: service2 apiVersion: logging.banzaicloud.io/v1beta1 kind: ClusterFlow metadata: name: final-flow spec: flowLabel: '@final-flow' includeLabelInRouter: false filters: [] ``` Using the relabel output also makes it possible to pass the messages emitted by the {{% xref "/docs/configuration/plugins/filters/concat.md" %}} plugin in case of a timeout. Set the `timeout_label` of the concat plugin to the flowLabel of the flow where you want to send the timeout messages. Specifies new label for events
Project: Cortex (Observability and Analysis / Observability)
File: how-to-upgrade-golang-version.md

title: "How to upgrade Golang version" linkTitle: "How to upgrade Golang version" weight: 4 slug: how-to-upgrade-golang-version To upgrade the Go's runtime version: Upgrade build image version with golang version as describe If the minimum support Go's language version should be upgraded as well: Upgrade `go` version in `go.mod`
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: guide-vmcluster-multiple-retention-setup.md

weight: 10 title: Multi Retention Setup within VictoriaMetrics Cluster menu: docs: parent: "guides" weight: 10 aliases: /guides/guide-vmcluster-multiple-retention-setup.html Objective Setup Victoria Metrics Cluster with support of multiple retention periods within one installation. Enterprise Solution supports specifying multiple retentions for distinct sets of time series and via . Open Source Solution Community version of VictoriaMetrics supports only one retention period per `vmstorage` node via command-line flag. A multi-retention setup can be implemented by dividing a into logical groups with different retentions. Example: Setup should handle 3 different retention groups 3months, 1year and 3 years. Solution contains 3 groups of vmstorages + vminserts and one group of vmselects. Routing is done by by . The sets how long to keep the metrics. The diagram below shows a proposed solution <img src="guide-vmcluster-multiple-retention-setup.webp"> Implementation Details Groups of vminserts A know about only vmstorages A and this is explicitly specified via `-storageNode` . Groups of vminserts B know about only vmstorages B and this is explicitly specified via `-storageNode` . Groups of vminserts C know about only vmstorages A and this is explicitly specified via `-storageNode` . vmselect reads data from all vmstorage nodes via `-storageNode` with setting equal to vmagent's scrape interval or minimum interval between collected samples. vmagent routes incoming metrics to the given set of `vminsert` nodes using relabeling rules specified at `-remoteWrite.urlRelabelConfig` . Multi-Tenant Setup Every group of vmstorages can handle one tenant or multiple one. Different groups can have overlapping tenants. As vmselect reads from all vmstorage nodes, the data is aggregated on its level. Additional Enhancements You can set up for routing data to the given vminsert group depending on the needed retention.
Project: Checkmk (Observability and Analysis / Observability)
File: 16385.md

key | value | date | 2024-01-17T11:41:59+00:00 version | 2.3.0b1 class | fix edition | cre component | wato level | 1 compatible | yes Changes made by the checkmk internal user can now only be reverted when the logged-in user has the permission "Discard foreign changes".
Project: PowerfulSeal (Observability and Analysis / Chaos Engineering)
File: crd.md

layout: default title: Kubernetes Custom Resources nav_order: 2 description: "" permalink: /crd parent: Setup {: .no_toc } {: .no_toc .text-delta } TOC {:toc} `Powerfulseal` can be deployed on Kubernetes cluster to perform random chaos the application services. It also allows teams to define scenarios in their own namespace using . Powerfulseal adds all CRD-defined scenarios to the ones defined in the policy configuration file (optional). Scenarios are reloaded after the execution of the current run. Apply the rbac.yml (choose the appropriate namespace) to setup a service account with sufficient privileges `kubectl apply -f kubernetes/rbac.yml` Deploy powerfulseal `kubectl apply -f kubernetes/powerfulseal.yml` Create the Custom Resource Definition `kubectl apply -f kubernetes/crd.yml` An example scenario is provided. This creates a sandbox namespace with 2 nginx replicas and ensures their resilience `kubectl apply -f kubernetes/sandbox.yml` `kubectl apply -f kubernetes/sandbox_scenario.yml`
Project: Elastic (Observability and Analysis / Observability)
File: replace.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> The function substitutes in the string `str` any match of the regular expression `regex` with the replacement string `newStr`. ``` ROW str = "Hello World" | EVAL str = REPLACE(str, "World", "Universe") | KEEP str ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16236.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-02-21T13:17:42+00:00 level | 1 class | fix component | checks edition | cre This regression exists since 2.2.0b1. Monitoring mails in your in box may have not been possible. This is fixed now.
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: google_cloud_storage.md

sidebar_position: 5 The will use the and to access your flag in Google Cloud Storage. ```go err := ffclient.Init(ffclient.Config{ PollingInterval: 3 * time.Second, Retriever: &gcstorageretriever.Retriever{ Options: []option.ClientOption{option.WithoutAuthentication()}, Bucket: "2093u4pkasjc3", Object: "flags.yaml", } }) defer ffclient.Close() ``` To configure your Google Cloud Storage file location: | Field | Description | |--|--| | `Bucket` | The name of your bucket. | | `Object` | The name of your object in your bucket. | | `Option` | An instance of `option.ClientOption` that configures your access to Google Cloud. <br/> Check . |
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: _index.md

title: Profiling and tracing integration menuTitle: Profiling and tracing description: Learning about how profiling and tracing work together. weight: 50 aliases: ../introduction/traces-to-profiles/ ../introduction/profile-tracing/ keywords: pyroscope continuous profiling tracing {{< docs/shared source="grafana" lookup="datasources/pyroscope-profile-tracing-intro.md" version="<GRAFANA VERSION>" >}}
Project: Checkmk (Observability and Analysis / Observability)
File: 16376.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-01-23T14:05:03+00:00 level | 1 class | fix component | checks edition | cre This fixes disappearing hosts in case of temporarily missing data around the time when a cleanup background job is run (around midnight). In case a piggybacked host temporarily did not receive any data while the background (cron) job <code>cmk --cleanup-piggyback</code> was executed, a subsequent run of the DCD would not respect the "Validity of missing data" setting, wrongly removing the affected host from the monitoring configuration.
Project: Netdata (Observability and Analysis / Observability)
File: inter_process_communication.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/integrations/interprocesscommunication.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/metadata.yaml" sidebar_label: "Inter Process Communication" learn_status: "Published" learnrelpath: "Collecting Metrics/Linux Systems/IPC" 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/network-wired.svg" width="150"/> Plugin: proc.plugin Module: ipc <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> IPC stands for Inter-Process Communication. It is a mechanism which allows processes to communicate with each other and synchronize their actions. This collector exposes information about: Message Queues: This allows messages to be exchanged between processes. It's a more flexible method that allows messages to be placed onto a queue and read at a later time. Shared Memory: This method allows for the fastest form of IPC because processes can exchange data by reading/writing into shared memory segments. Semaphores: They are used to synchronize the operations performed by independent processes. So, if multiple processes are trying to access a single shared resource, semaphores can ensure that only one process accesses the resource at a given time. This collector is supported on all platforms. This collector only supports collecting metrics from a single instance of this integration. 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 scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | system.ipc_semaphores | semaphores | semaphores | | system.ipcsemaphorearrays | arrays | arrays | | system.messagequeuemessage | a dimension per queue | messages | | system.messagequeuebytes | a dimension per queue | bytes | | system.sharedmemorysegments | segments | segments | | system.sharedmemorybytes | bytes | bytes | The following alerts are available: | Alert name | On metric | Description | |:|:-|:| | | system.ipc_semaphores | IPC semaphore utilization | | | system.ipcsemaphorearrays | IPC semaphore arrays utilization | No action required. There is no configuration file. There are no configuration options. There are no configuration examples.
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-1.2.1.md

Upgrade to log4j 2.15.0 (#1704) Fri, 10 Dec 2021 18:05:14 -0500 Signed-off-by: Andrew Ross &lt;andrross@amazon.com&gt; Increment version to 1.2.1 (#1700) Fri, 10 Dec 2021 14:06:17 -0500 Increment version to 1.2.1. Signed-off-by: dblock &lt;dblock@dblock.org&gt; Move Gradle wrapper and precommit checks into OpenSearch repo. (#1664) Move Gradle checks into OpenSearch repo. Signed-off-by: dblock &lt;dblock@amazon.com&gt; Use working-directory for gradle wrapper validation. Signed-off-by: dblock &lt;dblock@amazon.com&gt; Use https://github.com/gradle/wrapper-validation-action. Signed-off-by: dblock &lt;dblock@amazon.com&gt; Use Java 14. Signed-off-by: dblock &lt;dblock@dblock.org&gt;
Project: Netdata (Observability and Analysis / Observability)
File: postgres_table_last_autovacuum_time.md

This alert is related to the PostgreSQL database and checks the time since the last autovacuum operation occurred on a specific table. If you receive this alert, it means that the table has not been vacuumed by the autovacuum daemon for more than a week (7 days). Autovacuum is a feature in PostgreSQL that automates the maintenance of the database by reclaiming storage, optimizing the performance of the database, and updating statistics. It operates on individual tables and performs the following tasks: Reclaims storage occupied by dead rows and updates the Free Space Map. Optimizes the performance by updating statistics and executing the `ANALYZE` command. Removes dead rows and updates the visibility map in order to reduce the need for vacuuming. Check the autovacuum status To check if the autovacuum daemon is running for the PostgreSQL instance, run the following SQL command: ``` SHOW autovacuum; ``` If the result is "off", then the autovacuum is disabled for the PostgreSQL instance. You can enable it by modifying the `postgresql.conf` configuration file and setting `autovacuum = on`. Verify table-specific autovacuum settings Sometimes, autovacuum settings might be altered for individual tables. To check the autovacuum settings for the specific table mentioned in the alert, run the following SQL command: ``` SELECT relname, reloptions FROM pgclass JOIN pgnamespace ON pgnamespace.oid = pgclass.relnamespace WHERE relname = '<tablename>' AND nspname = '<schemaname>'; ``` Look for any custom `autovacuum_*` settings in the `reloptions` column and adjust them accordingly to allow the autovacuum daemon to run on the table. Monitor the PostgreSQL logs Inspect the PostgreSQL logs for any error messages or unusual behavior related to autovacuum. The log file location depends on your PostgreSQL installation and configuration. Manually vacuum the table If the autovacuum daemon has not run for a long time on the table, you can manually vacuum the table to reclaim storage and update statistics. To perform a manual vacuum, run the following SQL command: ``` VACUUM (VERBOSE, ANALYZE) <schemaname>.<tablename>; ```
Project: Grafana Loki (Observability and Analysis / Observability)
File: json.md

title: json menuTitle: description: The 'json' Promtail pipeline stage. aliases: ../../../clients/promtail/stages/json/ weight: The `json` stage is a parsing stage that reads the log line as JSON and accepts expressions to extract data. ```yaml json: expressions: [ <string>: <string> ... ] [source: <string>] [drop_malformed: <bool> | default = false] ``` This stage uses the Go JSON unmarshaler, which means non-string types like numbers or booleans will be unmarshaled into those types. The extracted data can hold non-string values and this stage does not do any type conversions; downstream stages will need to perform correct type conversion of these values as necessary. Please refer to the for how to do this. If the value extracted is a complex type, such as an array or a JSON object, it will be converted back into a JSON string before being inserted into the extracted data. For the given pipeline: ```yaml json: expressions: output: log stream: stream timestamp: time ``` Given the following log line: ``` {"log":"log message\n","stream":"stderr","time":"2019-04-30T02:12:41.8443515Z"} ``` The following key-value pairs would be created in the set of extracted data: `output`: `log message\n` `stream`: `stderr` `timestamp`: `2019-04-30T02:12:41.8443515` For the given pipeline: ```yaml json: expressions: output: log stream: stream timestamp: time extra: json: expressions: user: source: extra ``` And the given log line: ``` {"log":"log message\n","stream":"stderr","time":"2019-04-30T02:12:41.8443515Z","extra":"{\"user\":\"marco\"}"} ``` The first stage would create the following key-value pairs in the set of extracted data: `output`: `log message\n` `stream`: `stderr` `timestamp`: `2019-04-30T02:12:41.8443515` `extra`: `{"user": "marco"}` The second stage will parse the value of `extra` from the extracted data as JSON and append the following key-value pairs to the set of extracted data: `user`: `marco` This pipeline uses a literal JMESPath expression to parse JSON fields with special characters in the name, like `@` or `.` For the given pipeline: ```yaml json: expressions: output: log stream: '"grpc.stream"' timestamp: time ``` Given the following log line: ``` {"log":"log message\n","grpc.stream":"stderr","time":"2019-04-30T02:12:41.8443515Z"} ``` The following key-value pairs would be created in the set of extracted data: `output`: `log message\n` `stream`: `stderr` `timestamp`: `2019-04-30T02:12:41.8443515` {{% admonition type="note" %}} Referring to `grpc.stream` without the combination of double quotes wrapped in single quotes will not work properly. {{% /admonition %}}
Project: Botkube (Observability and Analysis / Observability)
File: 2019-02-20-multi-cluster.md

| Status | || | `IMPLEMENTED` | `@botkube` commands refer to all the commands in the slack bot which currently supports: kubectl notifier ping Add Multi-cluster support for Botkube, where a single bot can monitor multiple clusters and respond to `@botkube` commands with cluster specific results. Currently in multi-cluster scenario, a Slack bot authenticates all the clusters with a same authentication token. Thus running `@botkube` command returns response from all the configured clusters, irrespective of the slack channel or group. For `@botkube` command execution, we need a particular cluster specific output. This design approach adds a flag `--cluster-name` to all `@botkube` commands. Use of that flag is optional in a cluster specific channel. Botkube `Notifier` commands are restricted to a dedicated channel for a cluster only and `--cluster-name` flag is ignored. Botkube `ping` command with the `--cluster-name` flag returns `pong` response from the cluster specified in the flag, else you get response from all the clusters. `Ping` command without --cluster-name flag can be used to list all the configured clusters in the slack bot and identify you cluster's name among them. For `kubectl` commands in a dedicated channel to a cluster, if `--cluster-name` flag is used, it responds with the output for the cluster specified in flag, else it checks if the channel in the request matches the `config.Communications.Slack.Channel` and responds if true else ignores. For `kubectl` commands in a group, Direct message or channel not dedicated to any cluster, the `--cluster-name` flag is mandatory. The executor checks if the `--cluster-name` flag is present in the request. If yes, it gets the cluster's name from the flag and compares with `c.Settings.ClusterName` from the config file, if it matches then it responds with the required output to the slack bot and if it doesn't match, it ignores the request. And if the `--cluster-name` flag is absent for `kubectl` commands, it responds to the slack bot saying 'Please specify the cluster-name'. For example - ```sh @Botkube get pods --cluster-name={CLUSTER_NAME} ``` where, `CLUSTER_NAME` is the name of the cluster you want to query. To get the list of all clusters configured in the slack, you can run the following command in slack. ```sh @Botkube ping ``` The `--cluster-name` flag is mandated for kubectl and notifier commands resulting additional overhead. We can add channel specific authentication token or completely dedicate a channel to a particular cluster which requires changes in the slack code.
Project: Checkmk (Observability and Analysis / Observability)
File: 14222.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-01-31T09:55:00+00:00 level | 1 class | feature component | bi edition | cre This werk only introduces a visual fix, so no functional changes. The order of the dropdown choice elements did not reflect the severity of the states. The correct severity order for the BI is OK->WARN->UNKNOWN->CRIT, which differs from the order of the monitoring states OK->WARN->CRIT->UNKNOWN.
Project: Vector (Observability and Analysis / Observability)
File: roles.md

title: Deployment roles short: Roles weight: 1 show_toc: true aliases: ["/docs/setup/deployment/strategies"] Vector is an end-to-end data pipeline designed to collect, process, and route data. This means that Vector serves all roles in building your pipeline. You can deploy it as an , , or . You combine these roles to form [topologies]. In this section, we'll cover each role in detail and help you understand when to use each. {{< roles >}} You can install the Vector as an Aggregator on Kubernetes using Helm. For more information about getting started with the Aggregator role, see the .