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

title: "Interface: KubeLimitRange" linkTitle: "KubeLimitRange" slug: "libk8slimitRange.KubeLimitRange" .KubeLimitRange `KubeLimitRange` `Optional` apiVersion: `string` . _ kind: `string` Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. In CamelCase. Cannot be updated. `see` . _ metadata: . _ spec:
Project: Checkmk (Observability and Analysis / Observability)
File: 16340.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-03-06T16:28:34+00:00 level | 1 class | fix component | checks edition | cre In newer versions of the Docker API the information about the 'VirtualSize' of a node image is not available, because it has been deprecated. From now on the plugin will use 'VirtualSize' if available, and 'Size' if not.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-hostgroup_template_unbind.md

category: HostGroup apiurl: '/api/v1/hostgroup/template' title: "Unbind A Template of A HostGroup" type: 'PUT' sample_doc: 'hostgroup.html' layout: default Required ```{ "tpl_id": 5, "grp_id": 3 }``` ```Status: 200``` ```{"message":"template: 5 is unbind of HostGroup: 3"}```
Project: Netdata (Observability and Analysis / Observability)
File: setup.md

[% if entry.setup.description %] [[ entry.setup.description ]] [% else %] [% if entry.setup.prerequisites.list %] [% for prereq in entry.setup.prerequisites.list %] [[ prereq.description ]] [% endfor %] [% else %] No action required. [% endif %] [% if entry.setup.configuration.file.name %] The configuration file name for this integration is `[[ entry.setup.configuration.file.name ]]`. [% if 'section_name' in entry.setup.configuration.file %] Configuration for this specific integration is located in the `[[ entry.setup.configuration.file.section_name ]]` section within that file. [% endif %] [% if entry.plugin_name == 'go.d.plugin' %] [% include 'setup/sample-go-config.md' %] [% elif entry.plugin_name == 'python.d.plugin' %] [% include 'setup/sample-python-config.md' %] [% elif entry.plugin_name == 'charts.d.plugin' %] [% include 'setup/sample-charts-config.md' %] [% elif entry.plugin_name == 'ioping.plugin' %] [% include 'setup/sample-charts-config.md' %] [% elif entry.plugin_name == 'apps.plugin' %] [% include 'setup/sample-apps-config.md' %] [% elif entry.plugin_name == 'ebpf.plugin' %] [% include 'setup/sample-netdata-config.md' %] [% elif entry.setup.configuration.file.name == 'netdata.conf' %] [% include 'setup/sample-netdata-config.md' %] [% endif %] 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 [[ entry.setup.configuration.file.name ]] ``` [% else %] There is no configuration file. [% endif %] [[ entry.setup.configuration.options.description ]] [% if entry.setup.configuration.options.list %] [% if entry.setup.configuration.options.folding.enabled and not clean %] {% details summary="[[ entry.setup.configuration.options.folding.title ]]" %} [% endif %] | Name | Description | Default | Required | |:-|:--|:-|:--:| [% for item in entry.setup.configuration.options.list %] | [[ strfy(item.name) ]] | [[ strfy(item.description) ]] | [[ strfy(item.default_value) ]] | [[ strfy(item.required) ]] | [% endfor %] [% for item in entry.setup.configuration.options.list %] [% if 'detailed_description' in item %] [[ item.detailed_description ]] [% endif %] [% endfor %] [% if entry.setup.configuration.options.folding.enabled and not clean %] {% /details %} [% endif %] [% elif not entry.setup.configuration.options.description %] There are no configuration options. [% endif %] [% if entry.setup.configuration.examples.list %] [% for example in entry.setup.configuration.examples.list %] [[ example.description ]] [% if example.folding.enabled and not clean %] {% details summary="[[ entry.setup.configuration.examples.folding.title ]]" %} [% endif %] ```yaml [[ example.config ]] ``` [% if example.folding.enabled and not clean %] {% /details %} [% endif %] [% endfor %] [% else%] There are no configuration examples. [% endif %] [% endif %]
Project: Botkube (Observability and Analysis / Observability)
File: bug_report.md

name: Bug about: Report a bug in the project labels: bug <!-- Thank you for your contribution. Before you submit the issue: Search open and closed issues for duplicates. Read the contributing guidelines (CONTRIBUTING.md file on root of the repository). --> <!-- Provide a clear and concise description of the problem. Describe where it appears, when it occurred, and what it affects. Provide all relevant technical details such as the Botkube version. --> <!-- Describe what you expect to happen. --> <!-- Describe what happens instead. --> <!-- Steps to reproduce the issue. Attach all resources that can help us understand the bug, such as screenshots, links or files. -->
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: ci&t.md

CI&T is an information technology and software engineering company. CI&T operates as a global systems integrator headquartered in the Brazilian city of Campinas with offices in other regions of South America, United States, Europe, and Asia. After an evaluation period of some Chaos Engineering tools, we chose Litmus because it is a more mature tool that would meet most of our needs. We are in the implementation, configuration, and process definition phase. AB-Inbev's BEES is a huge project that has hundreds of microservices, it has been a great challenge to adapt Litmus in this process, making customizations and counting on the help of the Litmus community to evolve the tool and thus achieve our goal of making it available to the teams. Some points that made us choose Litmus: Based on K8S resources SSO Customization of attacks, attacks in parallel Installation on multiple clusters GitOps
Project: Prometheus (Observability and Analysis / Observability)
File: unit_testing_rules.md

title: Unit Testing for Rules sort_rank: 6 You can use `promtool` to test your rules. ```shell ./promtool test rules test.yml ./promtool test rules test1.yml test2.yml test3.yml ``` ```yaml rule_files: [ - <file_name> ] [ evaluation_interval: <duration> | default = 1m ] groupevalorder: [ - <group_name> ] tests: [ - <test_group> ] ``` ``` yaml [ interval: <duration> | default = evaluation_interval ] input_series: [ - <series> ] [ name: <string> ] alertruletest: [ - <alerttestcase> ] promqlexprtest: [ - <promqltestcase> ] external_labels: [ <labelname>: <string> ... ] [ external_url: <string> ] ``` ```yaml series: <string> values: <string> ``` Prometheus allows you to have same alertname for different alerting rules. Hence in this unit testing, you have to list the union of all the firing alerts for the alertname under a single `<alerttestcase>`. ``` yaml eval_time: <duration> alertname: <string> exp_alerts: [ - <alert> ] ``` ``` yaml exp_labels: [ <labelname>: <string> ] exp_annotations: [ <labelname>: <string> ] ``` ```yaml expr: <string> eval_time: <duration> exp_samples: [ - <sample> ] ``` ```yaml labels: <string> value: <number> ``` This is an example input file for unit testing which passes the test. `test.yml` is the test file which follows the syntax above and `alerts.yml` contains the alerting rules. With `alerts.yml` in the same directory, run `./promtool test rules test.yml`. ```yaml rule_files: alerts.yml evaluation_interval: 1m tests: interval: 1m input_series: series: 'up{job="prometheus", instance="localhost:9090"}' values: '0 0 0 0 0 0 0 0 0 0 0 0 0 0 0' series: 'up{job="node_exporter", instance="localhost:9100"}' values: '1+0x6 0 0 0 0 0 0 0 0' # 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 series: 'go_goroutines{job="prometheus", instance="localhost:9090"}' values: '10+10x2 30+20x5' # 10 20 30 30 50 70 90 110 130 series: 'gogoroutines{job="nodeexporter", instance="localhost:9100"}' values: '10+10x7 10+30x4' # 10 20 30 40 50 60 70 80 10 40 70 100 130 alertruletest: eval_time: 10m alertname: InstanceDown exp_alerts: exp_labels: severity: page instance: localhost:9090 job: prometheus exp_annotations: summary: "Instance localhost:9090 down" description: "localhost:9090 of job prometheus has been down for more than 5 minutes." promqlexprtest: expr: go_goroutines > 5 eval_time: 4m exp_samples: labels: 'go_goroutines{job="prometheus",instance="localhost:9090"}' value: 50 labels: 'gogoroutines{job="nodeexporter",instance="localhost:9100"}' value: 50 ``` ```yaml groups: name: example rules: alert: InstanceDown expr: up == 0 for: 5m labels: severity: page annotations: summary: "Instance {{ $labels.instance }} down" description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes." alert: AnotherInstanceDown expr: up == 0 for: 10m labels: severity: page annotations: summary: "Instance {{ $labels.instance }} down" description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes." ```
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_persistentVolumeClaim.PersistentVolumeClaim.md

title: "Class: PersistentVolumeClaim" linkTitle: "PersistentVolumeClaim" slug: "libk8spersistentVolumeClaim.PersistentVolumeClaim" .PersistentVolumeClaim `any` `PersistentVolumeClaim` new PersistentVolumeClaim(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubePersistentVolumeClaim\>( 'persistentVolumeClaim' ).constructor `Static` apiEndpoint: `Object` | Name | Type | | : | : | | `scale?` | { `get`: (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> ; `put`: (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> } | | `scale.get` | (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> | | `scale.put` | (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> | _ `Static` className: `string` makeKubeObject<KubePersistentVolumeClaim\>( 'persistentVolumeClaim' ).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<KubePersistentVolumeClaim\>( 'persistentVolumeClaim' ).apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubePersistentVolumeClaim\>( 'persistentVolumeClaim' ).getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubePersistentVolumeClaim\>( 'persistentVolumeClaim' ).getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubePersistentVolumeClaim\>( 'persistentVolumeClaim' ).useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubePersistentVolumeClaim\>( 'persistentVolumeClaim' ).useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubePersistentVolumeClaim\>( 'persistentVolumeClaim' ).useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubePersistentVolumeClaim\>( 'persistentVolumeClaim' ).useList
Project: Netdata (Observability and Analysis / Observability)
File: cockroachdb_underreplicated_ranges.md

This alert is related to CockroachDB, a scalable and distributed SQL database. When you receive this alert, it means that there are under-replicated ranges in your database cluster. Under-replicated ranges can impact the availability and fault tolerance of your database, leading to potential data loss or unavailability in case of node failures. In a CockroachDB cluster, data is split into small chunks called ranges. These ranges are then replicated across multiple nodes to ensure fault tolerance and high availability. The desired replication factor determines the number of replicas for each range. When a range has fewer replicas than the desired replication factor, it is considered as "under-replicated". This situation can occur if nodes are unavailable or if the cluster is in the process of recovering from failures. Access the CockroachDB Admin UI Access the Admin UI by navigating to the URL `http://<any-node-ip>:8080` on any of your cluster nodes. Check the 'Replication Status' in the dashboard In the Admin UI, check the 'Under-replicated Ranges' metric on the main 'Dashboard' or 'Metrics' page. Inspect the logs of your CockroachDB nodes Look for any error messages or issues that could be causing under-replication. For example, you may see errors related to node failures or network issues. Check cluster health and capacity Make sure that all nodes in the cluster are running and healthy. You can do this by running the command `cockroach node status`. Consider adding more nodes or increasing the capacity if your nodes are overworked. Verify replication factor configuration Check your cluster's replication factor configuration to ensure it is set to an appropriate value. The default replication factor is 3, which can tolerate one failure. You can view and change it using the . Consider decommissioning problematic nodes If specific nodes are causing under-replication, consider decommissioning them to allow the cluster to automatically rebalance the ranges. Follow the in the CockroachDB documentation.
Project: Grafana (Observability and Analysis / Observability)
File: triage-issues.md

Triage helps ensure that issues resolve quickly by: Ensuring the issue's intent and purpose is conveyed precisely. This is necessary because it can be difficult for an issue to explain how an end user experiences a problem and what actions they took. Giving a contributor the information they need before they commit to resolving an issue. Lowering the issue count by preventing duplicate issues. Streamlining the development process by preventing duplicate discussions. This document gives you some ideas on what you can do to help. For more information, read more about . Improve issues by suggesting improvements to the title and description. If you think an issue has formatting issues, bad language, or grammatical errors, post a comment to let the author and maintainers know. If you think an issue has been resolved, or is no longer relevant, suggest us to close it. Add a comment on the issue, where you explain the reason it should be closed. Make sure to include any related issues and pull requests. Investigate issues that we haven't been able to reproduce yet. In some cases, there are many combinations of panels, dashboards, and data sources that make it difficult for us to reproduce certain issues. Help us by adding more information. Use to let us know what's important to you. Vote on bugs if you've experienced the same problem. Don't vote, or react, by commenting on the issue. Read more about . If you find two issues that describe the same thing, add a comment in one of the issues, with a reference (`#<issue number>`) to the other. Explain why you think the issue is duplicated.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: transport.md

title: Transport weight: 200 generated_file: true Specify private CA contained path Specify path to CA certificate file private CA private key passphrase contained path private CA private key contained path Specify path to Certificate file Ciphers Default: "ALL:!aNULL:!eNULL:!SSLv2" When this is set Fluentd will check all incoming HTTPS requests for a client certificate signed by the trusted CA, requests that don't supply a valid client certificate will fail. Use secure connection when use tls) Default: false public CA private key passphrase contained path Specify path to private Key file Protocol Default: :tcp Version Default: 'TLSv1_2'
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: clusterflow_types.md

title: ClusterFlow weight: 200 generated_file: true ClusterFlow is the Schema for the clusterflows API Name of the logging cluster to be attached ClusterFlowSpec is the Kubernetes spec for ClusterFlows Deprecated Deprecated ClusterFlowList contains a list of ClusterFlow
Project: M3 (Observability and Analysis / Observability)
File: m3coordinator_admin.md

title: "Running M3 Coordinator in Admin mode" Sometimes it is useful to run M3 Coordinator in "admin mode". Usually it is enough o have a single dedicated instance that is used to perform various administration tasks: M3DB placement management M3 Aggregator placement management Namespace operations To run M3 Coordinator in admin mode simply start it with `noop-etcd` backend: ```yaml backend: noop-etcd ``` Usually for production clusters we run external Etcd. Set it up under `clusterManagement` configuration key. Final configuration might look as follows: ```yaml listenAddress: 0.0.0.0:7201 metrics: scope: prefix: "coordinator-admin" prometheus: handlerPath: /metrics listenAddress: 0.0.0.0:3030 sanitization: prometheus samplingRate: 1.0 backend: noop-etcd clusterManagement: etcd: env: default_env zone: embedded service: m3db cacheDir: /var/lib/m3kv etcdClusters: zone: embedded endpoints: etcd01:2379 ```
Project: Vector (Observability and Analysis / Observability)
File: 2023-01-17-0-27-0-upgrade-guide.md

date: "2023-01-17" title: "0.27 Upgrade Guide" description: "An upgrade guide that addresses breaking changes in 0.27.0" authors: ["spencergilbert", "neuronull"] release: "0.27.0" hideonrelease_notes: false badges: type: breaking change Vector's 0.27.0 release includes breaking changes: and potentially impactful changes: and deprecations: We cover them below to help you upgrade quickly: Prior to this release, the `statsd` source parsed incoming empty tags (tags with a key but no value), as having a boolean value "true". For example, in the tagset "atag,btag:bvalue" , the tag "atag" would be parsed to a value of "true". With this release, that behavior is now changed and the `statsd` source parses empty tags as empty tags. Similarly, prior to this release, the `statsd` sink encoded metric tags with a boolean value of "true", to being an empty tag. With this release, the `statsd` sink now correctly encodes a value of "true" to "true", and empty tags as empty tags. Prior to this release, the `datadog_agent` source parsed incoming empty tags (tags with a key but no value) as empty strings. With this release, empty tags are properly parsed as empty tags. The `native` and `native_json` codecs have been modified to include support for enhanced tags (bare tags or multi-valued tags) on metrics by optionally encoding tag values as arrays of values. This will cause Vector, when using these codecs and a metric source or transform that generates enhanced tags, to emit metrics that are not backwards compatible with previous versions. Vector can continue to load in events emitted by older versions. This has two potential implications that you should consider: Disk buffers should be backed up if you want to be able to roll back to an older Vector version since new disk buffer entries may not be readable by older Vector versions. The disk buffers location can be found under the . When upgrading Vector to Vector communication using the `vector` source and sink or the `native` or `native_json` codecs, make sure you upgrade the consumers first followed by the producers to ensure newer versions of Vector aren't sending data to older versions, which may not be able to be read. Before this release, the `awscloudwatchmetrics` sink would only send up to ten tags to AWS as metric dimensions. This limit has been increased to thirty based on the . This could increase the cardinality of your metrics by including previously dropped tags. The following VRL program would allow you to drop tags when there are more than ten, maintaining the original behavior. ```coffeescript count = 10 tags = {} for_each(object!(.tags)) ->|key, value| { if count > 0 { count = count - 1 tags = set!(tags, [key], value) } } .tags = tags ``` Before this release, the `awskinesisfirehose` source would only allow matching against single configured access keys. Now multiple access keys can be configured via `access_keys` configuration option. For now, both `accesskey` and `accesskeys` are supported, via merging them to the single output parameter. Afterwards, only `access_keys` will be supported.
Project: Vector (Observability and Analysis / Observability)
File: advice.md

<!-- See https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-advice --> <!-- markdownlint-disable MD033 MD041 --> <details><summary>If flagged items are :speaking_head: proper nouns</summary> You can add them to `allow.txt`. If they could be written in `lowercase`, feel free to add them in `lowercase` instead of `Initial` or `UPPERCASE`. </details> <details><summary>If flagged items are :exploding_head: false positives</summary> If items relate to a ... binary file (or some other file you wouldn't want to check at all). Please add a file path to the `excludes.txt` file matching the containing file. File paths are Perl 5 Regular Expressions - you can [test]( https://www.regexplanet.com/advanced/perl/) yours before committing to verify it will match your files. `^` refers to the file's path from the root of the repository, so `^README\.md$` would exclude [README.md]( ../tree/HEAD/README.md) (on whichever branch you're using). well-formed pattern. If you can write a that would match it, try adding it to the `patterns.txt` file. Patterns are Perl 5 Regular Expressions - you can [test]( https://www.regexplanet.com/advanced/perl/) yours before committing to verify it will match your lines. Note that patterns can't match multiline strings. </details>
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-2-6.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 8.2.6 <!-- Auto generated by update changelog github action --> Security: Upgrade Docker base image to Alpine 3.14.3. , Security: Upgrade Go to 1.17.2. , TimeSeries: Fix fillBelowTo wrongly affecting fills of unrelated series. ,