cwielenb/CNCF-Dataset huggingface dataset:
Project: HertzBeat (Observability and Analysis / Observability)
File: alert_email.md

id: alert_email title: Alert email notification sidebar_label: Alert email notification keywords: [open source monitoring tool, open source alerter, open source email notification] After the threshold is triggered send alarm information and notify the recipient by email. Alarm notification->Add new recipient ->Select email notification method Get verification code-> Enter email verification code-> Confirm Configure the associated alarm notification strategy Add new notification strategy-> Associate the recipient just set-> Confirm Note Adding a new recipient does not mean that it is effective to receive alarm information. It is also necessary to configure the associated alarm notification strategy, that is, to specify which messages are sent to which recipients. Hertzbeat deployed on its own intranet cannot receive email notifications Hertzbeat needs to configure its own mail server, not tancloud. Please confirm whether you have configured its own mail server in application.yml Cloud environment tancloud cannot receive email notification Please check whether there is any triggered alarm information in the alarm center. Please check whether the mailbox is configured correctly and whether the alarm strategy association is configured. Please check whether the warning email is blocked in the trash can of the mailbox. Other issues can be fed back through the communication group ISSUE!
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: Jayesh_Kumar_Tank.md

I started exploring the facinating world of Chaos Engineering while working on stitching together CloudNative Validation Suite. In persuit of finding the suitable candidate, I evaluated couple of Chaos Engineering tool chains, both free as well commercial and finally settled on to LitmusChaos. I have my own reasons to do so, which includes super helpful developers and community supporting this project. While evaluating LitmusChaos for my pipeline - I requested a new feature for Aborting the active experiment, which was accepted and is being actively worked on. Another thing which sets LitmusChaos apart from many other players is it being fully CloudNative, ease of development in Ansible. ChaosHub is a central place for community to contribute their work and make it available for others. In the past I have been contributing to Litmus-Docs project as maintainer and looking forward to contribute a couple of Chaos Experiments. Keeping my fingers crossed!!
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: installation-cli-tool.md

title: "Installation of CLI Tool" description: "How to install kubectl-crane" weight: 12 You can install `kubectl-crane` plugin in any of the following ways: One-click installation. Install using Krew. Build from source code. Kubectl: `kubectl` is the Kubernetes command line tool lets you control Kubernetes clusters. For installation instructions see . ```shell export release=v0.2.0 export arch=x86_64 curl -L -o kubectl-crane.tar.gz https://github.com/gocrane/kubectl-crane/releases/download/${release}/kubectl-crane${release}Linux_${arch}.tar.gz tar -xvf kubectl-crane.tar.gz cp kubectl-crane${release}Linux_${arch}/kubectl-crane /usr/local/bin/ ``` ```shell export release=v0.2.0 export arch=arm64 curl -L -o kubectl-crane.tar.gz https://github.com/gocrane/kubectl-crane/releases/download/${release}/kubectl-crane${release}Darwin_${arch}.tar.gz tar -xvf kubectl-crane.tar.gz cp kubectl-crane${release}Darwin_${arch}/kubectl-crane /usr/local/bin/ ``` `Krew` is the plugin manager for `kubectl` command-line tool. Krew on your machine. Then install `kubectl-crane` plug-in: ```shell kubectl krew install crane ``` ```shell git clone https://github.com/gocrane/kubectl-crane.git cd kubectl-crane export CGO_ENABLED=0 go mod vendor go build -o kubectl-crane ./cmd/ ``` Next, move the `kubectl-crane` executable file in the project root directory to the `PATH` path.
Project: Netdata (Observability and Analysis / Observability)
File: consul_autopilot_server_health_status.md

The `consulautopilotserverhealthstatus` alert triggers when a Consul server in your service mesh is marked `unhealthy`. This can affect the overall stability and performance of the service mesh. Regular monitoring and addressing unhealthy servers are crucial in maintaining a smooth functioning environment. `Consul` is a service mesh solution that provides a full-featured control plane with service discovery, configuration, and segmentation functionalities. It is used to connect, secure, and configure services across any runtime platform and public or private cloud. Follow the steps below to identify and resolve the issue of an unhealthy Consul server: Check Consul server logs Inspect the logs of the unhealthy server to identify the root cause of the issue. You can find logs typically in `/var/log/consul` or use `journalctl` with Consul: ``` journalctl -u consul ``` Verify connectivity Ensure that the unhealthy server can communicate with other servers in the datacenter. Check for any misconfigurations or network issues. Review server resources Monitor the resource usage of the unhealthy server (CPU, memory, disk I/O, network). High resource usage can impact the server's health status. Use tools like `top`, `htop`, `iotop`, or `nload` to monitor the resources. Restart the Consul server If the issue persists and you cannot identify the root cause, try restarting the Consul server: ``` sudo systemctl restart consul ``` Refer to Consul's documentation Consult the official for further assistance. Inspect the Consul UI Check the Consul UI for the server health status and any additional information related to the unhealthy server. You can find the Consul UI at `http://<consul-server-ip>:8500/ui/`.
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: concepts.md

sidebar_position: 10 description: How GO Feature Flag is working with OpenFeature. :::note OpenFeature 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. https://docs.openfeature.dev/docs/category/concepts ::: OpenFeature offer a framework-agnostic way of using feature flags, it means that if you use OpenFeature SDKs you will have minimum changes to do if you want to choose another provider. To support this initiative, GO Feature Flag does not have any SDKs and rely 100% on OpenFeature SDKs. To be compatible with our solution, we offer for GO Feature Flag in several languages. To use the OpenFeature SDKs you need what we call a provider. A provider is responsible for performing flag evaluations. It provides an abstraction between GO Feature Flag and the OpenFeature SDK. A provider need a backend service to perform the flag evaluation. This is why we have introduced the . This component retrieve your feature flag configuration file using the GO module and expose APIs to get your flags variations. With this simple architecture you have a central component (the relay proxy) that is in charge of the flag evaluation, while the SDKs and providers are responsible to communicate with the relay proxy. This supports different languages the same way and makes you able to use GO Feature Flag with all your favorite languages.
Project: Netdata (Observability and Analysis / Observability)
File: elasticsearch_node_indices_search_time_query.md

This alert is triggered when the average search time for Elasticsearch queries has been higher than the defined warning thresholds. If you receive this alert, it means that your search performance is degraded, and queries are running slower than usual. Search performance in Elasticsearch refers to how quickly and efficiently search queries are executed, and the respective results are returned. Good search performance is essential for providing fast and relevant results in applications and services relying on Elasticsearch for their search capabilities. Several factors can cause search performance degradation, including: High system load, causing CPU, memory or disk I/O bottlenecks Poorly optimized search queries High query rate, resulting in a large number of concurrent queries Insufficient hardware or resources allocated to Elasticsearch Check the Elasticsearch logs for any error messages or warnings: ``` cat /var/log/elasticsearch/elasticsearch.log ``` Monitor the system resources (CPU, memory, and disk I/O) using tools like `top`, `vmstat`, and `iotop`. Determine if there are any resource bottlenecks affecting the search performance. Analyze and optimize the slow search queries by using the Elasticsearch . Evaluate the cluster health status by running the following Elasticsearch API command: ``` curl -XGET 'http://localhost:9200/_cluster/health?pretty' ``` Check for any issues that may be impacting the search performance. Assess the number of concurrent queries and, if possible, reduce the query rate or distribute the load among additional Elasticsearch nodes. If the issue persists, consider scaling up your Elasticsearch deployment or allocating additional resources to the affected nodes to improve their performance.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_ingress.IngressRule.md

title: "Interface: IngressRule" linkTitle: "IngressRule" slug: "libk8singress.IngressRule" .IngressRule host: `string` _ http: `Object` | Name | Type | | : | : | | `paths` | { `backend`: ; `path`: `string` ; `pathType?`: `string` }[] |
Project: OpenTelemetry (Observability and Analysis / Observability)
File: http.md

Get the HTTP semantic conventions across the finish line to stability, and afterwards update existing HTTP instrumentation across all OpenTelemetry repositories to conform with the stable conventions. https://github.com/orgs/open-telemetry/projects/41 Mark the HTTP semantic conventions as stable. Update existing HTTP instrumentation across all OpenTelemetry repositories to conform with the stable conventions. The goal is to follow @tedsuo's proposed . Stage 1: Working Group Preparation Stage 2: Specification Stage 3: Implementation @trask project lead @denisivan0v domain expert @lmolkova domain expert @mateuszrzeszutek prototyping in Java @reyang technical committee sponsor @jsuereth technical committee sponsor Need: more domain experts Need: engineers willing to write prototypes in at least one more language other than Java. Language should be fairly different from Java (for example: Python). Need: maintainers or approvers from those languages committed to reviewing the prototypes. @trask project lead @mateuszrzeszutek updating Java instrumentation Need: engineers across all languages willing to update existing HTTP instrumentation across all OpenTelemetry repositories to conform with the stable conventions. Need: maintainers or approvers across all languages committed to reviewing the updates. Once a project is started, the working group should meet regularly for discussion. These meeting times should be posted on the OpenTelemetry public calendar. All work has been completed.
Project: Beats (Observability and Analysis / Observability)
File: flaky-test.md

name: Flaky Test about: Report a flaky test (one that doesn't pass consistently) labels: flaky-test Test Name:* Name of the failing test. Link:* Link to file/line number in github. Branch:* Git branch the test was seen in. If a PR, the branch the PR was based off. Artifact Link:* If available, attach the generated zip artifact associated with the stack trace for this failure. Notes:* Additional details about the test. e.g. theory as to failure cause ``` paste stack trace here ```
Project: Netdata (Observability and Analysis / Observability)
File: vm.swap_info.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/integrations/vm.swap_info.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/metadata.yaml" sidebarlabel: "vm.swapinfo" 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.swap_info <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Collect information about SWAP memory. The plugin calls `sysctlnametomib` function to collect necessary data. This collector is supported on all platforms. This collector supports collecting metrics from multiple instances of this integration, including remote instances. This integration doesn't support auto-detection. The default configuration for this integration does not impose any limits on data collection. The default configuration for this integration is not expected to impose a significant performance impact on the system. Metrics grouped by scope. The scope defines the instance that the metric belongs to. An instance is uniquely identified by a set of labels. This metric shows the SWAP usage. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | mem.swap | free, used | MiB | The following alerts are available: | Alert name | On metric | Description | |:|:-|:| | | mem.swap | swap memory utilization | 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.swap_info | Enable or disable SWAP metrics. | yes | no | </details> There are no configuration examples.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: litmus-sdk.md

The Litmus SDK provides a simple way to bootstrap your experiment and helps create the aforementioned artifacts in the appropriate directory (i.e., as per the chaos-category) based on an attributes file provided as input by the chart-developer. The scaffolded files consist of placeholders which can then be filled as desired. It generates the custom chaos experiments with some default Pre & Post Chaos Checks (AUT & Auxiliary Applications status checks). It can use the existing chaoslib (present inside /chaoslib directory), if available else It will create a new chaoslib inside the corresponding directory. UseCase: Create a pod cpu stress experiment, which execs inside the target pod and run md5sum command Steps: Clone the litmus-go repository and navigate to the contribute/developer-guide directory Generate experiment code Add stead-state checks and experiment business logic Build go-runner image Create charts and add them inside the chaos-charts repo Create a new chaos hub Run the experiment
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: fluentd_types.md

title: FluentdSpec weight: 200 generated_file: true FluentdSpec defines the desired state of Fluentd BufferStorageVolume is by default configured as PVC using FluentdPvcSpec Allows Time object in buffer's MessagePack serde FluentOutLogrotate sends fluent's stdout to file and rotates it Deprecated, use bufferStorageVolume Ignore repeated log lines Ignore same log lines Set the logging format. Allowed values are: "text" (default) and "json". Fluentd port inside the container (24240 by default). The headless service port is controlled by this field as well. Note that the default ClusterIP service port is always 24240, regardless of this field. Available in Logging operator version 4.5 and later. Configure sidecar container in Fluentd pods, for example: . ExtraVolume defines the fluentd extra volumes FluentdScaling enables configuring the scaling behaviour of the fluentd statefulset FluentdTLS defines the TLS configs FluentdDrainConfig enables configuring the drain behavior when scaling down the fluentd statefulset Annotations to use for the drain watch sidecar Should persistent volume claims be deleted after draining is done Should buffers on persistent volumes left after scaling down the statefulset be drained Labels to use for the drain watch sidecar on top of labels added by the operator by default. Default values can be overwritten. Container image to use for the fluentd placeholder pod Available in Logging operator version 4.4 and later. Configurable resource requirements for the drainer sidecar container. Default 20m cpu request, 20M memory limit Available in Logging operator version 4.4 and later. Configurable security context, uses fluentd pods' security context by default
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-7-5-0-beta2.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 7.5.0-beta2 <!-- Auto generated by update changelog github action --> CloudWatch: Add support for EC2 IAM role. , CloudWatch: Consume the grafana/aws-sdk. , CloudWatch: Restrict auth provider and assume role usage according to Grafana configuration. , Cloudwatch: ListMetrics API page limit. , Cloudwatch: use shared library for aws auth. , DataLinks: Bring back single click links for Stat, Gauge and BarGauge panel. , Docker: Support pre-installed plugins from other sources in custom Dockerfiles. , Elasticseach: Add support for histogram fields. , Exemplars: Always query exemplars. , Explore: Support full inspect drawer. , HttpServer: Make read timeout configurable but disabled by default. , SQLStore: Close session in withDbSession. , Templating: Use dashboard timerange when variables are set to refresh 'On Dashboard Load'. , Tempo: Convert to backend data source. , Admin: Keeps expired api keys visible in table after delete. , Data proxy: Fix encoded characters in URL path should be proxied as encoded. , Explore/Logs: Fix escaping in ANSI logs. , GraphNG: Fix tooltip series color for multi data frame scenario. , GraphNG: Make sure data set and config are in sync when initializing and re-initializing uPlot. , Loki: Fix autocomplete when re-editing Loki label values. , MixedDataSource: Name is updated when data source variables change. , PanelInspect: Interpolates variables in CSV file name. , ReduceTransform: Include series with numeric string names. , Snapshots: Fix usage of sign in link from the snapshot page. , TimePicker: Fixes hidden time picker shown in kiosk TV mode. , ValueMappings: Fixes value 0 not being mapped. , Variables: Fixes filtering in picker with null items. , Variables: Improves inspection performance and unknown filtering. , Auth: Allow soft token revocation. ,
Project: Opstrace (Observability and Analysis / Observability)
File: gcp.md

Note: For a detailed walk-through showing how to set up a fresh GCP project for Opstrace, please try our corresponding . Creating an Opstrace instance in a GCP project requires the following APIs to be in that project: Cloud DNS API Compute Engine API Kubernetes Engine API Cloud SQL Admin API Service Networking API Cloud Resource Manager API We try to keep this list up to dateif in doubt, please ! Creating an Opstrace instance in a GCP project requires a service account. That service account must have certain security roles applied in the GCP project: `roles/compute.networkAdmin` `roles/container.admin` `roles/editor` `roles/iam.securityAdmin` If you would like to know which individual permissions are implied by any of these roles, please search for that role (e.g. `roles/container.admin`) on the . Note: we didn't quite arrive at fulfilling the herethis is an ongoing effort. If you have specific ideas for reducing the set of privileges required, please !
Project: Vector (Observability and Analysis / Observability)
File: 2022-11-07-0-26-0-upgrade-guide.md

date: "2022-11-07" title: "0.26 Upgrade Guide" description: "An upgrade guide that addresses breaking changes in 0.26.0" authors: ["tobz"] release: "0.26.0" hideonrelease_notes: false badges: type: breaking change Vector's 0.26.0 release includes breaking changes: We cover them below to help you upgrade quickly: Nearly two years ago, as part of the , we had deprecated many transforms and conditions after initially releasing . Over time, many of these transforms and conditions were fully removed, but some of them were left as the performance gap between them and their equivalent usage in VRL had significant performance differences. Since then, many of these performance gaps have been significantly reduced, if not closed entirely. After taking another look at `check_fields`, it now has less than a 10% performance difference compared to the equivalent VRL, which we feel is close enough to allow us to finally remove support for `check_fields`. As we don't always have a full view into what features of Vector are being used, please do not hesitate to let us know if the removal of `check_fields`, and having to switch over to using VRL, represents a significant performance regression for you. Similarly to the removal of `check_fields`, the `lanes` parameter of the `route` transform is a holdover from when the transform was originally called `swimlanes`. It is an alias to the `route` parameter used to configure the actual routing logic for the transform. We deprecated being able to reference the `route` transform by its former name of `swimlanes` in the 0.24.0 release, and removed the ability entirely in 0.25.0. In following with removing the `swimlanes` alias, we're now removing the `lanes` alias as well to finally drop all remaining ties to the original `swimlanes` name. A simple change of the field name in your configuration is all that has to change: ```yaml transforms: my_route: type: route lanes: # <-- change this to "route" route_a: .. ``` The `geoip` transform was deprecated in `0.24.0` and has now been removed. You can get the same functionality through a `remap` transform with [`geoip` enrichment tables](/docs/reference/configuration/global-options/#enrichment_tables.geoip). These can be used with to enrich events using a . For example, ```yaml transforms: geoip: type: geoip inputs: withipinfo database: /etc/vector/GeoLite2-City.mmdb source: ip_address target: geoip ``` can be migrated as: ```yaml enrichment_tables: geoip_table: path: /etc/vector/GeoLite2-City.mmdb type: geoip transforms: geoip: type: remap inputs: withipinfo source: |- .geoip = getenrichmenttablerecord!("geoiptable", { "ip": .ip_address } ) ``` (credit to for this migration example)
Project: Checkmk (Observability and Analysis / Observability)
File: 16368.md

key | value | date | 2024-02-12T12:34:21+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes Prior to this Werk, when a service discovery was requested from a host whose IP could not be resolved, the endpoint returned a 500 error status (Internal Server Error). This Werk corrects this behavior and now returns error code 400.