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

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/integrations/slack.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/metadata.yaml" sidebar_label: "Slack" learn_status: "Published" learnrelpath: "Alerts & Notifications/Notifications/Centralized Cloud Notifications" message: "DO NOT EDIT THIS FILE DIRECTLY, IT IS GENERATED BY THE NOTIFICATION'S metadata.yaml FILE" endmeta--> <img src="https://netdata.cloud/img/slack.png" width="150"/> From the Netdata Cloud UI, you can manage your space's notification settings and enable the configuration to deliver notifications on Slack. <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> A Netdata Cloud account Access to the Netdata Space as an Admin The Netdata Space needs to be on a paid plan You need to have a Slack app on your workspace to receive the Webhooks. Steps to configure your Slack to receive notifications from Netdata: Create an app to receive webhook integrations. Check from Slack documentation for further details Install the app on your workspace Configure Webhook URLs for your workspace On your app go to Incoming Webhooks and click on activate incoming webhooks At the bottom of Webhook URLs for Your Workspace section you have Add New Webhook to Workspace After pressing that specify the channel where you want your notifications to be delivered Once completed copy the Webhook URL that you will need to add to your notification configuration on Netdata UI For more details please check Slacks's article . Click on the Space settings cog (located above your profile icon) Click on the Notification tab Click on the + Add configuration button (near the top-right corner of your screen) On the Slack card click on + Add A modal will be presented to you to enter the required details to enable the configuration: Notification settings* are Netdata specific settings Configuration name - you can optionally provide a name for your configuration you can easily refer to it Rooms - by specifying a list of Rooms you are select to which nodes or areas of your infrastructure you want to be notified using this configuration Notification - you specify which notifications you want to be notified using this configuration: All Alerts and unreachable, All Alerts, Critical only Integration configuration* are the specific notification integration required settings, which vary by notification method. For Slack: Webhook URL - URL provided on Slack for the channel you want to receive your notifications.
Project: Checkmk (Observability and Analysis / Observability)
File: 16666.md

key | value | date | 2024-04-22T06:19:27+00:00 version | 2.4.0b1 class | fix edition | cee component | setup level | 1 compatible | yes Th rule "Asynchronous execution of plug-ins" has no affect on the execution of the scrips therefore it is being deprecated. This means it will eventually be removed in future versions.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-5-2.md

hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 8.5.2 <!-- Auto generated by update changelog github action --> Alerting: Add safeguard for migrations that might cause dataloss. , AzureMonitor: Add support for not equals and startsWith operators when creating Azure Metrics dimension filters. , Elasticsearch: Add deprecation notice for < 7.10 versions. , Traces: Filter by service/span name and operation in Tempo and Jaeger. , AzureAd Oauth: Fix strictMode to reject users without an assigned role. , CloudWatch: Fix variable query tag migration. , Plugins: Ensure catching all appropriate 4xx api/ds/query scenarios. ,
Project: Nightingale (Observability and Analysis / Observability)
File: PULL_REQUEST_TEMPLATE.md

What type of PR is this? What this PR does / why we need it: <!-- "Nice to have" "You need it" is not a good reason. :) --> Which issue(s) this PR fixes: <!-- Usage: `Fixes #<issue number>`, or "Fixes (paste link of issue)" --> Fixes # Special notes for your reviewer:
Project: Grafana Mimir (Observability and Analysis / Observability)
File: RELEASE.md

The `yaml` Project is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: docker.md

description: Getting Started with Flagsmith on Docker sidebar_position: 40 You can use docker to set up an entire environment locally: ```bash curl -o docker-compose.yml https://raw.githubusercontent.com/Flagsmith/flagsmith/main/docker-compose.yml docker-compose -f docker-compose.yml up ``` Wait for the images to download and run, then visit `http://localhost:8000/`. As a first step, you will need to create a new account at As well as the Environment Variables specified in the and you can also specify the following: `GUNICORNCMDARGS`: Gunicorn command line arguments. Overrides Flagsmith's defaults. See for reference. `GUNICORN_WORKERS`: The number of that are created `GUNICORN_THREADS`: The number of `GUNICORN_TIMEOUT`: The number of seconds before the `ACCESSLOGFORMAT`: Message format for Gunicorn's access log. See to define your own format. `ACCESSLOGLOCATION`: The location to write access logs to. If set to `-`, the logs will be sent to `stdout` Our Docker images are built against the following CPU architectures: `amd64` `linux/arm64` `linux/arm/v7` The docker-compose file runs the following containers: The Web user interface allows you to create accounts and manage your flags. The front end is written in node.js and React. The web user interface communicates via REST to the API that powers the application. The SDK clients also connect to this API. The API is written in Django and the Django REST Framework. Once you have created an account and some flags, you can then start using the API with one of the . You will need to override the API endpoint for each SDK to point to . You can access the Django Admin console to get CRUD access to some of the core tables within the API. You will need to create a super user account first with the following command: ```bash docker-compose run --rm --entrypoint "python manage.py createsuperuser" api ``` You can then access the admin dashboard at The REST API stores all its data within a Postgres database. Schema changes will be carried out automatically when upgrading using Django Migrations. You will need to either open ports into your docker host or set up a reverse proxy to access the two Flagsmith services (dashboard and API). You will also need to configure the dashboard environment variable `API_URL`, which tells the dashboard where the REST API is located.
Project: Netdata (Observability and Analysis / Observability)
File: kubelet_1m_pleg_relist_latency_quantile_099.md

This alert calculates the average Pod Lifecycle Event Generator (PLEG) relisting latency over the last minute with a quantile of 0.99 in microseconds. If you receive this alert, it means that the Kubelet's PLEG latency is high, which can slow down your Kubernetes cluster. Pod Lifecycle Event Generator (PLEG) is a component of the Kubelet that watches for container events on the system and generates events for a pod's lifecycle. High PLEG latency indicates a delay in processing these events, which can cause delays in pod startup, termination, and updates. Check the overall Kubelet performance and system load: a. Run `kubectl get nodes` to check the status of the nodes in your cluster. b. Investigate the node with high PLEG latency using `kubectl describe node <NODE_NAME>` to view detailed information about resource usage and events. c. Use monitoring tools like `top`, `htop`, or `vmstat` to check for high CPU, memory, or disk usage on the node. Look for problematic pods or containers: a. Run `kubectl get pods --all-namespaces` to check the status of all pods across namespaces. b. Use `kubectl logs <POD_NAME> -n <NAMESPACE>` to check the logs of the pods in the namespace. c. Investigate pods with high restart counts, crash loops, or other abnormal statuses. Verify Kubelet configurations and logs: a. Check the Kubelet configuration on the node. Look for any misconfigurations or settings that could cause high latency. b. Check Kubelet logs using `journalctl -u kubelet` for more information about PLEG events and errors. Consider evaluating your workloads and scaling your cluster: a. If you have multiple nodes experiencing high PLEG latency or if the overall load on your nodes is consistently high, you might need to scale your cluster. b. Evaluate your workloads and adjust resource requests and limits to make the best use of your available resources.
Project: Tracetest (Observability and Analysis / Observability)
File: tracetest_completion_fish.md

Generate the autocompletion script for fish Generate the autocompletion script for the fish shell. To load completions in your current shell session: ``` tracetest completion fish | source ``` To load completions for every new session, execute once: ``` tracetest completion fish > ~/.config/fish/completions/tracetest.fish ``` You will need to start a new shell for this setup to take effect. ``` tracetest completion fish [flags] ``` ``` -h, --help help for fish --no-descriptions disable completion descriptions ``` ``` -c, --config string config file will be used by the CLI (default "config.yml") -o, --output string output format [pretty|json|yaml] -s, --server-url string server url -v, --verbose display debug information ``` - Generate the autocompletion script for the specified shell
Project: M3 (Observability and Analysis / Observability)
File: headers_optional_write_all.md

`M3-Map-Tags-JSON`: If this header is set it enables dynamically mutating tags in a Prometheus write request. See issue for further context. Currently only `write` is supported. As an example, the following header would unconditionally cause `globaltag=somevalue` to be added to all metrics in a write request: ``` M3-Map-Tags-JSON: '{"tagMappers":[{"write":{"tag":"globaltag","value":"somevalue"}}]}' ```
Project: Vector (Observability and Analysis / Observability)
File: 2020-12-23-graphql-api.md

date: "2020-12-23" title: "The GraphQL API for Vector" description: "View Vector metrics and explore Vector topologies using GraphQL" authors: ["lucperkins"] pr_numbers: [] release: "0.12.0" hideonrelease_notes: false badges: type: "new feature" domains: ["api"] Vector now has a [GraphQL] API that you can use for a variety of purposes: To view Vector's internal metrics To view metadata about the Vector instance To explore configured Vector topologies We have plans to enhance the API in the coming releases by enabling you to, for example, re-configure Vector via the API. The GraphQL API for Vector is disabled by default. We want to keep Vector's behavior as predictable and secure as possible, so we chose to make the feature opt-in. To enable the API, add this to your Vector config: ```toml [api] enabled = true address = "127.0.0.1:8686" # optional. Change IP/port if required ``` For a more in-depth look at the API, check out: The recent for the API from esteemed Vector engineer . Our [official documentation] The behind the API
Project: Netdata (Observability and Analysis / Observability)
File: httpcheck_web_service_bad_status.md

The `httpcheckwebservicebadstatus` alert is generated by the Netdata Agent when monitoring the status of an HTTP web service using the `httpcheck` collector. This alert is triggered when the HTTP web service returns a non-successful status code (anything other than 2xx or 3xx), indicating that there is an issue with the web service, preventing it from responding to requests as expected. Verify the target URL: Ensure that the target URL configured in the `httpcheck` collector is correct and accessible. Check for any typos or incorrect domain names. Check the actual response status and the expected response status: Try to implement a request with a verbose result: ``` root@netdata # curl -v <yourhttpendpoint>:<port>/<path> ``` Verify server resources: Ensure that your server has enough resources (CPU, RAM, disk space) to handle the current workload. High resource utilization can lead to web service issues. You can use Netdata's dashboard to monitor the server resources in real-time. Check server configuration: Review the configuration files of the web service for any misconfigurations or settings that may be causing the issue. For example, incorrect permissions, wrong file paths, or improper configurations can lead to bad status codes.
Project: Netdata (Observability and Analysis / Observability)
File: adaptec_raid_ld_status.md

This alert is related to the Adaptec RAID controller, which manages the logical device statuses on your RAID configuration. When this alert is triggered in a critical state, it means that a logical device state value is in a degraded or failed state, indicating that one or more disks in your RAID configuration have failed. Data is priceless. Before taking any action, ensure to have necessary backups in place. Netdata is not liable for any loss or corruption of any data, database, or software. Your Adaptec RAID card will automatically start rebuilding a faulty hard drive when you replace it with a healthy one. Sometimes this operation may take some time or may not start automatically. Check if the rebuild process is already running: ``` root@netdata # arcconf GETSTATUS <Controller_num> ``` Replace `<Controller_num>` with the number of your RAID controller. Examine the output of the previous command to find any segments that are idle or missing. If the rebuild process hasn't started automatically, change the logical device (ld) status manually. This action will trigger a rebuild on your RAID: ``` root@netdata # arcconf SETSTATE <Controllernum> LOGICALDRIVE <LDnum> OPTIMAL ADVANCED nocheck noprompt ``` Replace `<Controllernum>` with the number of your RAID controller and `<LDnum>` with the number of the logical device.
Project: HertzBeat (Observability and Analysis / Observability)
File: opengauss.md

id: opengauss title: OpenGauss Database Monitor sidebar_label: OpenGauss Database keywords: [open source monitoring tool, open source database monitoring tool, monitoring opengauss database metrics] Collect and monitor the general performance Metrics of OpenGauss database. | Parameter name | Parameter help description | | -- | -- | | Monitoring Host | Monitored IPV4, IPV6 or domain name. NoteWithout protocol header (eg: https://, http://) | | Monitoring name | Identify the name of this monitoring. The name needs to be unique | | Port | Port provided by the database. The default is 5432 | | Query timeout | Set the timeout time when SQL query does not respond to data, unit: ms, default: 3000ms | | Database name | Database instance name, optional | | Username | Database connection user name, optional | | Password | Database connection password, optional | | URL | Database connection URLoptionalIf configured, the database name, user name, password and other parameters in the URL will overwrite the above configured parameters | | Collection interval | Interval time of monitor periodic data collection, unit: second, and the minimum interval that can be set is 30 seconds | | Whether to detect | Whether to detect and check the availability of monitoring before adding monitoring. Adding and modifying operations will continue only after the detection is successful | | Description remarks | For more information about identifying and describing this monitoring, users can note information here | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | server_version | none | Version number of the database server | | port | none | Database server exposure service port | | server_encoding | none | Character set encoding of database server | | data_directory | none | Database storage data disk address | | max_connections | connections | Database maximum connections | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | name | none | Database name, or share-object is a shared object | | conflicts | times | The number of queries canceled in the database due to a conflict with recovery | | deadlocks | number | Number of deadlocks detected in the database | | blks_read | times | The number of disk blocks read in the database | | blks_hit | times | Times the disk block has been found to be in the buffer, so there is no need to read it once (This only includes hits in the PostgreSQL buffer, not in the operating system file system buffer) | | blkreadtime | ms | Time spent by the backend reading data file blocks in the database | | blkwritetime | ms | Time spent by the backend writing data file blocks in the database | | stats_reset | none | The last time these statistics were reset | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | running | connections | Number of current client connections |
Project: Checkmk (Observability and Analysis / Observability)
File: 16504.md

key | value | date | 2024-02-12T10:44:11+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes There was an error in the nfsiostat plugin where it tried to report some data in units not supported by the graphing system which made viewing its service graphs impossible. This werk changes the units that were reported to our visualizations and now the graphs render all data appropriately.
Project: Checkmk (Observability and Analysis / Observability)
File: 16695.md

key | value | date | 2024-04-17T06:14:37+00:00 version | 2.4.0b1 class | fix edition | cre component | multisite level | 1 compatible | yes The mega menu search produced a crash report if redis was not reachable. Now only an error message is shown.
Project: Kubeinvaders (Observability and Analysis / Chaos Engineering)
File: CONTRIBUTING.md

We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's: Reporting a bug Discussing the current state of the code Submitting a fix Proposing new features Becoming a maintainer We use github to host code, to track issues and feature requests, as well as accept pull requests. Pull requests are the best way to propose changes to the codebase (we use ). We actively welcome your pull requests: Fork the repo and create your branch from `master`. If you've added code that should be tested, add tests. If you've changed APIs, update the documentation. Ensure the test suite passes (play the game!) Make sure your code lints. Issue that pull request! In short, when you submit code changes, your submissions are understood to be under the same that covers the project. Feel free to contact the maintainers if that's a concern. We use GitHub issues to track public bugs. Report a bug by ; it's that easy! Great Bug Reports tend to have: A quick summary and/or background Steps to reproduce Be specific! Give sample code if you can What you expected would happen What actually happens Notes (possibly including why you think this might be happening, or stuff you tried that didn't work) By contributing, you agree that your contributions will be licensed under its Apache 2.0 License.
Project: Checkmk (Observability and Analysis / Observability)
File: 16444.md

key | value | compatible | yes version | 2.3.0b1 date | 2024-01-22T09:32:56+00:00 level | 1 class | fix component | ec edition | cee With werk 16012 the event console rules are filtered and saved to the location var/mkeventd/active_config during activate changes. Unfortunatelly other configuration files like global.mk are missing which are now copied recursively, too.
Project: Checkmk (Observability and Analysis / Observability)
File: 16524.md

key | value | date | 2024-02-21T11:07:55+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes Previously the requests and urllib examples were hard coded to show the same response samples and the same response status codes in the request samples. This werk addresses this issue by showing the correct possible status codes for each endpoint.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: wipro.md

AppAnywhere is an industry-leading managed service from Wipro for customers adopting containers. It addresses the operational and security encounters of multiple Kubernetes clusters and provides managed services for monitoring, logging, and observability of multiple Kubernetes clusters. AppAnywhere is a managed service comprising a set of tightly integrated technologies to deliver end-to-end automation of container-based IT lifecycle to enterprises We do use Litmus to validate and verify the reliability of applications moved into Kubernetes as part of end-to-end automation. The practice of chaos engineering says we have to induce failures into apps in production to detect anomalies. Litmus helps the same. We have included Litmus as part of AppAnyhere Gecko where our customers can run Chaos on their applications and themselves validate the resiliency of their application in the Kubernetes environment. This would help them to capture abnormalities and harden their platform. After incorporating the Litmus in our platform we are able to harden the applications and catch the resiliency issues early. The community is growing and they are able to add new Application specific chaos by the application experts which we believe a scalable model to develop more perfect chaos with respect to the application.
Project: Botkube (Observability and Analysis / Observability)
File: cloud-slack-help.golden.md

:rocket: Botkube instance "Stage US" is now active. Multi-Cluster Specify `--cluster-name=Stage US` flag to run a command on this cluster. Use `--all-clusters` flag to run commands on all clusters. Use Cloud commands to manage connected instances and set per-channel defaults. `{{BotName}} cloud help` Ping your cluster to check its status `{{BotName}} ping` Manage incoming notifications ``` {{BotName}} [enable|disable|status] notifications ``` `{{BotName}} enable notifications` `{{BotName}} disable notifications` `{{BotName}} status notifications` Fine-tune your notifications for this channel `{{BotName}} edit SourceBindings` Automatically execute commands upon receiving events Automation help: https://docs.botkube.io/usage/automated-actions Manage executors and aliases `{{BotName}} list executors` `{{BotName}} list aliases` Executors and aliases help: https://docs.botkube.io/usage/executor Run kubectl commands `{{BotName}} kubectl` `{{BotName}} kubectl help` Run Helm commands `{{BotName}} helm help` Give feedback: https://feedback.botkube.io Read our docs: https://docs.botkube.io Join our Slack: https://join.botkube.io Follow us on Twitter: https://twitter.com/botkube_io