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

The Fluentd community adheres to the following principles: Open: Fluentd is open source. See repository guidelines and CLA, below. Welcoming and respectful: See Code of Conduct, below. Transparent and accessible: Work and collaboration are done in public. Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, scope, and design principles. The Fluentd project employs "organization voting" to ensure no single organization can dominate the project. Individuals not associated with or employed by a company or organization are allowed one organization vote. Each company or organization (regardless of the number of maintainers associated with or employed by that company/organization) receives one organization vote. In other words, if two maintainers are employed by Company X, two by Company Y, two by Company Z, and one maintainer is an un-affiliated individual, a total of four "organization votes" are possible; one for X, one for Y, one for Z, and one for the un-affiliated individual. Any maintainer from an organization may cast the vote for that organization. For formal votes, a specific statement of what is being voted on should be added to the relevant github issue or PR, and a link to that issue or PR added to the maintainers meeting agenda document. Maintainers should indicate their yes/no vote on that issue or PR, and after a suitable period of time, the votes will be tallied and the outcome noted. New maintainers are proposed by an existing maintainer and are elected by a 2/3 majority organization vote. Maintainers can be removed by a 2/3 majority organization vote. Maintainers will be added to the fluent GitHub organization and added to the GitHub cni-maintainers team, and made a GitHub maintainer of that team. After 6 months a maintainer will be made an "owner" of the GitHub organization. The fluent organization is open to receive new sub-projects under it umbrella. To apply a project as part of the fluent organization, it has to met the following criteria: Licensed under the terms of the Apache License v2.0 Project has been active for at least one year since it inception More than 2 contributors Related to one or more scopes of Fluentd ecosystem: Data collection Log management Metering Be supported by 2/3 majority of organization The submission process starts as a Pull Request on Fluentd repository with the required information mentioned above. Once a project is accepted, it's considered a CNCF sub-project under the umbrella of Fluentd Fluentd follows the CNCF Code of Conduct: https://github.com/cncf/foundation/blob/master/code-of-conduct.md
Project: Grafana Loki (Observability and Analysis / Observability)
File: major-release.md

title: Prepare Major Release description: Describes the process to create a workflow for a major release of Grafana Loki. A major release follows the same process as , but requires a custom workflow to be created to run on the branch we want to release from. The reason for this is that we don't do major releases very often, so it is not economical to keep those workflows running all the time. To create a major release workflow, follow the steps below. Edit `./github/release-workflows.jsonnet` Add a new workflow for the major release. For example, the 3.0 release looked like the following: ```jsonnet 'three-zero-release.yml': std.manifestYamlDoc( lokiRelease.releasePRWorkflow( branches=['release-3.0.0'], buildImage=buildImage, checkTemplate=checkTemplate, golangCiLintVersion=golangCiLintVersion, imageBuildTimeoutMin=imageBuildTimeoutMin, imageJobs=imageJobs, imagePrefix=imagePrefix, releaseLibRef=releaseLibRef, releaseRepo='grafana/loki', skipArm=false, skipValidation=false, useGitHubAppToken=true, releaseAs='3.0.0', ) + { name: 'Prepare Loki 3.0 release', }, false, false ), ``` Make sure the `branches` field is set to the release branch you want to release from. Make sure the `releaseAs` field is set to the version you want to release. Run `make release-workflows` to generate the new workflow. Merge this change to both the main and release branch. You may also want to disable the patch release workflow as part of this PR, see below. Once this new workflow is created there is a bit of a race condition with the patch workflow. This can be resolved in 1 of 2 ways: Disable the patch release workflow until after the major release is complete. Watch all actions for the release branch (ie. <https://github.com/grafana/loki/actions?query=branch%3Arelease-3.0.x>) and cancel and patch release runs.
Project: Krkn (Observability and Analysis / Chaos Engineering)
File: SLOs_validation.md

Pass/fail based on metrics captured from the cluster is important in addition to checking the health status and recovery. Kraken supports: If enabled, the check runs at the end of each scenario ( post chaos ) and Kraken exits in case critical alerts are firing to allow user to debug. You can enable it in the config: ``` performance_monitoring: checkcriticalalerts: False # When enabled will check prometheus for critical alerts firing post chaos ``` Takes PromQL queries as input and modifies the return code of the run to determine pass/fail. It's especially useful in case of automated runs in CI where user won't be able to monitor the system. This feature can be enabled in the by setting the following: ``` performance_monitoring: prometheus_url: # The prometheus url/route is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes. prometheusbearertoken: # The bearer token is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes. This is needed to authenticate with prometheus. enable_alerts: True # Runs the queries specified in the alert profile and displays the info or exits 1 when severity=error. alert_profile: config/alerts.yaml # Path to alert profile with the prometheus queries. ``` A couple of are shipped by default and can be tweaked to add more queries to alert on. User can provide a URL or path to the file in the . The following are a few alerts examples: ``` expr: avgovertime(histogramquantile(0.99, rate(etcddiskwalfsyncdurationseconds_bucket[2m]))[5m:]) > 0.01 description: 5 minutes avg. etcd fsync latency on {{$labels.pod}} higher than 10ms {{$value}} severity: error expr: avgovertime(histogramquantile(0.99, rate(etcdnetworkpeerroundtriptimesecondsbucket[5m]))[5m:]) > 0.1 description: 5 minutes avg. etcd network peer round trip on {{$labels.pod}} higher than 100ms {{$value}} severity: info expr: increase(etcdserverleaderchangesseen_total[2m]) > 0 description: etcd leader changes observed severity: critical ``` Kube-burner supports setting the severity for the alerts with each one having different effects: ``` info: Prints an info message with the alarm description to stdout. By default all expressions have this severity. warning: Prints a warning message with the alarm description to stdout. error: Prints a error message with the alarm description to stdout and makes kube-burner rc = 1 critical: Prints a fatal message with the alarm description to stdout and exits execution inmediatly with rc != 0 ```
Project: Netdata (Observability and Analysis / Observability)
File: btrfs_device_corruption_errors.md

This alert monitors the `corruptionerrs` metric in the `btrfs.deviceerrors` chart. If you receive this alert, it means that your system's BTRFS file system has encountered one or more corruption errors in the past 10 minutes. These errors indicate data inconsistencies on the file system that could lead to data loss or other issues. BTRFS (B-Tree File System) is a modern, fault-tolerant, and highly scalable file system used in several Linux distributions. Corruption errors in a BTRFS file system refer to inconsistencies in the data structures that the file system relies on to store and manage data. Such inconsistencies can stem from software bugs, hardware failures, or other causes. Check for system messages: Review your system's kernel message log (`dmesg` output) for any BTRFS-related errors or warnings. These messages can provide insights into the cause of the corruption and help you diagnose the issue. ``` dmesg | grep -i btrfs ``` Run a file system check: Use the `btrfs scrub` command to scan the file system for inconsistencies and attempt to automatically repair them. Note that this command may take a long time to complete, depending on the size of your BTRFS file system. ``` sudo btrfs scrub start /path/to/btrfs/mountpoint ``` After the scrub finishes, check the status with: ``` sudo btrfs scrub status /path/to/btrfs/mountpoint ``` Assess your storage hardware In some cases, BTRFS corruption errors may be caused by failing storage devices, such as a disk drive nearing the end of its lifetime. Check the S.M.A.R.T. status of your disks using the `smartctl` tool to identify potential hardware issues. ``` sudo smartctl -a /dev/sdX ``` Replace `/dev/sdX` with the actual device path of your disk. Update your system Ensuring that your system has the latest kernel, BTRFS tools package, and other relevant updates can help prevent software-related corruption errors. For example, on Ubuntu or Debian-based systems, you can update with: ``` sudo apt-get update sudo apt-get upgrade ``` Backup essential data As file system corruption might result in data loss, ensure that you have proper backups of any critical data stored on your BTRFS file system. Regularly back up your data to an external or secondary storage device.
Project: Loggie (Observability and Analysis / Observability)
File: MIGRATION_GUIDE.md

Starting from , the import path has changed from `github.com/dgrijalva/jwt-go` to `github.com/golang-jwt/jwt`. Future releases will be using the `github.com/golang-jwt/jwt` import path and continue the existing versioning scheme of `v3.x.x+incompatible`. Backwards-compatible patches and fixes will be done on the `v3` release branch, where as new build-breaking features will be developed in a `v4` release, possibly including a SIV-style import path. In a first step, the easiest way is to use `go mod edit` to issue a replacement. ``` go mod edit -replace github.com/dgrijalva/jwt-go=github.com/golang-jwt/jwt@v3.2.1+incompatible go mod tidy ``` This will still keep the old import path in your code but replace it with the new package and also introduce a new indirect dependency to `github.com/golang-jwt/jwt`. Try to compile your project; it should still work. If your code still consistently builds, you can replace all occurences of `github.com/dgrijalva/jwt-go` with `github.com/golang-jwt/jwt`, either manually or by using tools such as `sed`. Finally, the `replace` directive in the `go.mod` file can be removed. The original migration guide for older releases can be found at https://github.com/dgrijalva/jwt-go/blob/master/MIGRATION_GUIDE.md.
Project: Grafana Loki (Observability and Analysis / Observability)
File: compatibility.md

title: "Compatibility" description: "The Loki Operator supports a number of Kubernetes and Loki releases." lead: "" date: 2022-06-21T08:48:45+00:00 lastmod: 2022-06-21T08:48:45+00:00 draft: false images: [] menu: docs: parent: "operator" weight: 100 toc: true The Loki Operator supports a number of Kubernetes and Loki releases. The Loki Operator uses client-go to communicate with Kubernetes clusters. The supported Kubernetes cluster version is determined by client-go. The compatibility matrix for client-go and Kubernetes clusters can be found . All additional compatibility is only best effort, or happens to still/already be supported. The currently used client-go version is "v0.23.5". Due to the use of CustomResourceDefinitions Kubernetes >= v1.7.0 is required. Due to the use of apiextensions.k8s.io/v1 CustomResourceDefinitions, requires Kubernetes >= v1.16.0. The versions of Loki compatible to be run with the Loki Operator are: v2.7.1 v2.7.2 v2.7.3 v2.7.4 v2.8.0 v2.8.3 v2.9.0 v2.9.1 v2.9.2 v2.9.3 v2.9.4 v2.9.6 v2.9.8
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: sumologic_syslog.md

title: Sumo Logic HTTP 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/56#TOPIC-1829122 This option sets the port number of the Sumo Logic server to connect to. Default: 6514 This option specifies your Sumo Logic deployment.https://help.sumologic.com/APIs/General-API-Information/Sumo-Logic-Endpoints-by-Deployment-and-Firewall-Security Default: empty This option specifies the list of tags to add as the tags fields of Sumo Logic messages. If not specified, syslog-ng OSE automatically adds the tags already assigned to the message. If you set the tag() option, only the tags you specify will be added to the messages. Default: tag The Cloud Syslog Cloud Token that you received from the Sumo Logic service while configuring your cloud syslog source. https://help.sumologic.com/03Send-Data/Sources/02Sources-for-Hosted-Collectors/Cloud-Syslog-Source#configure-a-cloud%C2%A0syslog%C2%A0source Default: - This option sets various options related to TLS encryption, for example, key/certificate files and trusted CA locations. TLS can be used only with tcp-based transport protocols. For details, see https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.37/administration-guide/73#TOPIC-1829193 Default: - This option 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: false Default: -
Project: Vector (Observability and Analysis / Observability)
File: 2020-11-25-json-yaml-config-formats.md

date: "2020-11-25" title: "JSON and YAML config formats are now supported" description: "We've added support for JSON and YAML config formats." authors: ["binarylogic"] pr_numbers: [4856, 5144] release: "0.11.0" hideonrelease_notes: false badges: type: "new feature" domains: ["config"] To ensure Vector fits into existing workflows, like Kubernetes, we've added support for JSON and YAML config formats in addition to TOML. TOML will continue to be our default format, but users are welcome to use JSON and YAML as they see fit. YAML is the preferred language in the K8s ecosystem, and to ensure Vector does not feel awkward in the Kubernetes platform we now support YAML for our pipeline definitions. A bonus to supporting JSON is the enablement of data templating languages like and . For example, a Vector user has already built an for Vector. Use Vector as you normally work, but pass it `yaml` or `json` config files: ```bash vector --config /etc/vector/vector.json ``` Vector will infer the format from the extension. This is especially useful when passing multiple config files via globs: ```bash vector --config /etc/vector/* ``` Additionally, we've provided format specific flags for edge cases: ```bash vector --config-json /etc/vector/vector.json ``` Head over to the for more info.
Project: Centreon (Observability and Analysis / Observability)
File: register.md

This module aims to provide a way to register nodes manually, in opposition to the module. Nodes are either servers running Gorgone daemon or simple equipment with SSH server. There is no specific configuration in the Gorgone daemon configuration file, only a directive to set a path to a dedicated configuration file. | Directive | Description | Default value | | :-- | :- | : | | config\_file | Path to the configuration file listing nodes | | ```yaml name: register package: "gorgone::modules::core::register::hooks" enable: true config_file: config/registernodes.yaml ``` Nodes are listed in a separate configuration file in a `nodes` table as below: | Directive | Description | | :-- | :- | | id | Unique identifier of the node (can be Pollers ID if using prevail option) | | type | Way for the daemon to connect to the node (push\_zmq) | | address | IP address of the node | | port | Port to connect to on the node | | server\_pubkey | Server public key (Default: ask the server pubkey when it connects) | | client\_pubkey | Client public key (Default: use global public key) | | client\_privkey | Client private key (Default: use global private key) | | cipher | Cipher used for encryption (Default: Cipher::AES) | | vector | Encryption vector (Default: 0123456789012345) | | prevail | Defines if this configuration prevails on `nodes` module configuration | | nodes | Table to register subnodes managed by node (pathscore is not mandatory) | ```yaml nodes: id: 4 type: push_zmq address: 10.1.2.3 port: 5556 nodes: id: 2 pathscore: 1 id: 20 pathscore: 10 ``` | Directive | Description | | :-- | : | | id | Unique identifier of the node (can be Pollers ID if using prevail option) | | type | Way for the daemon to connect to the node (push\_ssh) | | address | IP address of the node | | ssh\_port | Port to connect to on the node | | ssh\directory | Path to the SSH directory, used for files like known\hosts and identity (private and public key) | | ssh\known\hosts | Path to the known hosts file | | ssh\_identity | Path to the identity file | | ssh\_username | SSH username | | ssh\_password | SSH password (if no SSH key) | | ssh\connect\timeout | Time is seconds before a connection is considered timed out | | strict\serverkey\check | Boolean to strictly check the node fingerprint | | prevail | Defines if this configuration prevails on `nodes` module configuration | ```yaml nodes: id: 8 type: push_ssh address: 10.4.5.6 ssh_port: 2222 sshidentity: ~/.ssh/thersa_key ssh_username: user strictserverkeycheck: false prevail: 1 ``` No events. No API endpoints.
Project: Vector (Observability and Analysis / Observability)
File: vector-installer.md

title: Install Vector using the Vector installer short: Vector installer The Vector installer enables you to install Vector using a platform-agnostic installation script: ```shell curl --proto '=https' --tlsv1.2 -sSfL https://sh.vector.dev | bash ``` You may use `VECTOR_VERSION` to specify a custom version like below: ```shell curl --proto '=https' --tlsv1.2 -sSfL https://sh.vector.dev | VECTOR_VERSION=0.34.1 bash ``` {{< jump "/docs/administration/management" "vector-executable" >}}
Project: Netdata (Observability and Analysis / Observability)
File: telegram.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/integrations/telegram.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/metadata.yaml" sidebar_label: "Telegram" 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/telegram.svg" width="150"/> From the Cloud interface, you can manage your space's notification settings and from these you can add a specific configuration to get notifications delivered on Telegram. <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> To add Telegram notification you need: A Netdata Cloud account Access to the space as an Admin The Space needs to be on a paid plan The Telegram bot token and chat ID 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 Telegram 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 Telegram: Bot Token - the token of your bot Chat ID - the chat id where your bot will deliver messages to Bot token: To create one bot, contact the bot and send the command `/newbot` and follow the instructions. Start a conversation with your bot or invite it into the group where you want it to send notifications. To get the chat ID you have two options: Contact the bot and send the `/getid` command to get your personal chat ID, or invite it into a group and use the `/getgroupid` command to get the group chat ID. Alternatively, you can get the chat ID directly from the bot API. Send your bot a command in the chat you want to use, then check `https://api.telegram.org/bot{YourBotToken}/getUpdates`, eg. `https://api.telegram.org/bot111122223:7OpFlFFRzRBbrUUmIjj5HF9Ox2pYJZy5/getUpdates`
Project: Vector (Observability and Analysis / Observability)
File: PRIVACY.md

It should go without saying, but Vector takes the privacy of your data, including how you use Vector, very seriously. Vector collects and routes some of your most sensitive data, and therefore, Vector strives to be as transparent as possible with our privacy efforts. This document clarifies how the Vector project thinks about privacy now and in the future. - - Vector uses AWS S3, GitHub assets, and Docker Hub to host release artifacts. Vector does track download counts in aggregate. For GitHub, and Docker this data is anonymous, but for AWS S3 IP addresses are logged. There is no way to disable IP address tracking within the AWS S3 logs. If you are concerned about sharing your IP address we recommend using a proxy, or downloading Vector from a different channel. Vector will not "phone home" or communicate with an external service that you did not explicitly configure. This includes grey-area tactics such as version checks, capturing diagnostic information, and sharing crash reports. The Vector website does collect various analytics. Aggregated analytics data is derived from backend server logs which are anonymized. Vector uses for this. The Vector repository is hosted on GitHub. You can review their privacy policy . Additionally, Vector will not attempt to mine information about users that interact with Vector on GitHub. Vector team members will occasionally reach out to active users offer help debugging or learn about ways Vector can improve. The Vector chat uses Discord; you can review their privacy policy .