cwielenb/CNCF-Dataset huggingface dataset:
Project: Logstash (Observability and Analysis / Observability)
File: test-failure.md

name: Test Failure about: A test failure in CI labels: "test failure" <!-- Please fill out the following information, and ensure you have attempted to reproduce locally --> Build scan: Repro line: Reproduces locally?: Applicable branches: Failure history: <!-- Link to build stats and possible indication of when this started failing and how often it fails <https://build-stats.elastic.co/app/kibana> --> Failure excerpt:
Project: Keep (Observability and Analysis / Observability)
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 `main`. If you've added code that should be tested, add tests. If you've changed APIs, update the documentation. Ensure the test suite passes. 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) People love thorough bug reports. I'm not even kidding. Follow PEP8, use `black` for formatting and `isort` to sort imports. By contributing, you agree that your contributions will be licensed under its MIT License. This document was adapted from the open-source contribution guidelines for
Project: PowerfulSeal (Observability and Analysis / Chaos Engineering)
File: pods-and-hosts.md

layout: default title: Stop a host running particular pod description: "" permalink: /stop-host-running-a-pod parent: Writing policies nav_order: 8 {: .no_toc } {: .no_toc .text-delta } TOC {:toc} You might want to stop a host that runs a particular set of pods. You can do that with `stopHost` action for pods. ```yaml scenarios: name: Stop that host! steps: podAction: matches: namespace: something filters: randomSample: size: 1 actions: stopHost: autoRestart: true wait: seconds: 30 ``` This will stop the host running that pod, and restart at the end of the scenario.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_deployment.KubeDeployment.md

title: "Interface: KubeDeployment" linkTitle: "KubeDeployment" slug: "libk8sdeployment.KubeDeployment" .KubeDeployment `KubeDeployment` `Optional` apiVersion: `string` . _ kind: `string` Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. In CamelCase. Cannot be updated. `see` . _ metadata: . _ spec: `Object` | Name | Type | | : | : | | `selector?` | | | `strategy?` | { `[otherProps: string]`: `any`; `type`: `string` } | | `strategy.type` | `string` | | `template` | { `metadata?`: ; `spec`: } | | `template.metadata?` | | | `template.spec` | | _ status: `Object`
Project: Vector (Observability and Analysis / Observability)
File: buffer.md

This document specifies Vector's buffer behavior for the development of Vector. The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC 2119]. - - - - This specification addresses direct buffer development and does not cover aspects that buffers inherit "for free". For example, this specification does not cover global context, such as component_id, that all buffers receive in their telemetry by nature of being attached to a Vector component. This section extends the [Instrumentation Specification], which should be read first. Vector buffers MUST be instrumented for optimal observability and monitoring. `bytesize` - Refers to the byte size of events from a buffer's perspective. For memory buffers, `bytesize` represents the in-memory byte size of events. For disk buffers, `byte_size` represents the serialized byte size of events. `buffertype` - One of `memory`, `disk`. Buffer metrics MUST be tagged with `buffertype` unless otherwise specified. All buffers MUST emit a `BufferCreated` event upon creation. To avoid stale metrics, this event MUST be regularly emitted at an interval. Properties `maxsizebytes` - the max size of the buffer in bytes if relevant `maxsizeevents` - the max size of the buffer in number of events if relevant Metric MUST emit the `buffermaxeventsize` gauge (in-memory buffers) if the defined `maxsize_events` value is present MUST emit the `buffermaxbytesize` gauge (disk buffers) if the defined `maxsize_bytes` value is present All buffers MUST emit a `BufferEventsReceived` event: upon startup if there are existing events in the buffer. after receiving one or more Vector events. Properties `count` - the number of received events `byte_size` - as defined in Metric MUST increment the `bufferreceivedevents_total` counter by the defined `count` MUST increment the `bufferreceivedbytestotal` counter by the defined `bytesize` MUST increment the `buffer_events` gauge by the defined `count` MUST increment the `bufferbytesize` gauge by the defined `byte_size` All buffers MUST emit a `BufferEventsSent` event after sending one or more Vector events. Properties `count` - the number of sent events `byte_size` - as defined in Metric MUST increment the `buffersentevents_total` counter by the defined `count` MUST increment the `buffersentbytestotal` counter by the defined `bytesize` MUST decrement the `buffer_events` gauge by the defined `count` MUST decrement the `bufferbytesize` gauge by the defined `byte_size` Extends the [Error event]. All buffers MUST emit error events in accordance with the [Error event] requirements. This specification does not list a standard set of errors that components must implement since errors are specific to the buffer and operation. Extends the [EventsDropped event]. All buffers that can drop events MUST emit a `BufferEventsDropped` event in accordance with the [EventsDropped event] requirements.
Project: Checkmk (Observability and Analysis / Observability)
File: 16552.md

key | value | date | 2024-03-28T15:50:10+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes When re-registering agents, a call to activate changes could crash with an error message like ``` [Errno 2] No such file or directory: '/omd/sites/<site>/var/agent-receiver/received-outputs/<uuid> ```
Project: Netdata (Observability and Analysis / Observability)
File: netdata_mobile_app.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/integrations/netdatamobileapp.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/metadata.yaml" sidebar_label: "Netdata Mobile App" 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/netdata.png" width="150"/> From the Netdata Cloud UI, you can manage your user notification settings and enable the configuration to deliver notifications on the Netdata Mobile Application. <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> A Netdata Cloud account You need to have the Netdata Mobile Application installed on your or phone. Steps to login to the Netdata Mobile Application to receive alert and reachability and alert notifications: Download the Netdata Mobile Application from or the Open the App and Choose the Sign In Option Sign In with Email Address: Enter the Email Address of your registered Netdata Cloud Account and Click on the Verification link received by Email on your mobile device. Sign In with QR Code: Scan the QR Code from your `Netdata Cloud` UI under User Settings --> Notifications --> Mobile App Notifications --> Show QR Code Start receiving alert and reachability notifications for your Space(s) on a Paid Subscription plan Click on the User settings on the bottom left of your screen (your profile icon) Click on the Notifications tab Enable Mobile App Notifications if disabled (Enabled by default) Use the Show QR Code Option to login to your mobile device by scanning the QR Code
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-nodata_create.md

category: NoData apiurl: '/api/v1/nodata/' title: "Create Nodata" type: 'POST' sample_doc: 'nodata.html' layout: default Required ```{ "tags": "", "step": 60, "obj_type": "host", "obj": "docker-agent", "name": "testnodata", "mock": -1, "metric": "test.metric", "dstype": "GAUGE" }``` ```Status: 200``` ```{ "id": 4, "name": "testnodata", "obj": "docker-agent", "obj_type": "host", "metric": "test.metric", "tags": "", "dstype": "GAUGE", "step": 60, "mock": -1, "creator": "root" }```
Project: Checkmk (Observability and Analysis / Observability)
File: 16412.md

key | value | date | 2024-03-14T12:54:20+00:00 version | 2.4.0b1 class | fix edition | cre component | omd level | 1 compatible | yes This Werk affects those who are testing the 2.3.0 beta. It affects users, whom have enabled MKPs and then use either `omd update` or `cmk-update-config`. During the pre-update steps of Checkmk all rulesets are loaded, which are part of an MKP. Previously, if an error occurs during this step, then the user is prompted with the following error. ``` 02/05 UI extensions... Error loading rulespecs: [ValueError('cmk.plugins.redfish.rulesets.datasource: boom')] Incompatible local file 'cmk/plugins/redfish/rulesets/datasource.py'. Error: cmk.plugins.redfish.rulesets.datasource: boom You can abort the update process (A) and try to fix the incompatibilities or continue the update (c). Abort the update process? [A/c] ``` Thus, eventhough the file belongs to an MKP, if that file is part of the ruleset API v1, then Checkmk does not correctly recognize that the file belongs to an MKP during the update. Now, Checkmk offers to disable the MKP instead, i.e., ``` You can abort the update process (A) or disable the extension package (d) and continue the update process. Abort the update process? [A/d] ```
Project: Grafana (Observability and Analysis / Observability)
File: drone-pipeline.md

Only people in the Grafana organization can make changes to the Drone pipeline The Drone pipelines are built with , a language which is similar to Python. The Starlark files are located in . Set environment variables `DRONESERVER` and `DRONETOKEN`, which can be found on your . These are used to verify that only Grafana employees can make changes to the pipelines. Install , and use it to format the Starlark files you edit. Open a PR where you can do test runs for your changes. If you need to experiment with secrets, create a PR in the , before opening a PR in the main repo. Run `make drone` after making changes to the Starlark files. This builds the `.drone.yml` file.
Project: Thanos (Observability and Analysis / Observability)
File: sharding.md

By default, all components that read from object store assume that all the operations and functionality should be done based on all the available blocks that are present in the given bucket's root directory. This is in most cases totally fine, however when storing blocks from many `Sources` over long durations in the same bucket the number of objects in a bucket can grow drastically. This means that with time you might want to scale out certain components e.g: Larger number of objects does not matter much, however compactor has to scale (CPU, network, disk, memory) with number of Sources pushing blocks to the object storage. Queries against store gateway which are touching large number of blocks (no matter from what Sources) might be expensive, so it can scale with number of blocks. Similar to this config follows native syntax. Currently, thanos only supports the following relabel actions: keep drop hashmod on `external labels` for all components on `block_id` for store gateway, see this The relabel config is used to filter the relevant blocks every time a Thanos component synchronizes with object storage. If a block is dropped, this means it will be ignored by the component. Currently, only external labels are allowed as sources. The block will be dropped if the output is an empty label set. If no relabel-config is given, all external labels will be kept. Example usages: Ignore blocks which contain the external labels `cluster=A` ```yaml action: drop regex: "A" source_labels: cluster ``` Keep only blocks which contain the external labels `cluster=A` ```yaml action: keep regex: "A" source_labels: cluster ``` We can shard by adjusting which labels should be included in the blocks. For store gateway, we can specify `--min-time` and `--max-time` flags to filter for what blocks store gateway should be responsible for. More details can refer to "Time based partitioning" chapter in .
Project: Checkmk (Observability and Analysis / Observability)
File: 16503.md

key | value | date | 2024-03-11T08:55:56+00:00 version | 2.4.0b1 class | feature edition | cre component | rest-api level | 1 compatible | no Starting with the 2.3, the bulk discovery mode has been split up for more granular control regarding the discovery execution. This werk now introduces the same approach to the equivalent REST API bulk discovery endpoint introducing the 'options' field. The previous 'mode' field is deprecated with the 2.3 and will be removed in 2.4. The user should migrate existing scripts to make use of the 'options' field.
Project: Netdata (Observability and Analysis / Observability)
File: httpcheck_web_service_no_connection.md

This alert monitors the percentage of failed HTTP requests to a specific URL in the last 5 minutes. If you receive this alert, it means that your web service experienced connection issues. Verify HTTP service status Check if the web service is running and accepting requests. If the service is down, restart it and monitor the situation. Review server logs Examine the logs of the web server hosting the HTTP service. Look for any errors or warning messages that may provide more information about the cause of the connection issues. Check network connectivity If the server hosting the HTTP service is experiencing connectivity issues, it can lead to failed requests. Ensure that the server has stable network connectivity. Monitor server resources Inspect the server's resource usage to check if it is running out of resources, such as CPU, memory, or disk space. If the server is running low on resources, it can cause the HTTP service to malfunction. In this case, free up resources or upgrade the server. Review client connections It is also possible that the clients are having connectivity issues. Make sure that the clients are in a good network condition and can connect to the server without any issues. Test the HTTP service Perform HTTP requests to the service manually or using monitoring tools to measure response times and verify if the issue persists.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: fis.md

is an American multinational corporation which offers a wide range of financial products and services. We at FIS Global, have been embarking on to larger SRE program to transform platform teams from purely operations focused to bring in SRE/Automation culture and mindset. As part of that larger effort, Chaos/Resiliency Engineering is identified as key program to improve stability and availability thus improve overall reliability of applications across organization and provide superior customer experience. We have chosen Litmus as a Chaos Engineering Tool because, It Fulfills all of resiliency testing requirements Has good and responsive community Has good documentation is built on loosely coupled architecture Has nice dashboard features Exposes APIs to integrate with CI/CD pipelines Currently, using in Applications/Workloads but idea is to expand to Infrastructure, e.g. using network latency to identify and understand resiliency of upstream application/component when downstream application/component is slow, Use Pod delete under production load to understand the application's ability to self heal. Simulate experiments using Litmus to understand utilization of JVM's key resources such as thread pool, connection pool, heap memory etc Kafka Resiliency : Kafka itself is a complex distributed architecture solution, planning to use Litmus network and memory hog experiments to simulate latency between Producer and Broker, Consumer and Broker, Leader and Follower, and also trying to understand how cluster behaves under Memory and CPU pressure. Integrate Litmus with CI/CD over APIs so that Chaos Testing can be autonomous
Project: Netdata (Observability and Analysis / Observability)
File: mattermost.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/integrations/mattermost.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/metadata.yaml" sidebar_label: "Mattermost" 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/mattermost.png" width="150"/> From the Netdata Cloud UI, you can manage your space's notification settings and enable the configuration to deliver notifications on Mattermost. <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 permissions on Mattermost to add new integrations. You need to have a Mattermost app on your workspace to receive the webhooks. Steps to configure your Mattermost to receive notifications from Netdata: In Mattermost, go to Product menu > Integrations > Incoming Webhook If you dont have the Integrations option, incoming webhooks may not be enabled on your Mattermost server or may be disabled for non-admins. They can be enabled by a System Admin from System Console > Integrations > Integration Management. Once incoming webhooks are enabled, continue with the steps below. Select Add Incoming Webhook and add a name and description for the webhook. The description can be up to 500 characters Select the channel to receive webhook payloads, then select Add to create the webhook You will end up with a webhook endpoint that looks like below: `https://your-mattermost-server.com/hooks/xxx-generatedkey-xxx` Treat this endpoint as a secret. Anyone who has it will be able to post messages to your Mattermost instance. For more details please check Mattermost'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 Mattermost 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 Mattermost: Webhook URL - URL provided on Mattermost for the channel you want to receive your notifications
Project: Kubeinvaders (Observability and Analysis / Chaos Engineering)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at eugenio.marzo@yahoo.it. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq
Project: Elastic (Observability and Analysis / Observability)
File: atan2.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> The angle between the positive x-axis and the ray from the origin to the point (x , y) in the Cartesian plane, expressed in radians. ``` ROW y=12.9, x=.6 | EVAL atan2=ATAN2(y, x) ```