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

This alert monitors the current number of tubes on a Beanstalk server. If the number of tubes drops below 5, you will receive a warning. Tubes are used as queues for jobs in Beanstalk, and having a low number of tubes may indicate an issue with service configuration or job processing. Beanstalk is a simple, fast work queue service that allows you to distribute tasks among different workers. In Beanstalk, tubes are essentially queues for jobs. Each tube stores jobs with specific priorities, Time-to-run (TTR) values, and other relevant data. Workers can reserve jobs from specific tubes, process the jobs, and delete them when finished. Check Beanstalk server status. Use the following command to display the current Beanstalk server status: ``` beanstalkctl stats ``` Look for the current number of tubes (`current-tubes`). If it is too low (below 5), proceed to the next step. Identify recently deleted tubes. Determine if any tubes have been deleted recently. Check your application logs, Beanstalk daemon logs, or discuss with your development team to find out if any tube deletion is intentional. Check for misconfigurations or code issues. Inspect your Beanstalk server configuration and verify that the expected tubes are correctly defined. Additionally, review the application code and deployment scripts to ensure that tubes are being created and used as intended. Check worker status and processing. Verify that your worker processes are running and processing jobs from the tubes correctly. If there are issues with worker processes, it may lead to unused or unprocessed tubes. Create missing tubes if necessary. If you've identified that some tubes are missing and need to be created, add the required tubes using your application code or Beanstalk configuration.
Project: InfluxData (Observability and Analysis / Observability)
File: developer_experience.md

name: Developer experience problem about: Tell us about slow builds, tests, and code editing <!-- Thank you for sharing your development experience concerns with the InfluxDB IOx team. Have your read the contributing guide? https://github.com/influxdata/influxdb/blob/main/CONTRIBUTING.md We welcome your thoughts and feedback on the IOx developer experience. In particular: Is your code editor sluggish? How long does your edit-build or edit-test cycle take? Is your cardboard sword wearing out faster than usual? We especially welcome your experience improving your development environment. Which hardware tradeoffs work best? Which code editor and plugins have been helpful? Suggest build configuration or code organization tweaks? Thank you! --> <!-- Be descriptive, write a few sentences describing the difficult (or positive) developer experience. --> <!-- For example: git checkout deadbeef cargo clean cargo build --offline ... --> ... ... ... ... <!-- For example: Build time less than 5 minutes --> <!-- For example: Build time 15m32s --> <!-- Describe the hardware you are developing on. --> Package: ... <!-- laptop, workstation, cloud VM, etc --> CPU: ... Memory: ... Block Device: ... <!-- If Unix-like, then the command `uname -a` is ideal. --> <!-- Describe your IDE or code editor, with version. Some examples: vim 8.2 IntelliJ CLion 2021.2.3 VS Code 1.61.0 --> [ ] I'm using sccache <!-- Describe your build environment. Some examples: IDE build trigger IDE debug trigger bash: cargo build zsh: cargo build --release -->
Project: Checkmk (Observability and Analysis / Observability)
File: 16366.md

key | value | date | 2024-02-09T07:06:04+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes Before this Werk, an status code 500 Internal Server Error was returned when creating a rule without conditions or properties. This Werk fixes it and now it is possible to create a rule in such conditions.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-0-2.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 8.0.2 <!-- Auto generated by update changelog github action --> Datasource: Add support for maxconnsper_host in dataproxy settings. , Configuration: Fix changing org preferences in FireFox. , PieChart: Fix legend dimension limits. , Postgres/MySQL/MSSQL: Fix panic in concurrent map writes. , Variables: Hide default data source if missing from regex. ,
Project: Vector (Observability and Analysis / Observability)
File: 2020-10-27-kubernetes-integration.md

date: "2020-10-27" title: "First-class Kubernetes integration" description: "Vector officially supports Kubernetes with a first-class integration." authors: ["binarylogic"] featured: true pr_numbers: [1314] release: "0.11.0" hideonrelease_notes: false badges: type: "featured" domains: ["platforms"] platforms: ["kubernetes"] After eight months of development, , and intensive QA in clusters producing over 30 terabytes per day, were pleased to announce Vector's first-class Kubernetes integration. It is our intent for Vector to become the single, best platform for collecting and processing all Kubernetes observability data. - A new source designed to handle the intricacies of Kubernetes log collection. It'll collect all Pod logs, merge split logs together, and enrich them with k8s metadata. - To ensure Vector fits cleanly into your existing K8s workflows, Vector now accepts YAML and JSON config formats. - A new Vector feature designed to automatically optimize HTTP communication in the face of ever changing environments like Kubernetes. It does away with static rate limits and raises the performance and reliability of your entire observability infrastructure by monitoring downstream service performance. To get started, follow the install instructions:
Project: HertzBeat (Observability and Analysis / Observability)
File: ssl_cert.md

id: ssl_cert title: Monitoring SSL Certificate sidebar_label: SSL Monitor keywords: [open source monitoring tool, open source ssl cert monitoring tool, monitoring website ssl metrics] Monitor the website's SSL certificate expiration time, response time and other Metrics | Parameter name | Parameter help description | | -- | -- | | Monitoring Host | The peer IPV4, IPV6 or domain name to be monitored. Note Without protocol header (eg: https://, http://). | | Monitoring name | The name that identifies this monitoring, and the name needs to be unique. | | Port | The port provided by the website, https generally defaults to 443. | | Relative path | The suffix path of the website address except the IP port, for example, `www.tancloud.cn/console` The relative path of the website is `/console`. | | Acquisition Interval | Interval time for monitoring periodic data collection, in seconds, 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, and the operation of adding and modifying will continue after the detection is successful | | Description Remarks | More remark information to identify and describe this monitoring, users can remark information here | | Metric Name | Metric Unit | Metric Help Description | | -- ||-| | subject | none | certificate name | | expired | no | expired or not | | start_time | None | Validity start time | | start_timestamp | ms millisecond | Validity start timestamp | | end_time | None | Expiration time | | end_timestamp | ms milliseconds | expiration timestamp |
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_queue_message_drop.md

This alert monitors the number of dropped messages in VerneMQ due to full message queues within the last minute. If you receive this alert, it means that message queues are full and VerneMQ is dropping messages. This can be a result of slow consumers, slow VerneMQ performance, or fast publishers. Check the message queue length and performance metrics of VerneMQ Monitor the current message queue length for each topic by using the command: ``` vmq-admin metrics show | grep queue | sort | uniq -c ``` You can also monitor VerneMQ performance metrics like CPU utilization, memory usage, and network I/O by using the `top` command: ``` top ``` Identify slow consumers, slow VerneMQ, or fast publishers Analyze the message flow and performance data to determine if the issue is caused by slow consumers, slow VerneMQ performance, or fast publishers. Slow Consumers: If you identify slow consumers, consider optimizing their processing capabilities or scaling them to handle more load. Slow VerneMQ: If VerneMQ itself is slow, consider optimizing its configuration, increasing resources, or scaling the nodes in the cluster. Fast Publishers: If fast publishers are causing the issue, consider rate-limiting them or breaking their input into smaller chunks. Increase the queue length or adjust maxonlinemessages If increasing the capacity of your infrastructure is not a viable solution, consider increasing the queue length or adjusting the `maxonlinemessages` value in VerneMQ. This can help mitigate the issue of dropped messages due to full queues. Update the VerneMQ configuration file (`vernemq.conf`) to set the desired `maxonlinemessages` value: ``` maxonlinemessages=<yourdesiredvalue> ``` Then, restart VerneMQ to apply the changes: ``` sudo service vernemq restart ``` Monitor the situation Continue to monitor the message queue length and VerneMQ performance metrics after making changes, to ensure that the issue is resolved or mitigated.
Project: PowerfulSeal (Observability and Analysis / Chaos Engineering)
File: autonomous.md

layout: default title: Autonomous nav_order: 3 description: "" permalink: /autonomous-mode parent: Modes {: .no_toc } {: .no_toc .text-delta } TOC {:toc} Autonomous mode is the workhorse of the seal. Once you know what kind of experiment you're after, you can write a yaml file to describe that. For more information on running the autonomous mode, see the help: ```sh $ seal autonomous --help ``` To learn how to write policies, visit the Autonomous mode also comes with the ability for metrics useful for monitoring to be collected. PowerfulSeal currently has a `stdout`, Prometheus and Datadog collector. However, metric collectors are easily extensible so it is easy to add your own. More details can be found . For example, getting prometheus metrics is as simple as adding the flag `--prometheus-collector` when starting the seal. If you're not going to use the UI, use the flag `--headless` to disable it PowerfulSeal comes with a web interface to help you navigate Autonomous Mode. Features include: viewing logs viewing the policy ](https://github.com/powerfulseal/powerfulseal/blob/master/docs/media/web.png)
Project: Grafana Mimir (Observability and Analysis / Observability)
File: deploying-monitoring-mixin.md

aliases: ../../operators-guide/monitoring-grafana-mimir/deploying-monitoring-mixin/ ../../operators-guide/visualizing-metrics/deploying-monitor-mixin/ ../../operators-guide/monitor-grafana-mimir/deploying-monitoring-mixin/ description: Learn how to deploy the Grafana Mimir monitoring mixin. menuTitle: Deploying the monitoring mixin title: Deploying the Grafana Mimir monitoring mixin weight: 20 Grafana Mimir exposes a `/metrics` endpoint returning Prometheus metrics. You can configure your Prometheus server to scrape Grafana Mimir or you can use the built-in functionality of the . The endpoint is exposed on the Mimir HTTP server address / port which can be customized through `-server.http-listen-address` and `-server.http-listen-port` CLI flags or their respective YAML . Grafana Mimir is shipped with a comprehensive set of production-ready Grafana dashboards and alerts to monitor the state and health of a Mimir cluster. Dashboards provide both a high-level and in-depth view of every aspect of a Grafana Mimir cluster. You can take a look at all the available dashboards in . Alerts allow you to monitor the health of a Mimir cluster. For each alert, we provide detailed to further investigate and fix the issue. The lists prerequisites for using the Grafana Mimir dashboards and alerts. The show available options to install Grafana Mimir dashboards and alerts.
Project: Checkmk (Observability and Analysis / Observability)
File: 16395.md

key | value | date | 2024-01-18T09:22:17+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes In Werk , we replaced the "less than" comparison by the "less or equal" comparison. This is not consistent with how Checkmk handles lower levels, despite what the Werk claims. This Werk restores the old behavior before Werk . Note, that Werk also uncovered some Cisco devices, which report faulty thresholds for "less or equal". These thresholds are now ignored again.
Project: Netdata (Observability and Analysis / Observability)
File: sctp_statistics.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/integrations/sctp_statistics.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/metadata.yaml" sidebar_label: "SCTP Statistics" learn_status: "Published" learnrelpath: "Collecting Metrics/Linux Systems/Network" 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/network-wired.svg" width="150"/> Plugin: proc.plugin Module: /proc/net/sctp/snmp <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> This integration provides statistics about the Stream Control Transmission Protocol (SCTP). 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 scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | sctp.established | established | associations | | sctp.transitions | active, passive, aborted, shutdown | transitions/s | | sctp.packets | received, sent | packets/s | | sctp.packet_errors | invalid, checksum | packets/s | | sctp.fragmentation | reassembled, fragmented | packets/s | There are no alerts configured by default for this integration. No action required. There is no configuration file. There are no configuration options. There are no configuration examples.
Project: Kiali (Observability and Analysis / Observability)
File: troubleshooting.md

The project Kiali has four release pipelines mentioned in the release document. These pipelines have similarities but also some differences. For this reason, there will be common things to look at in case of errors but also some different things and actions to take according to each pipeline. An important step to check for all of the pipelines is the initialize job, specifically the "Log information" step. The following is an example of a release execution, where the inputs are logged to help troubleshooting. It indicates the inputs that will make the pipeline behave accordingly. Release type: minor Release version: v1.54.0 Next version: v1.55.0 Branch version: v1.54 Quay tag: quay.io/kiali/kiali:v1.54.0 quay.io/kiali/kiali:v1.54 With this information, the person troubleshooting would know the type of release (is a minor, a patch?), the release version, the next version and also the tags for pushing the images. The Kiali server pipeline has jobs to build the backend, the frontend, test both of them and also jobs to run integration tests on both too. The jobs are: build_backend build_frontend integrationtestsbackend integrationtestsfrontend If some error occurs in these jobs, there is nothing to amend or fix. The errors can occur because of a failure test, a transient situation with the integration tests or some problem in GitHub infrastructure. The Kiali server and Kiali operator shares a very similar last job, the one that makes the release, called "release", where the release versions are set in the code, the images are built and pushed, the tag is pushed, the release is created, the preparation for the next version is made and if this is a minor release, a PR is generated targeting master to update the versions with the next ones. In case of errors in any of these steps, the log should be inspected to check what was the last action the pipeline executed. The pipelines are not idempotent so to retry them if there was a failure in the release step, manual amends should be done to prepare the next run: Delete the tags and the release on GitHub (if exists) Revert the commits made by the pipeline on the version branch (if there are commits made by kiali-bot on the same time around the pipeline run) Delete the PR generated if exists The Helm charts pipeline has a "release" job that in case of errors, the log should be inspected to check what was the last action the pipeline executed. The manual actions to do in case of a failure are: Delete the $RELEASE_VERSION-main branch (if exists) Revert the last commit in the $RELEASE_VERSION branch (if there is one made by kiali-bot on the same time around the pipeline run) Delete the tags $RELEASEVERSION and $RELEASEVERSION-master (if exist) Delete the PR generated (if exists) The Kiali.io pipeline has a "release" job that in case of errors, the log should be inspected to check what was the last action the pipeline executed. The manual actions to do in case of a failure are: Delete the $RELEASE_VERSION branch (if exists) Revert the last commits made by kiali-bot on the staging branch
Project: Tracetest (Observability and Analysis / Observability)
File: tracetest_apply.md

Apply resources Apply (create/update) resources to your Tracetest server ``` tracetest apply analyzer|config|datastore|demo|env|organization|pollingprofile|test|testrunner|testsuite|variableset [flags] ``` ``` -f, --file string path to the definition file -h, --help help for apply ``` ``` -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 ``` - CLI to configure, install and execute tests on a Tracetest server
Project: Netdata (Observability and Analysis / Observability)
File: memcached_cache_fill_rate.md

This alert, `memcachedcachefill_rate`, measures the average rate at which the Memcached cache fills up (positive value) or frees up (negative value) space over the last hour. The units are in `KB/hour`. If you receive this alert, it means that your Memcached cache is either filling up or freeing up space at a noticeable rate. Memcached is a high-performance, distributed memory object caching system used to speed up web applications by temporarily storing frequently-used data in RAM. It reduces the load on the database and improves performance by minimizing the need for repeated costly database queries. Check the current cache usage: You can view the current cache usage using the following command, where `IP` and `PORT` are the Memcached server's IP address and port number: ``` echo "stats" | nc IP PORT ``` Look for the `bytes` and `limit_maxbytes` fields in the output to see the current cache usage and the maximum cache size allowed, respectively. Identify heavy cache users: Find out which applications or services are generating a significant number of requests to Memcached. You may be able to optimize them to reduce cache usage. You can check Memcached logs for more details about requests and operations. Optimize cache storage: If the cache is filling up too quickly, consider optimizing your cache storage policies. For example, you can adjust the expiration times of stored items, prioritize essential data, or use a more efficient caching strategy. Increase the cache size: If needed, you can increase the cache size to accommodate a higher fill rate. To do this, stop the Memcached service and restart it with the `-m` option, specifying the desired memory size in megabytes: ``` memcached -d -u memcached -m NEW_SIZE -l IP -p PORT ``` Replace `NEW_SIZE` with the desired cache size in MB.
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: install-linux.md

title: Installing on Linux weight: 20 description: > How to install Inspektor Gadget on Linux <!-- toc --> * <!-- /toc --> The tool can be built and installed independently. The result is a single binary (statically linked) that can be copied to a Kubernetes node or any host to trace its containers. It is possible to download the asset for a given release and platform from the . For instance, to download the latest release for linux-amd64: ```bash $ IGVERSION=$(curl -s https://api.github.com/repos/inspektor-gadget/inspektor-gadget/releases/latest | jq -r .tagname) $ IG_ARCH=amd64 $ curl -sL https://github.com/inspektor-gadget/inspektor-gadget/releases/download/${IGVERSION}/ig-linux-${IGARCH}-${IG_VERSION}.tar.gz | sudo tar -C /usr/local/bin -xzf - ig $ ig version ``` `ig` is built using a Docker container relying on , so you don't have to worry about installing dependencies: ```bash $ make ig $ sudo cp ig /usr/local/bin/ ``` Inspektor Gadget has some experimental features disabled by default. Users can enable those features, however they don't provide any stability and could be removed at any time. Experimental features can be enabled in `ig` by using the `IG_EXPERIMENTAL` env variable. ```bash $ sudo IG_EXPERIMENTAL=true ig trace exec INFO[0000] Experimental features enabled ... $ export IG_EXPERIMENTAL=true $ sudo -E ig trace exec INFO[0000] Experimental features enabled ... ```
Project: Grafana (Observability and Analysis / Observability)
File: SUPPORT.md

First, check the official . If you require further help or support then ask a question in the or . You can also search the community site for previously answered questions, in case someone already had your problem and got help. Please note: The Grafana project uses GitHub mainly for tracking bugs and feature requests. Do not open an issue just to ask a question. The issue will be closed immediately. Only submit issues for bug reports, feature requests, or enhancements.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: syslog.md

title: syslog-ng syslog (rfc5424) output weight: 200 generated_file: true More info at https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.37/administration-guide/32#kanchor2338 Documentation: https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.37/administration-guide/56#TOPIC-1829124 Address of the destination host Default: - The port number to connect to. Default: - Specifies the protocol used to send messages to the destination server. Default: - By default, syslog-ng OSE closes destination sockets if it receives any input from the socket (for example, a reply). If this option is set to no, syslog-ng OSE just ignores the input, but does not close the socket. Default: - Flags influence the behavior of the destination driver. Default: - Specifies how many lines are flushed to a destination at a time. Default: - Enables keep-alive messages, keeping the socket open. Default: - Specifies the number of seconds syslog-ng waits for identical messages. Default: - Specifies a template defining the logformat to be used in the destination. Default: 0 Turns on escaping for the ', ", and backspace characters in templated output files. Default: - Sets various options related to TLS encryption, for example, key/certificate files and trusted CA locations. Default: - Override the global timestamp format (set in the global ts-format() parameter) for the specific destination. Default: - Enables putting outgoing messages into the disk buffer of the destination to avoid message loss in case of a system failure on the destination side. Default: - Unique name for the syslog-ng driver Default: -