cwielenb/CNCF-Dataset huggingface dataset:
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_persistentVolume.PersistentVolume.md

title: "Class: PersistentVolume" linkTitle: "PersistentVolume" slug: "libk8spersistentVolume.PersistentVolume" .PersistentVolume `any` `PersistentVolume` new PersistentVolume(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubePersistentVolume\>('persistentVolume').constructor `Static` apiEndpoint: `Object` | Name | Type | | : | : | | `apiInfo` | { `group`: `string` ; `resource`: `string` ; `version`: `string` }[] | | `delete` | (`name`: `string`, `queryParams?`: , `cluster?`: `string`) => `Promise`<`any`\> | | `get` | (`name`: `string`, `cb`: , `errCb`: , `queryParams?`: , `cluster?`: `string`) => `Promise`<() => `void`\> | | `isNamespaced` | `boolean` | | `list` | (`cb`: , `errCb`: , `queryParams?`: , `cluster?`: `string`) => `Promise`<() => `void`\> | | `patch` | (`body`: `OpPatch`, `cluster?`: `string`) => `Promise`<`any`\> | | `post` | (`body`: , `queryParams?`: , `cluster?`: `string`) => `Promise`<`any`\> | | `put` | (`body`: , `queryParams?`: , `cluster?`: `string`) => `Promise`<`any`\> | _ `Static` className: `string` makeKubeObject<KubePersistentVolume\>('persistentVolume').className `get` spec(): `any` `any` _ `get` status(): `any` `any` `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubePersistentVolume\>('persistentVolume').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubePersistentVolume\>('persistentVolume').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubePersistentVolume\>('persistentVolume').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubePersistentVolume\>('persistentVolume').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubePersistentVolume\>('persistentVolume').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubePersistentVolume\>('persistentVolume').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubePersistentVolume\>('persistentVolume').useList
Project: Krkn (Observability and Analysis / Chaos Engineering)
File: container_scenarios.md

Kraken uses the `oc exec` command to `kill` specific containers in a pod. This can be based on the pods namespace or labels. If you know the exact object you want to kill, you can also specify the specific container name or pod name in the scenario yaml file. These scenarios are in a simple yaml format that you can manipulate to run your specific tests or use the pre-existing scenarios to see how it works. The following are the components of Kubernetes for which a basic chaos scenario config exists today. ``` scenarios: name: "<name of scenario>" namespace: "<specific namespace>" # can specify "*" if you want to find in all namespaces label_selector: "<label of pod(s)>" container_name: "<specific container name>" # This is optional, can take out and will kill all containers in all pods found under namespace and label pod_names: # This is optional, can take out and will select all pods with given namespace and label <pod_name> count: <number of containers to disrupt, default=1> action: <kill signal to run. For example 1 ( hang up ) or 9. Default is set to 1> expectedrecoverytime: <number of seconds to wait for container to be running again> (defaults to 120seconds) ``` In all scenarios we do a post chaos check to wait and verify the specific component. Here there are two options: Pass a custom script in the main config scenario list that will run before the chaos and verify the output matches post chaos scenario. See for an example. ``` container_scenarios: # List of chaos pod scenarios to load. - scenarios/container_etcd.yml scenarios/postactionetcd_container.py ``` Allow kraken to wait and check the killed containers until they become ready again. Kraken keeps a list of the specific containers that were killed as well as the namespaces and pods to verify all containers that were affected recover properly. ``` expectedrecoverytime: <seconds to wait for container to recover> ```
Project: Grafana Loki (Observability and Analysis / Observability)
File: user-interface-issue.md

name: User Interface issue about: 'Open UI issues here: https://github.com/grafana/grafana/issues/new' title: '' labels: '' assignees: '' Issues with querying and displaying logs inside Grafana should be opened in the Grafana repo: https://github.com/grafana/grafana/issues/new
Project: Kuberhealthy (Observability and Analysis / Observability)
File: generate-kuberhealthy-crds.md

khstate khcheck khjob From the Kuberhealthy directory run: ```bash ./scripts/generate.sh ``` The exit status 1 error is expected and the CRDS are generated properly despite it. This should generate the three CRD files in the comcast.github.io_khchecks.yaml comcast.github.io_khjobs.yaml comcast.github.io_khstates.yaml
Project: Netdata (Observability and Analysis / Observability)
File: vm.stats.sys.v_swtch.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/integrations/vm.stats.sys.v_swtch.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/metadata.yaml" sidebarlabel: "vm.stats.sys.vswtch" 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/freebsd.svg" width="150"/> Plugin: freebsd.plugin Module: vm.stats.sys.v_swtch <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> CPU context switch 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. The metric count the number of context switches happening on host. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | system.ctxt | switches | context switches/s | | system.forks | started | processes/s | There are no alerts configured by default for this integration. 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 | |:-|:--|:-|:--:| | vm.stats.sys.v_swtch | Enable or disable CPU context switch metric. | yes | no | </details> There are no configuration examples.
Project: Checkmk (Observability and Analysis / Observability)
File: 16148.md

key | value | date | 2024-01-12T06:35:01+00:00 version | 2.3.0b1 class | feature edition | cre component | livestatus level | 1 compatible | yes The hosts and services tables have a new column named `performance_data` that returns a mapping where the keys are the names of metrics and values are the numeric values of the performance data. For example, ``` OMD[heute]:~$ lq << EOF GET services Columns: description performance_data Filter: description = CPU load OutputFormat: python EOF [["CPU load",{"load5":0.64,"load1":0.62,"load15":1.13}]] ```
Project: PowerfulSeal (Observability and Analysis / Chaos Engineering)
File: 3_modes.md

layout: default title: Modes nav_order: 3 description: "" permalink: /modes has_children: true PowerfulSeal works in several modes: mode reads a policy file, that can contain any number of scenarios. It will continuously execute the desired scenarios and produce metrics. This is designed for when you know what kind of failure you'd like to inject into your cluster. mode is designed to allow you to discover your cluster's components and manually break things to see what happens. It has fewer features than the autonomous mode and should be used during the initial phase of planning a chaos experiment. mode allows you to specify which pods to kill with a small number of options by adding `seal/` labels to pods. This is a more imperative alternative to autonomous mode.
Project: Opstrace (Observability and Analysis / Observability)
File: troubleshooting.md

When the Opstrace instance or parts of it appear to not be healthy then debugging should start with getting insights about the underlying Kubernetes cluster and its deployments. <!--tabs--> Make sure use the same `AWSACCESSKEYID` and `AWSSECRETACCESSKEY` that were used for creating the Opstrace instance. Then run ```text aws eks update-kubeconfig --name <clustername> --region <awsregion> ``` For example: ```text aws eks update-kubeconfig --name testcluster --region us-west-2 ``` Make sure `gcloud` is configured for the GCP project under which the Opstrace instance was created. Then run ```text gcloud container clusters get-credentials <clustername> --zone <gcpzone> --project <gcpproject> ``` For example: ```text gcloud container clusters get-credentials testcluster --zone us-west2-a --project vast-pad-13337 ``` <!--/tabs--> When the Opstrace instance or parts of it appear to not be healthy then debugging should start with getting an overview over all Kubernetes deployments and individual container states. This can be obtained with the following command: ```text kubectl describe all --all-namespaces > describe_all.out ``` This will reveal when a certain container is for example in a crash loop, or when it never started in the first place as of for example an error while pulling the corresponding container image. When the Opstrace controller (a deployment running in the Opstrace instance) is suspected to have run into a problem then it is important to fetch and inspect its logs: ```text kubectl logs deployment/opstrace-controller \ --all-containers=true --namespace=kube-system > controller.log ```
Project: Netdata (Observability and Analysis / Observability)
File: elasticsearch_cluster_health_status_yellow.md

The `elasticsearchclusterhealthstatusyellow` alert triggers when the Elasticsearch cluster's health status is `yellow` for longer than 10 minutes. This may indicate potential issues in the cluster, like unassigned or missing replicas. The alert class is `Errors`, and the type is `SearchEngine`. In Elasticsearch, cluster health status can be one of three colors: Green: All primary shards and replicas are active and properly assigned to each index. Yellow: All primary shards are active, but one or more replicas are unassigned or missing. Red: One or more primary shards are unassigned or missing. Check the Elasticsearch cluster health. You can check the health of the Elasticsearch cluster using the `/_cluster/health` API endpoint: ``` curl -XGET 'http://localhost:9200/_cluster/health?pretty' ``` Identify the unassigned or missing replicas. You can check for any unassigned or missing shards using the `/_cat/shards` API endpoint: ``` curl -XGET 'http://localhost:9200/_cat/shards?v&h=index,shard,prirep,state' ``` Check Elasticsearch logs for any errors or warnings: ``` sudo journalctl --unit elasticsearch ``` Check disk space on all Elasticsearch nodes. Insufficient disk space may lead to unassigned or missing replicas: ``` df -h ``` Ensure Elasticsearch is properly configured. Check the `elasticsearch.yml` configuration file on all nodes for any misconfigurations or errors: ``` sudo nano /etc/elasticsearch/elasticsearch.yml ``` Review the Elasticsearch documentation on to understand how to properly assign and balance shards.
Project: Checkmk (Observability and Analysis / Observability)
File: 15321.md

key | value | date | 2024-01-29T12:49:03+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Rule "Status of the Checkmk service" provides a setting called "State if specific check plugins receive no monitoring data" where you can specify a regular expression to match specific check plugins, and assign a status for the "Check_MK" service if this check plugins receives no data. The feature did work correctly if you specified a Status worse than "WARN". But the "Check_MK" service went to "WARN" even if there was an rule to set the status to "OK" if the specific section did not receive any data. This is fixed now.
Project: Grafana Loki (Observability and Analysis / Observability)
File: ip.md

title: Matching IP addresses menuTItle: description: Describes how LogQL supports matching IP addresses. aliases: ../logql/ip/ weight: 40 LogQL supports matching IP addresses. With logs such as ``` 3.180.71.3 - - [17/May/2015:08:05:32 +0000] "GET /downloads/product_1 HTTP/1.1" 304 0 "-" "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.21)" 80.91.33.133 - - [17/May/2015:08:05:14 +0000] "GET /downloads/product_1 HTTP/1.1" 304 0 "-" "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.16)" 46.4.66.76 - - [17/May/2015:08:05:45 +0000] "GET /downloads/product_1 HTTP/1.1" 404 318 "-" "Debian APT-HTTP/1.3 (1.0.1ubuntu2)" 93.180.71.3 - - [17/May/2015:08:05:26 +0000] "GET /downloads/product_1 HTTP/1.1" 404 324 "-" "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.21)" ``` the LogQL line filter is not sufficient. A line filter such as ```logql {job_name="myapp"} |= "3.180.71.3" ``` also matches example IP addresses such as 93.180.71.3. A better choice uses a regexp: `|~"^3.180.71.3"`. This regexp does not handle IPv6 addresses, and it does not match a range of IP addresses. The LogQL support for matching IP addresses handles both IPv4 and IPv6 single addresses, as well as ranges within IP addresses and CIDR patterns. Match IP addresses with the syntax: `ip("<pattern>")`. The `<pattern>` can be: A single IP address. Examples: `ip("192.0.2.0")`, `ip("::1")` A range within the IP address. Examples: `ip("192.168.0.1-192.189.10.12")`, `ip("2001:db8::1-2001:db8::8")` A CIDR specification. Examples: `ip("192.51.100.0/24")`, `ip("2001:db8::/32")` The IP matching can be used in both line filter and label filter expressions. When specifying line filter expressions, only the `|=` and `!=` operations are allowed. When specifying label filter expressions, only the `=` and `!=` operations are allowed. Line filter examples ```logql {job_name="myapp"} |= ip("192.168.4.5/16") ``` Return log lines that do not match with an IPv4 range: ```logql {job_name="myapp"} != ip("192.168.4.5-192.168.4.20") ``` Label filter examples ```logql {job_name="myapp"} | logfmt | remote_addr = ip("2001:db8::1-2001:db8::8") | level = "error" ``` Filters can also be chained. This example matches log lines with all IPv4 subnet values `192.168.4.5/16` except IP address `192.168.4.2`: ```logql {job_name="myapp"} | logfmt | addr = ip("192.168.4.5/16") | addr != ip("192.168.4.2") ``` This example use the conditional `or` and matches log lines with either, all IPv4 subnet values `192.168.4.0/24` OR all IPv4 subnet values `10.10.15.0/24`: ```logql {job_name="myapp"} | logfmt | addr = ip("192.168.4.0/24") or addr = ip("10.10.15.0/24") ```
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_publish_auth_errors.md

This alert is triggered when the Netdata Agent detects a spike in unauthorized MQTT v3/v5 `PUBLISH` attempts in the last minute on your VerneMQ broker. If you receive this alert, it means that there might be clients attempting to publish messages without the proper authentication, which could indicate a misconfiguration or potential security risk. MQTT (Message Queuing Telemetry Transport) is a lightweight, publish-subscribe protocol designed for low-bandwidth, high-latency, or unreliable networks. VerneMQ is a high-performance, distributed MQTT broker that supports a wide range of industry standards and can handle millions of clients. Verify the clients' credentials To check if the clients are using the correct credentials while connecting and publishing to the VerneMQ broker, inspect their log files or debug messages to find authentication-related issues. Review VerneMQ broker configuration Ensure that the VerneMQ configuration allows for proper authentication of clients. Verify that the correct authentication plugins and settings are enabled. The configuration file is usually located at `/etc/vernemq/vernemq.conf`. For more information on VerneMQ config, please refer to . Analyze VerneMQ logs Inspect the VerneMQ logs to identify unauthorized attempts and assess any potential risks. The logs typically reside in the `/var/log/vernemq` directory, and you can tail the logs using the following command: ``` tail -f /var/log/vernemq/console.log ``` Configure firewall rules If you find unauthorized or suspicious IP addresses attempting to connect to your VerneMQ broker, consider blocking those addresses using firewall rules to prevent unauthorized access.
Project: Netdata (Observability and Analysis / Observability)
File: riakkv_kv_get_slow.md

The `riakkvkvget_slow` alert is related to Riak KV, a distributed NoSQL key-value data store. This alert is triggered when the average processing time for GET requests significantly increases in the last 3 minutes compared to the average time over the last hour. If you receive this alert, it means that your Riak KV server is overloaded. Check Riak KV server load: Investigate the current load on your Riak KV server. High CPU, memory, or disk usage can contribute to slow GET request processing times. Use monitoring tools like `top`, `htop`, `vmstat`, or `iotop` to identify any processes consuming excessive resources. Analyze Riak KV logs: Inspect the Riak KV logs for any error messages or warnings that could help identify the cause of the slow GET request processing times. The logs are typically located at `/var/log/riak` or `/var/log/riak_kv`. Look for messages related to timeouts, failures, or high latencies. Monitor Riak KV metrics: Check Riak KV metrics, such as read or write latencies, vnode operations, and disk usage, to identify possible bottlenecks contributing to the slow GET request processing times. Use tools like `riak-admin` or the Riak HTTP API to access these metrics. Optimize query performance: Analyze your application's Riak KV queries to identify any inefficient GET requests that could be contributing to slow processing times. Consider implementing caching mechanisms or adjusting Riak KV settings to improve query performance. Evaluate hardware resources: Ensure that your hardware resources are sufficient to handle the current load on your Riak KV server. If your server has insufficient resources, consider upgrading your hardware or adding additional nodes to your Riak KV cluster.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-12-07-admin_login.md

category: Admin apiurl: '/api/v1/admin/login' title: 'Admin Login' type: 'POST' sample_doc: 'admin.html' layout: default SSO Required `Admin` usage ```{ "name": "test2", }``` ```Status: 200``` ```{ "sig": "9d791331c0ea11e690c5001500c6ca5a", "name": "test2", "admin": false }``` For errors responses, see the .
Project: Kiali (Observability and Analysis / Observability)
File: README-RELEASE.md

To install Istio (including Kiali), use the script `install-ossm-release.sh`. This will utilize the Sail operator and Kiali operator to install the latest released images via OLM using either the public Red Hat repository or public Community repository. Here's what you need to do in order to install everything. First, install a Kubernetes cluster and make sure you do not already have Istio or Kiali installed. (Note: currently non-OpenShift clusters are not supported. When the Sail operator is published on OperatorHub.io, then these scripts should be able to work with minor updates). So for now you need to use OpenShift. Second, if using OpenShift, log into this cluster as a cluster admin user via 'oc'. Otherwise, make sure your current kube context is pointing to your Kubernetes cluster. Now install the required operators: ``` ./install-ossm-release.sh install-operators ``` Once the operators have been given time to start up, now install a control plane with Istio and Kiali: ``` ./install-ossm-release.sh install-istio ``` Pass in `--help` for available options. To uninstall, use the `delete-istio` and `delete-operators` commands to the `./install-ossm-release.sh` script.