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

At the heart of the Litmus Platform are the chaos custom resources. This section consists of the specification (details of each field within the .spec & .status of the resources) as well as standard examples for tuning the supported parameters. <table> <tr> <th>Chaos Resource Name</th> <th>Description</th> <th>User Guide</th> </tr> <tr> <td>ChaosEngine</td> <td>Contains the ChaosEngine specifications user-guide</td> <td><a href="/litmus/experiments/concepts/chaos-resources/chaos-engine/contents/">ChaosEngine</a></td> </tr> <tr> <td>ChaosExperiment</td> <td>Contains the ChaosExperiment specifications user-guide</td> <td><a href="/litmus/experiments/concepts/chaos-resources/chaos-experiment/contents/">ChaosExperiment</a></td> </tr> <tr> <td>ChaosResult</td> <td>Contains the ChaosResult specifications user-guide</td> <td><a href="/litmus/experiments/concepts/chaos-resources/chaos-result/contents/">ChaosResult</a></td> </tr> <tr> <td>ChaosScheduler</td> <td>Contains the ChaosScheduler specifications user-guide</td> <td><a href="/litmus/experiments/concepts/chaos-resources/chaos-scheduler/contents/">ChaosScheduler</a></td> </tr> <tr> <td>Probes</td> <td>Contains the Probes specifications user-guide</td> <td><a href="/litmus/experiments/concepts/chaos-resources/probes/contents/">Probes</a></td> </tr> </table>
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: signal.md

title: 'Using trace signal' weight: 20 description: > Trace signals received by processes. The trace signal gadget is used to trace system signals received by the pods. First, we need to create one pod for us to play with: ```bash $ kubectl run debian --image debian:latest sleep inf ``` You can now use the gadget, but output will be empty: ```bash $ kubectl gadget trace signal K8S.NODE K8S.NAMESPACE K8S.POD K8S.CONTAINER PID COMM SIGNAL TPID RET ``` Indeed, it is waiting for signals to be sent. So, in another terminal, `exec` the container and send one signal: ```bash $ kubectl exec -ti debian -- sh -c 'sleep 3 & kill -kill $!' ``` Go back to the first terminal and see: ``` K8S.NODE K8S.NAMESPACE K8S.POD K8S.CONTAINER PID COMM SIGNAL TPID RET minikube default debian debian 129484 sh SIGKILL 129491 0 minikube default debian debian 129484 sh SIGHUP 129491 0 minikube default debian debian 129484 sh SIGHUP 129484 0 ``` The first line corresponds to `kill` sending signal `SIGKILL` to `sleep`. You can also use this gadget to trace when processes die with segmentation fault. In the other terminal, `exec` the container with the following: ```bash $ kubectl exec -ti debian -- bash ``` Now, go back to the first terminal and see that `SIGSEGV` was sent to python: ``` minikube default debian debian 142244 python2.7 SIGSEGV 142244 0 ``` Congratulations! You reached the end of this guide! You can now delete the pod you created: ```bash $ kubectl delete pod debian pod "debian" deleted ``` Start the gadget on a terminal. ```bash $ sudo ig trace signal -c test-trace-signal ``` Run a container and run sleep in the background, then will it: ```bash $ docker run -it --rm --name test-trace-signal busybox /bin/sh / # sleep 100 & / # echo $! 7 / # kill -kill $! / # exit ``` The gadget will show that sh killed a process. ```bash $ sudo ig trace signal -c test-trace-signal RUNTIME.CONTAINERNAME PID COMM SIGNAL TPID RET test-trace-signal 11131 sh SIGKILL 11162 0 test-trace-signal 11131 sh SIGHUP 11131 0 ``` With the following option, you can restrict the output: `--pid` only prints events where a signal is sent by the given PID. `--signal` only prints events where the given signal is sent. `-f/--failed-only` only prints events where signal failed to be delivered. `-k/--kill-only` only prints events where signal was sent by using kill syscall. For example, this command will only print failed attempts to send `SIGKILL` by PID `42` which were initiated by calling kill syscall: ```bash $ kubectl gadget -k -f --pid 42 --signal SIGKILL ``` Note that, with `--signal` you can use the name of the signal (e.g. `SIGKILL`) or its integer value (e.g. 9).
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: configure-disk-storage.md

title: "Configure Pyroscope disk storage" menuTitle: "Configure disk storage" description: "" weight: 30 aliases: /docs/phlare/latest/configure-server/configure-disk-storage/ Pyroscope's [ingester] component processes the received profiling data. First it keeps the data organized in memory, in the so-called "head block". Once the size of the head block exceeds a threshold or the head block is older than `-pyroscopedb.max-block-duration` (by default 3 hours), the ingester will write the block to the local persistent disk (see [block format] for more detail about the block's layout). Each of those blocks are identified by an [ULID] and stored within Grafana Pyroscope's data path `-pyroscopedb.data-path=` (by default `./data`). This directory is organized by the following: `./<tenant-id>`: Each tenant has its own subdirectory with the following subdirectories: `head/<block-id>`: Contains the current data still being written. `local/<block-id>`: Contains the finished blocks, which are kept locally When , finished blocks are uploaded to the object store bucket. To avoid losing the most recent data, Pyroscope will remove the oldest blocks when it detects that the volume on which the data path is located is close to running out of disk. This high utilization mode will be active every `-pyroscopedb.retention-policy-enforcement-interval` when: less than `-pyroscopedb.retention-policy-min-disk-available-percentage=0.05` of the total size of the volume is available and the available disk space smaller then `-pyroscopedb.retention-policy-min-free-disk-gb=10`. The deletion will be logged like this: ``` level=warn caller=pyroscopedb.go:231 ts=2022-10-05T13:19:09.770693308Z msg="disk utilization is high, deleted oldest block" path=data/anonymous/local/01GDZYHKKKY2ANY6PCJJZGT1N8 ```
Project: Sensu (Observability and Analysis / Observability)
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 community@sensu.io. 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: Prometheus (Observability and Analysis / Observability)
File: stability.md

title: API Stability sort_rank: 11 Prometheus promises API stability within a major version, and strives to avoid breaking changes for key features. Some features, which are cosmetic, still under development, or depend on 3rd party services, are not covered by this. Things considered stable for 2.x: The query language and data model Alerting and recording rules The ingestion exposition format v1 HTTP API (used by dashboards and UIs) Configuration file format (minus the service discovery remote read/write, see below) Rule/alert file format Console template syntax and semantics Remote write sending, per the . Things considered unstable for 2.x: Any feature listed as experimental or subject to change, including: The Remote write receiving, remote read and the remote read endpoint Server-side HTTPS and basic authentication Service discovery integrations, with the exception of `staticconfigs` and `filesd_configs` Go APIs of packages that are part of the server HTML generated by the web UI The metrics in the /metrics endpoint of Prometheus itself Exact on-disk format. Potential changes however, will be forward compatible and transparently handled by Prometheus The format of the logs As long as you are not using any features marked as experimental/unstable, an upgrade within a major version can usually be performed without any operational adjustments and very little risk that anything will break. Any breaking changes will be marked as `CHANGE` in release notes.
Project: Vector (Observability and Analysis / Observability)
File: 2020-03-03-privacy-policy.md

date: "2020-04-13" title: "We've Added a Privacy Policy" description: "Our commitment to privacy" authors: ["binarylogic"] pr_numbers: [1977, 1976] release: "0.8.1" hideonrelease_notes: true badges: type: "announcement" In addition to our , we've added a new . It's our pledge that Vector will never implement any tactics, gray-area or not, to unknowingly collect data.
Project: HertzBeat (Observability and Analysis / Observability)
File: port.md

id: port title: Monitoringport availability sidebar_label: Port availability keywords: [open source monitoring tool, open source port monitoring tool, monitoring port metrics] Judge whether the exposed port of the opposite end service is available, then judge whether the opposite end service is available, and collect Metrics such as response time for monitoring. | 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 | Ports provided by website, http generally defaults to 80 and https generally defaults to 443 | | Connection timeout | Waiting timeout for port connection, unit:ms, default: 3000ms | | 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 | | -- | -- | -- | | responseTime | ms | Website response time |
Project: Grafana Loki (Observability and Analysis / Observability)
File: decolorize.md

title: decolorize menuTitle: description: The 'decolorize' Promtail pipeline stage. aliases: ../../../clients/promtail/stages/decolorize/ weight: The `decolorize` stage is a transform stage that lets you strip ANSI color codes from the log line, thus making it easier to parse logs further. There are examples below to help explain. ```yaml decolorize: ``` The following is an example showing the use of the `decolorize` stage. Given the pipeline: ```yaml decolorize: ``` Would turn each line having a color code into a non-colored one, e.g. ``` [2022-11-04 22:17:57.811] \033[0;32http\033[0m: GET /_health (0 ms) 204 ``` is turned into ``` [2022-11-04 22:17:57.811] http: GET /_health (0 ms) 204 ```
Project: Netdata (Observability and Analysis / Observability)
File: systemd_target_unit_failed_state.md

The `systemdtargetunitfailedstate` alert is triggered when a `systemd` target unit goes into a failed state. Systemd is the system and service manager for Linux, and target units are groups of systemd units that are organized for a specific purpose. If this alert is triggered, it means there is an issue with one of your systemd target units. A systemd target unit in the failed state means that one or more units/tasks of that target, whether it's a service, or any other kind of systemd unit, have encountered an issue and cannot continue running. First, you need to identify which systemd target unit is causing the alert. You can list all the failed units by running: ``` systemctl --failed --all ``` Once you have identified the problematic target unit, check its status for more information about the issue. Replace `<target_unit>` with the actual target unit name: ``` systemctl status <target_unit> ``` Look at the logs of the failed target unit to collect more details on the issue: ``` journalctl -u <target_unit> ``` Based on the information gathered in steps 2 and 3, troubleshoot and fix the problem(s) in your target unit. This may involve: Editing the unit file Checking the services and processes that compose the target Looking into configuration files and directories. Reload the systemctl daemon to apply any changes you made, then restart the target unit: ``` sudo systemctl daemon-reload sudo systemctl restart <target_unit> ``` Verify that the target unit has been successfully restarted: ``` systemctl is-active <target_unit> ``` Continue monitoring the target unit to ensure that it remains stable and does not return to a failed state.
Project: Elastic APM (Observability and Analysis / Observability)
File: CONTRIBUTING.md

APM Server is open source, and we love to receive contributions from our community you! There are many ways to contribute, from writing tutorials or blog posts, improving the documentation, submitting bug reports and feature requests, or writing code. If you want to be rewarded for your contributions, sign up for the . Each time you make a valid contribution, youll earn points that increase your chances of winning prizes and being recognized as a top contributor. GitHub is reserved for bug reports and feature requests; it is not the place for general questions. If you have a question or an unconfirmed bug, please visit our ; feedback and ideas are always welcome. If you have a bug fix or new feature that you would like to contribute, please find or open an issue first. It's important to talk about what you would like to do, as there may already be someone working on it, or there may be context to be aware of before implementing the change. Development instructions are available in the project . When submitting changes, add an entry to the , describing the enhancement or fix that your PR is adding. Please read our , which includes the information we care about the most when submitting new changes. All feature development and most bug fixes hit the main branch first. Pull requests should be reviewed by someone with commit access. Once approved, the author of the pull request, or reviewer if the author does not have commit access, should "Squash and merge". Before or during review, a committer will label the pull request with `backport-<branch>` for the prior release branches to which the changes should be backported. For example, say the next minor release is 8.2, and a bug fix is implemented which should be backported to 8.1.next. The pull request should be developed against main, with the `backport-8.1` label applied. Once the pull request is merged, it will be automatically backported to the 8.1 branch. Once a version is released, new features are frozen for that minor version and will not be backported. For example, if 7.10 was just released, the soonest a new feature will be released is 7.11, not 7.10.1. Breaking changes may need to wait until the next major version. See for general information about major/minor versions. Bug fixes may be backported on a case by case basis. The committer of the original pull request, typically the author, is responsible for backporting the changes to the target versions. Straightforward backports may be merged without review. As an alternative to backport automation through `backport-<branch>` labels (e.g. when automation fails), we sometimes use . This is a collection of example PRs for additions occuring somewhat frequently.
Project: Thanos (Observability and Analysis / Observability)
File: feature-request.md

name: "\U0001F680 Feature Request" about: Suggest an idea for improving Thanos title: '' labels: "feature request / improvement" assignees: '' <!-- Provide a clear and concise description of what the problem is. For example, "I'm always frustrated when..." Alternatively, an issue can also be linked here. --> (Write your answer here.) <!-- Provide a clear and concise description of what you want to happen. --> (Describe your proposed solution here.) <!-- Let us know about other solutions you've tried or researched. --> (Write your answer here.) <!-- Is there anything else you can add about the proposal? You might want to link to related issues here, if you haven't already. --> (Write your answer here.)
Project: Loggie (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: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-host_related_hostgroup.md

category: Host apiurl: '/api/v1/host/#{host_id}/hostgroup' title: "Get related HostGorup of Host" type: 'GET' sample_doc: 'host.html' layout: default Required ex. /api/v1/host/1647/hostgroup grp_name: hostgroup name ```Status: 200``` ```[ { "id": 78, "grp_name": "tplB", "create_user": "userA" }, { "id": 145, "grpname": "OwlDefault_Group", "create_user": "userA" } ]```
Project: Checkmk (Observability and Analysis / Observability)
File: 16179.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-03-20T10:04:09+00:00 level | 1 class | fix component | checks edition | cre Before the version 2.2.0p21, 'Time left until full' was reported to be 0 in case of devices reporting negative free space. With werk 16330, we stopped reporting the metric in case of very small size changes because it lead to infinite values. With this change the behavior was unintentionally also changed for negative free space values. This werk restores the same functionality in case of negative free space.
Project: Checkmk (Observability and Analysis / Observability)
File: 16039.md

key | value | date | 2024-01-26T11:20:55+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes Previously, when using the effective attributes query parameter with the ``` GET /objects/hostconfig/{hostname} ``` endpoint, only the labels of the current host have been returned. Now all of the effective labels are aggregated and returned.
Project: Keep (Observability and Analysis / Observability)
File: new_provider_request.md

name: New provider request about: Suggest a new provider for keep title: '' labels: 'provider' assignees: '' Describe the provider you want to add Add any context about the tool and the kind of data you would want to pull/push from the provider. Describe your use case Does this integration will help you to use Keep? Are you already using Keep? Yes/No Additional context Add any other context or screenshots about the provider request here.
Project: M3 (Observability and Analysis / Observability)
File: fileset_migrations.md

title: "Fileset Migrations" weight: 20 Occasionally, changes will be made to the format of fileset files on disk. When those changes need to be applied to already existing filesets, a fileset migration is required. Migrating existing filesets is beneficial so that improvements made in newer releases can be applied to all filesets, not just newly created ones. Migrations are executed during the initial stages of the bootstrap. When enabled, the filesystem bootstrapper will scan for filesets that should be migrated and migrate any filesets found. A fileset is determined to be in need of a migration based on the `MajorVersion` and `MinorVersion` found in the info file. If `MajorVersion.MinorVersion` is less than the target migration version, then that fileset will be scheduled for migration. If migrations are deemed necessary, the bootstrap process pauses until the migrations complete. If a failure occurs while migrating, an error is logged and the process continues. If a fileset is not successfully migrated, the non-migrated version of the fileset is used going forward. In other words, whether they succeed or fail, migrations should leave filesets in a good state. Migrations are enabled by setting the following fields in the M3 configuration (`m3dbnode.yml`): ```yaml db: bootstrap: filesystem: migration: targetMigrationVersion: "1.1" concurrency: <# of concurrent workers> ``` <table> <thead> <tr> <th>Version</th> <th>Description</th> </tr> </thead> <tbody> <tr> <td><code>&quot;none&quot;</code></td> <td>Disables migrations. Effectively the same as not including the migration option in the M3 configuration</td> </tr> <tr> <td><code>&quot;1.1&quot;</code></td> <td>Migrates to version 1.1. Version 1.1 adds checksum values to individual entries in the index file of data filesets. This speeds up bootstrapping as validating the index file no longer requires loading and calculating the checksum of the entire file against the value in the digests file.</td> </tr> </tbody> </table>