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

is a tech consulting company, Cloud pureplayer, specialised in DevOps and digital automation. We are a multi-services provider able to help companies in their Cloud projects by understanding their needs and goals. Our goal consists in helping firms in their digital transformation process. We also help them to improve their knowledge such as Chaos Engineering and their skills on digital tools and software. We provide our clients with the knowledge and competencies necessary to manage cloud computing projects and provide more resiliency to their deployed micro-services. We aim to speed up innovation, this is the main reason why WeScale exists. Thus, we lean on public cloud platforms such as AWS and GCP for instance. To enhance the resiliency of our clients' systems, we do chaos engineering. But, we have faced so many tools that can be used to inject chaos in our deployed micro-services.After trying many tools, Litmus took the lead when injecting chaos in kubernetes. We use litmus experiments available in the litmus chaos hub. We are injecting them through our CI(it depends on the CI tools uesed by our clients) in the application. The chaos injection is done by increasing the blast radius from pods to the cluster. Soon, we will test the Litmus Portal to manage the chaos workflow. Litmus is one of the best Open Source tools that makes doing chaos engineering very easy. It provides a hub for chaos expriments. It can also be deployed in our kubernetes cluster without any external dependencies.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: rbac-details.md

It specifies the name of the serviceaccount mapped to a role/clusterRole with enough permissions to execute the desired chaos experiment. The minimum permissions needed for any given experiment are provided in the `.spec.definition.permissions` field of the respective chaosexperiment CR. It can be tuned via `chaosServiceAccount` field. ??? info "View the RBAC specification schema" <table> <tr> <th>Field</th> <td><code>.spec.chaosServiceAccount</code></td> </tr> <tr> <th>Description</th> <td>Flag to specify serviceaccount used for chaos experiment</td> </tr> <tr> <th>Type</th> <td>Mandatory</td> </tr> <tr> <th>Range</th> <td><i>user-defined</i> (type: string)</td> </tr> <tr> <th>Default</th> <td><i>n/a</i></td> </tr> <tr> <th>Notes</th> <td>The <code>chaosServiceAccount</code> in the spec specifies the name of the serviceaccount mapped to a role/clusterRole with enough permissions to execute the desired chaos experiment. The minimum permissions needed for any given experiment is provided in the <code>.spec.definition.permissions</code> field of the respective <b>chaosexperiment</b> CR.</td> </tr> </table> Use the following example to tune this: ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: "active" annotationCheck: "false" appinfo: appns: "default" applabel: "app=nginx" appkind: "deployment" chaosServiceAccount: pod-delete-sa experiments: name: pod-delete ```
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_lease.Lease.md

title: "Class: Lease" linkTitle: "Lease" slug: "libk8slease.Lease" .Lease `any` `Lease` new Lease(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeLease\>('Lease').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<KubeLease\>('Lease').className `get` spec(): `any` `any` `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeLease\>('Lease').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeLease\>('Lease').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeLease\>('Lease').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeLease\>('Lease').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeLease\>('Lease').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeLease\>('Lease').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeLease\>('Lease').useList
Project: Netdata (Observability and Analysis / Observability)
File: disk_space_usage.md

This alarm presents the percentage of used space of a particular disk. If it is close to 100%, it means that your storage device is running out of space. If the particular disk raising the alarm is full, the system could experience slowdowns and even crashes. Clean or upgrade the drive. If your storage device is full and the alert is raised, there are two paths you can tend to: Cleanup your drive, remove any unnecessary files (files on the trash directory, cache files etc.) to free up space. Some areas that are safe to delete, are: Files under `/var/cache` Old logs in `/var/log` Old crash reports in `/var/crash` or `/var/dump` The `.cache` directory in user home directories If your workflow requires all the space that is currently used, then you might want to look into upgrading the disk that raised the alarm, because its capacity is small for your demands. Netdata strongly suggests that you are careful when cleaning up drives, and removing files, make sure that you are certain that you delete only unnecessary files.
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_registry.SectionFuncProps.md

title: "Interface: SectionFuncProps" linkTitle: "SectionFuncProps" slug: "plugin_registry.SectionFuncProps" .SectionFuncProps title: `string` component(`props`): ``null`` \| `Element` | Name | Type | | : | : | | `props` | `Object` | | `props.resource` | `any` | ``null`` \| `Element`
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: openfeature.md

description: OpenFeature sidebar_label: OpenFeature sidebar_position: 2 is an open standard for feature flag management, created to support a robust feature flag ecosystem using cloud native technologies. OpenFeature provides a unified API and SDK, and a developer-first, cloud-native implementation, with extensibility for open source and commercial offerings. Flagsmith is proud to contribute to this initiative, and is a governance board member of this CNCF project. Our goal, and that of OpenFeature, is to recommend using OpenFeature as the default SDK interface for Flagsmith projects. OpenFeature is being actively worked on; we encourage anyone interested Feature Flags and Open Source to get involved! We currently offer for the following languages: The following OpenFeature Providers are currently being implemented: We plan on implementing providers for the following languages as soon as we can: PHP Kotlin Swift
Project: Elastic (Observability and Analysis / Observability)
File: mv_concat.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Converts a multivalued string expression into a single valued column containing the concatenation of all values separated by a delimiter. ``` ROW a=["foo", "zoo", "bar"] | EVAL j = MV_CONCAT(a, ", ") ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16177.md

key | value | date | 2024-03-15T15:27:21+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes Aggregation errors are shown in the details of 'Aggr' services. Previously, all aggregation errors were shown in the same tree independent of whether they influence the state of the service or not, which lead to confusion. Now, two trees are shown, 'Aggregation problems affecting the state' and 'Aggregation problems not affecting the state'.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: documentation_request.md

name: Documentation request about: Ask for documentation to be added, changed, or removed title: "Docs: ..." labels: type/docs assignees: "" A clear and concise description of the feature that you were trying to use, and what you were trying to achieve. A clear and concise description of the documentation that you want to add, change, or remove.
Project: Checkmk (Observability and Analysis / Observability)
File: 16037.md

key | value | date | 2023-12-22T08:11:28+00:00 version | 2.3.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes You can no longer set a non-existent site on folders and hosts. When called with a non-existent site as an attribute the endpoints now return the status code 400.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-strategy_update.md

category: Strategy apiurl: '/api/v1/strategy' title: "Update Strategy" type: 'PUT' sample_doc: 'template.html' layout: default Required ```{ "tags": "", "run_end": "", "run_begin": "", "right_value": "1", "priority": 2, "op": "==", "note": "this is a test", "metric": "agent.alive", "max_step": 3, "id": 904, "func": "all(#3)" }``` ```Status: 200``` ```{"message":"stragtegy:904 has been updated"}```
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: question.md

name: "\U0001F914 Question" about: Question not answered in our community meetings, Docs or Readme. title: '' labels: '' assignees: '' Feel free to get your queries resolved. Please make sure you have, Reviewed the asked by our community members and contributers. Searched opened and closed We primarily use GitHub as an issue tracker; for usage and support questions, please check out these resources below. Thanks! -
Project: Vector (Observability and Analysis / Observability)
File: 2020-01-12-request-options-refactored.md

date: "2020-07-13" title: "Sink options have been refactored" description: "We've simplified and organized our sink options" authors: ["binarylogic"] pr_numbers: [1006, 1493, 1494, 1495] release: "0.7.0" hideonrelease_notes: false badges: type: "breaking change" domains: ["buffers", "config", "sinks"] In our preparation for 1.0 we took time to organize and cleanup our request-based sink options. The specific changes include: `request_*` options have been moved under a `request` table. `retrybackoffsecs` must also be replaced with two new fields `retryinitialbackoffsecs` and `retrymaxdurationsecs`. `batch_*` options have been moved under a `batch` table. `batchsize` has been replaced with either `batch.maxevents` or `batch.max_size` in order to clarify its purpose (capping discrete events or bytes respectively). `basic_auth` fields have been moved to a general purpose `auth` table complemented with a `strategy` field. These changes effect the following sinks: `awscloudwatchlogs` `awskinesisfirehose` `awskinesisstreams` `aws_s3` `clickhouse` `datadog_metrics` `elasticsearch` `gcp_pubsub` `http` `newreliclogs` `splunk_hec` ```diff title="vector.toml" [sinks.mysinkid] type = "http" inputs = ["my-source-id"] uri = "https://10.22.212.22:9000/endpoint" batch_size = 1049000 [sinks.mysinkid.batch] max_size = 1049000 [sinks.mysinkid.basic_auth] [sinks.mysinkid.auth] strategy = "basic" user = "${USERNAMEENVVAR}" password = "${PASSWORDENVVAR}" requestinflight_limit = 5 requestretrybackoff_secs = 1 [sinks.mysinkid.request] inflightlimit = 5 retryinitialbackoff_secs = 1 retrymaxduration_secs = 10 ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16355.md

key | value | date | 2024-04-15T10:20:16+00:00 version | 2.4.0b1 class | fix edition | cee component | multisite level | 1 compatible | yes When using Checkmk in a language other than English, the list views for graph collections, graph tunings, custom graphs and forecast graphs might have displayed strange help texts such as "Project-Id-Version: Checkmk user interface translation 0.1 ...". This happened only for graph objects with empty descriptions and only if the inline help was activated for the corresponding page.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: AWS-experiments-tunables.md

It contains the AWS specific experiment tunables. It specifies whether aws instances are part of managed nodeGroups. If instances belong to the managed nodeGroups then provide `MANAGED_NODEGROUP` as `enable` else provide it as `disable`. The default value is `disabled`. Use the following example to tune this: ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: "active" annotationCheck: "false" chaosServiceAccount: ec2-terminate-by-tag-sa experiments: name: ec2-terminate-by-tag spec: components: env: name: MANAGED_NODEGROUP value: 'enable' name: REGION value: '<region for instances>' name: INSTANCE_TAG value: 'key:value' name: TOTALCHAOSDURATION value: '60' ``` The multiple iterations of chaos can be tuned via setting `CHAOS_INTERVAL` ENV. Which defines the delay between each iteration of chaos. Use the following example to tune this: ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: "active" annotationCheck: "false" chaosServiceAccount: ec2-terminate-by-tag-sa experiments: name: ec2-terminate-by-tag spec: components: env: name: CHAOS_INTERVAL value: '15' name: TOTALCHAOSDURATION value: '60' name: REGION value: '<region for instances>' name: INSTANCE_TAG value: 'key:value' ```
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: using-qos-ensurance.md

title: "Colocation with Enhanced QOS" description: "Colocation with Enhanced QOS General introduction" weight: 18 QOS ensurance guarantees the stability of the pods running on Kubernetes. It has the ability of interference detection and active avoidance. When pod with higher priority is affected by resource competition, disable schedule, throttle and evict will be applied to pod with lower priority to ensure the overall stability of the node. Currently, the absolute value/percentage of the node's cpu/mem is supported as a watermark. For details, please refer to . When there is interference for eviction or throttle, accurate calculation will be performed, and the operation will be stopped when the load is lowered to slightly below the watermark to prevent accidental injury and transitional operation. For details, please refer to . At the same time, Crane supports custom metrics to adapt to the entire interference detection framework. Users only need to complete some operations such as sorting definition, and can reuse the interference detection and avoidance processes including precise operations.For details, please refer to . Crane has the dynamic resource oversold ability enhanced by the prediction algorithm, and reuses the idle resources. At the same time, it combines the prediction ability of the crane to better reuse the idle resources. Currently, idle resource recycling of cpu and mem is supported. At the same time, it has the elastic resource limitation function to limit the workload of reusing idle resources, and avoid impact on high-quality business and starvation issues. For details, please refer to . At the same time, it has enhanced bypass cpuset management capability to improve resource utilization efficiency while binding cores. For details, please refer to .
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: syslogng_flow_types.md

title: SyslogNGFlowSpec weight: 200 generated_file: true SyslogNGFlowSpec is the Kubernetes spec for SyslogNGFlows Output metrics are applied before the log reaches the destination and contain output metadata like: `name,` `namespace` and `scope`. Scope shows whether the output is a local or global one. Available in Logging operator version 4.5 and later. Filter definition for SyslogNGFlowSpec Flow Kubernetes object FlowList contains a list of Flow
Project: Netdata (Observability and Analysis / Observability)
File: outbound_packets_dropped.md

This alert tracks the number of dropped outbound packets on a specific network interface (`${label:device}`) within the last 10 minutes. If you receive this alert, it means that your system has experienced dropped outbound packets in the monitored network interface, which might indicate network congestion or other issues affecting network performance. Dropped packets refer to network packets that are discarded or lost within a computer network during transmission. In general, this can be caused by various factors, such as network congestion, faulty hardware, misconfigured devices, or packet errors. Identify the affected network interface: Check the alert message for the `${label:device}` placeholder. It indicates the network interface experiencing the dropped outbound packets. Verify network congestion or excessive traffic: Excessive traffic or network congestion can lead to dropped packets. To check network traffic, use the `nload` tool. ```bash nload ${label:device} ``` This will display the current network bandwidth usage on the specified interface. Look for unusually high or fluctuating usage patterns, which could indicate congestion or excessive traffic. Verify hardware issues: Check the network interface and related hardware components (such as the network card, cables, and switches) for visible damage, loose connections, or other issues. Replace any defective components as needed. Check network interface configuration: Review your network interface configuration to ensure that it is correctly set up. To do this, you can use the `ip` or `ifconfig` command. For example: ```bash ip addr show ${label:device} ``` or ```bash ifconfig ${label:device} ``` Verify that the IP address, subnet mask, and other network settings match your network configuration. Check system logs for networking errors: Review your system logs to identify any networking error messages that might provide more information on the cause of the dropped packets. ```bash grep -i "error" /var/log/syslog | grep "${label:device}" ``` Monitor your network for packet errors using tools like `tcpdump` or `wireshark`.
Project: Promscale (Observability and Analysis / Observability)
File: prometheus-HA.md

Promscale is a stateless service, thus it can run safely with multiple replicas. A load-balancer can simply route Promscale requests to any replica. Promscale supports running Prometheus in High Availability (HA). This means that you can have multiple Prometheus instances running as "HA pairs". Such "HA pairs" (what we will call clusters from now on) are simply two or more identical Prometheus instances running on different machines/containers. These instances scrape the same targets and should thus have very similar data (the differences occur because scrapes happen at slightly different times). You can think of a cluster as a group of similar Prometheus instances that are all scraping the same targets and replicas as individual Prometheus instance in that group. Promscale supports de-duplicating data coming from such HA clusters upon ingest. It does this by electing a leader Prometheus instance and only ingesting data from that leader. If the leader Prometheus stops sending data to Promscale for any reason, Promscale will fail-over to the other Prometheus instance. Promscale supports having multiple clusters sending data to the same set of Promscale instances. It will elect one leader per cluster. To set up Promscale to process data from Prometheus running in HA mode, Prometheus must be configured to communicate which cluster it belongs to using external labels. In particular, each Prometheus should send a `cluster` label to indicate which cluster it's in and a `replica` label that provides a unique identifier for the Prometheus instance with the cluster. Two Prometheus instances running as part of a HA cluster, MUST send the same `cluster` label and different `replica` labels. In Kubernetes environments, it is often useful to set the `replica` label to the pod name, and the cluster name as the Prometheus deployment/statefulset name. When using the this can be done with the following settings: ``` replicaExternalLabelName: "replica" prometheusExternalLabelName: "cluster" ``` In bare metal and other environments, you need to configure external labels with the cluster and replica names in each Prometheus instance config as mentioned below: ``` global: external_labels: replica: <REPLICA_NAME> (This should be unique name of the Prometheus instance) cluster: <CLUSTER_NAME> (This should be the name of the Prometheus deployment, which should be common across the Prometheus replica instances.) ``` After Prometheus instances are configured to send the correct labels, Promscale simply needs to be started with the `-metrics.high-availability` CLI flag. Internally, Promscale will elect a single replica per cluster to be the current leader. Only data sent from that replica will be ingested. If that leader-replica stops sending data, then a new replica will be elected as the leader.
Project: Grafana Loki (Observability and Analysis / Observability)
File: quickstart.md

title: Quick Start description: Quick Start lead: "" lastmod: "2021-03-08T08:48:57+00:00" draft: false images: [] menu: docs: parent: prologue weight: 200 toc: true One page summary on how to start with Loki Operator and LokiStack. The easiest way to start with the Loki Operator is to use Kubernetes . The simplest form to deploy the Loki Operator and a LokiStack for demo purposes is: ```shell make quickstart ``` If you want to test local changes from your repository fork, you need to provide an image registry organization that you own that has an image repository name `loki-operator`, e.g. `quay.io/my-company-org/loki-operator`. The command to use your custom images is: ```shell make quickstart REGISTRY_BASE=quay.io/my-company-org ``` For detailed instructions on how to start hacking on the Loki Operator, please follow one of the two guides:
Project: Chaosblade (Observability and Analysis / Chaos Engineering)
File: MAINTAINERS.md

This file lists the maintainers of the ChaosBlade project. The responsibilities of maintainers are listed in the file. | Name | GitHub ID | Affiliation | | - | | -- | | | | Alibaba | | | | Alibaba | | | | Individual | | | | JiHu(GitLab) | | | | China Mobile |