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

key | value | date | 2024-03-08T14:57:50+00:00 version | 2.4.0b1 class | security edition | cre component | checks level | 1 compatible | yes The informix database monitoring plugin would previously `eval` statements parsed from `$INFORMIXDIR/bin/onstat`. Since the plugin is usually run as root, this could cause statements injected in `$INFORMIXDIR/bin/onstat` to be run as root as well. By adding scripts named the same as other functionality found in `$PATH` to `$INFORMIXDIR/bin`, `$PATH` functionality could also be overshadowed and the custom executed as root. Finally, `$INFORMIXDIR/bin/onstat` would be executed as root, allowing a substituted script to be run with elevated privileges. With this werk, the environment variables will be exported instead and `$PATH` will now be searched before `$INFORMIXDIR/bin`. The plugin will now also check if `$INFORMIXDIR/bin/onstat` belongs to root if the plugin is executed as root. If not, it will be executed as the user owning the executable. This issue was found during internal review. Affected Versions: 2.3.0 (beta) 2.2.0 2.1.0 2.0.0 (EOL) Vulnerability Management: We have rated the issue with a CVSS Score of 8.8 (High) with the following CVSS vector: `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H` and assigned CVE `CVE-2024-28824`.
Project: Vector (Observability and Analysis / Observability)
File: 2022-03-28-kube-for-kubernetes_logs.md

date: "2022-03-28" title: "`kube` for `kubernetes_logs`" description: "The `kubernetes_logs` source is now powered by the `kube-rs` library" authors: ["spencergilbert"] pr_numbers: [11714] release: "0.21.0" hideonrelease_notes: false badges: type: breaking change Our `kubernetes_logs` source has been updated to use as the foundations of our integration. `kube-rs` is a CNCF Sandbox Project and has served as the basis of a number of applications that work with the Kubernetes API. We made this change to improve the reliability and stability of our `kubernetes_logs` source and to ensure our compatibility with the Kubernetes API as it evolves. There are two user facing changes for this update: the `list` verb permission is now required for Vector's ClusterRole within the Kubernetes cluster, and the options are no longer used for the client. The has been updated to include this new verb as of `0.7.0`, and the Kustomize based manifests in the `vector` repo have been updated as part of the `0.21.0` release. If you are managing your own manifests separately you need to ensure the ClusterRole used by Vector includes both the `list` and `watch` verbs for `pods` and `namespaces`. A custom `kubeconfig` should now be provided to leverage any internal proxy you use to interact with the Kubernetes API, rather than the `proxy` option previously available to this source.
Project: Netdata (Observability and Analysis / Observability)
File: consul_client_rpc_requests_failed.md

This alert is triggered when the number of failed RPC (Remote Procedure Call) requests made by the Consul server in a datacenter surpasses a specific threshold. Consul is a service mesh solution and is responsible for discovering, configuring, and segmenting services in distributed systems. Remote Procedure Call (RPC) is a protocol that allows one computer to execute remote procedures (subroutines) on another computer. In the context of Consul, clients make RPC requests to servers to obtain information about the service configurations or to execute actions. When Consul's client RPC requests fail, it means that there is an issue in the communication between the Consul client and the server. It could be due to various reasons like network issues, incorrect configurations, high server load, or even software bugs. Verify the connectivity between Consul clients and servers. Check the network connections between the Consul client and the server. Ensure that the required ports are open and the network is functioning correctly. You can use tools like `ping`, `traceroute`, and `telnet` to verify connectivity. Check Consul server logs. Analyze the Consul server's logs to look for any error messages or unusual patterns related to RPC requests. Server logs can be found in the default Consul log directory, usually `/var/log/consul`. Review Consul client and server configurations. Ensure that Consul client and server configurations are correct and in accordance with the best practices. You can find more information about Consul's configuration recommendations . Monitor server load and resources. High server load or resource constraints can cause RPC request failures. Monitor your Consul servers' CPU, memory, and disk usage. If you find any resource bottlenecks, consider adjusting the server's resource allocation or scaling your Consul servers horizontally. Update Consul to the latest version. Software bugs can lead to RPC request failures. Ensure that your Consul clients and servers are running the latest version of Consul. Check the for the latest version.
Project: Checkmk (Observability and Analysis / Observability)
File: 16209.md

key | value | date | 2023-12-20T08:56:08+00:00 version | 2.3.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes This Werk fixes a performance issue that occurred when creating downtimes for services in a distributed monitoring environment.
Project: Elastic (Observability and Analysis / Observability)
File: to_degrees.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Converts a number in radians to degrees. ``` ROW rad = [1.57, 3.14, 4.71] | EVAL deg = TO_DEGREES(rad) ```
Project: Grafana Mimir (Observability and Analysis / Observability)
File: v4.4.md

title: "Grafana Mimir Helm chart version 4.4 release notes" menuTitle: "V4.4 release notes" description: "Release notes for Grafana Mimir Helm chart version 4.4" weight: 300 Grafana Labs is excited to announce version 4.4 of the Grafana Mimir Helm chart, which is compatible with Grafana Mimir v2.8 or Grafana Enterprise Metrics (GEM) v2.8. The `mimir-distributed` Helm chart is the best way to install Mimir on Kubernetes. To learn about new features and enhancements in Grafana Mimir or GEM, see the release notes for or . The highlights that follow include the top features, enhancements, and bugfixes in this release. For a comprehensive list of changes, see the . Note: If you are upgrading from a previous major version, review the changelog entry for all the major releases since then and perform the necessary migrations. Store-gateway rollout is sped up by setting unregisteronshutdown for store-gateway to false by default. Notable enhancements are as follows: Add support for Vault Agent When enabled, the Pod annotations for TLS configurable components are updated to allow a running Vault Agent to fetch secrets from Vault and to inject them into a Pod. The annotations are updated for the following components: `admin-api`, `alertmanager`, `compactor`, `distributor`, `gateway`, `ingester`, `overrides-exporter`, `querier`, `query-frontend`, `query-scheduler`, `ruler`, `store-gateway`. Default pod security context Set default pod security context under `rbac.podSecurityContext` for easier install on OpenShift. Configure `storageClass` per zone You can now configure `storageClass` per zone for Alertmanager, StoreGateway and Ingester. Allow for deploying mixin dashboards as part of the helm chart If enabled, a ConfigMap will be created for each dashboard which can be used for Grafana. Allow definition of multiple topology spread constraints Backwards compatibility is kept by supporting the old object/dict syntax next to the new array based syntax. : Fix route to service port mapping. Include podAnnotations on the tokengen Job. : Add http port in ingester and store-gateway headless services. Set `gateway` and `nginx` HPA MetricTarget type to Utilization to align with usage of averageUtilization. Add missing imagePullSecrets configuration to the `graphite-web` deployment template.
Project: Checkmk (Observability and Analysis / Observability)
File: bandit-exclusions.md

The following table contains the reasoning behind Bandit exclusions in our source code. All exclusions should be marked using `# nosec <rule id> # <bns id>` in the code. Note that Bandit is picky about the exact format. | Bandit nosec ID | Bandit Rule | Exclusion Reason | | | | | | `BNS:aee528` | `B102` | Config file data would be in an expected format however alternatives handle process threads different which may impact timings or cause hanging when loading configurations. | | `BNS:a29406` | `B102` | User defined input expected within executed files such as custom entries within agent plugin .cfg files. | | `BNS:c29b0e` | `B103` | A python file is compiled and marked as executable. | | `BNS:ce45cd` | `B103` | Creates a spoolfile, this is probably ought to be deleted by the other process. | | `BNS:7e6b08` | `B103` | We set the traverse permission on a folder, since there are files which needs to be world accessible.| | `BNS:537c43` | `B104` | Comparison against "0.0.0.0", if true then the address is set to "127.0.0.1". | | `BNS:7a2427` | `B108` | False positive, the temp file/directory is located inside a safe directory. | | `BNS:773085` | `B113` | Timeout policy to be reviewed. | | `BNS:9a7128` | `B301` | `ObjectStore` has a pickle serializer which it uses to store and load files from disk. To mitigate the risks, it makes sure that only non-world-writable files are loaded. | | `BNS:c3c5e9` | `B301` | `PackedConfigStore` loads a config from file via `pickle.load`. The path is hard-coded to `cmk.utils.paths.corehelperconfig_dir` in `ConfigPath`, which is only writable by the site user. | | `BNS:e9bfaa` | `B303` | Only used to display fingerprints and in testing. | | `BNS:02774b` | `B303` | SHA1 is still used by the agent bakery and mkbackup for compatibility reasons. Switching is planned. | | `BNS:6b61d9` | `B310` | The URL is explicitly validated. | | `BNS:28af27` | `B310` | The URL or the scheme is hardcoded, so the scheme cannot change. | | `BNS:97f639` | `B321`, `B402` | The checked service requires FTP. | | `BNS:501305` | `B323` | Intended behaviour and configurable via option. | | `BNS:eb967b` | `B324` | SHA1 HMAC is fine and is the preferred standard for TOTP, bandit only sees the use of SHA1. | | `BNS:016141` | `B501` | Certificate validation not performed as it may break existing deployments of clients. | | `BNS:2aa916` | `B601` | `nasdbenv` is sanitized with shlex.quote. | | `BNS:67522a` | `B602`, `B605` | External inputs to the command have been quoted for shell-safety. | | `BNS:2b5952` | `B602`, `B605` | Intended Shell functionaility, should be reviewed for mitigating security layers in the future. | | `BNS:f6c1b9` | `B605` | Shell command has been reviewed. | | `BNS:bbfc92` | `B701` | The test code in the examples is hard coded and does not currently take in external input. | | `BNS:a7d6b8` | `B202` | Bandit is not updated (tarfile check added July 2022) for the changes to tarfile.extractall() filters from python 3.12. | | `BNS:13b2c8` | `B108` | Using /tmp directory on host, reviewed. |
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-plugin_create.md

category: Plugin apiurl: '/api/v1/plugin' title: "Create A Plugin of HostGroup" type: 'POST' sample_doc: 'plugin.html' layout: default Required grp_id: hostgroup id ```{ "hostgroup_id": 343, "dir_path": "testpath" }``` ```Status: 200``` ```{ "id": 1501, "grp_id": 343, "dir": "testpath", "create_user": "root" }```
Project: Vector (Observability and Analysis / Observability)
File: raspbian.md

title: Install Vector on Raspbian short: Raspbian supported_installers: ["Vector installer", "Docker"] weight: 7 [Raspbian] is the operating system used on Raspberry Pis. It is a Debian-based operating system designed for compact single-board computers. This page covers installing and managing Vector on the Raspbian operating system. {{< supported-installers >}}
Project: Netdata (Observability and Analysis / Observability)
File: wifi_inbound_packets_dropped_ratio.md

This alert calculates the ratio of inbound dropped packets for a specific network interface over the last 10 minutes. If you receive this alert, it means that your WiFi network interface dropped a significant number of packets, which could be due to lack of resources or unsupported protocol. In the context of networking, "inbound dropped packets" means that packets were received by the network interface but were not processed. This can happen due to various reasons, including: Insufficient resources (e.g., CPU, memory) to handle the packet. Unsupported protocol. Network congestion, leading to packets being dropped. Hardware or configuration issues. Check the system resource utilization Using the `top` command, check the resource utilization (CPU, memory, and I/O) in your system. High resource usage might indicate that your system is struggling to process the incoming packets. ``` top ``` Inspect network configuration and hardware Check if there are any hardware issues or misconfigurations in your WiFi adapter or network interface. Refer to your hardware's documentation or manufacturer's support for troubleshooting steps. Make sure your network device drivers are up-to-date. Monitor network traffic Use the `iftop` command to monitor network traffic on your interface. High network traffic can cause congestion, leading to dropped packets. If you don't have it installed, follow the . ``` sudo iftop -i <interface_name> ``` Investigate network protocols Inbound dropped packets may be caused by unsupported network protocols. Use the `tcpdump` command to examine network traffic for any abnormalities or unknown protocols. ``` sudo tcpdump -i <interface_name> ``` Remember to replace `<interface_name>` with the actual name of the WiFi network interface causing the alert.
Project: Vector (Observability and Analysis / Observability)
File: prometheus_scrape.md

title: Prometheus scrape description: Collect metrics via the client component_kind: source layout: component tags: ["prometheus", "scrape", "component", "source", "metrics"] aliases: ["/docs/reference/sources/prometheus"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-7-3-7.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 7.3.7 <!-- Auto generated by update changelog github action --> Auth: Add missing request headers to SigV4 middleware allowlist. , Elasticsearch: Sort results by index order as well as @timestamp. , SAML: Fixes bug in processing SAML response with empty <Issuer> element by updating saml library (Enterprise). , SeriesToRows: Fixes issue in transform so that value field is always named Value. ,
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: README.md

_This is work in progress. We aim for it to become a good role model for alerts and dashboards eventually, but it is not quite there yet._ The Prometheus Mixin is a set of configurable, reusable, and extensible alerts and dashboards for Prometheus. To use them, you need to have `jsonnet` (v0.13+) and `jb` installed. If you have a working Go development environment, it's easiest to run the following: ```bash $ go install github.com/google/go-jsonnet/cmd/jsonnet@latest $ go install github.com/google/go-jsonnet/cmd/jsonnetfmt@latest $ go install github.com/jsonnet-bundler/jsonnet-bundler/cmd/jb@latest ``` _Note: The make targets `lint` and `fmt` need the `jsonnetfmt` binary, which is available from in the Go implementation of `jsonnet`. If your jsonnet version is older than 0.16.0 you have to either upgrade or install the [C++ version of jsonnetfmt](https://github.com/google/jsonnet) if you want to use `make lint` or `make fmt`._ Next, install the dependencies by running the following command in this directory: ```bash $ jb install ``` You can then build a `prometheus_alerts.yaml` with the alerts and a directory `dashboards_out` with the Grafana dashboard JSON files: ```bash $ make prometheus_alerts.yaml $ make dashboards_out ``` For more advanced uses of mixins, see https://github.com/monitoring-mixins/docs.
Project: Hubble (Observability and Analysis / Observability)
File: MAINTAINERS.md

This page lists all active maintainers of this repository. If you were a maintainer and would like to add your name to the Emeritus list, please send us a PR. See for governance guidelines and how to become a maintainer. See for general contribution guidelines. , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC
Project: Trickster (Observability and Analysis / Observability)
File: MAINTAINERS.md

| Name | Contact | Company | Term Expires | ||||| |James Ranson () | <james@ranson.org> | Virga | 22/Mar/2024 | | Name | Contact | Company | Pronouns | Focus Areas| |||||| |James Ranson () | <james@ranson.org> | Virga | He/Him | Core Functionality | |Jake Nichols () | <mail@jnichols.info> | Argano | They/Them | Core Functionality | |Chris Randles () | <randles.chris@gmail.com> | WB Discovery | He/Him | Core Functionality | |Adam Ross () | <adamross1126@gmail.com> | Amazon | He/Him | Deployment & Artifacts (Makefile, Dockerfile, Helm Charts, etc) | You can contact the maintainers using the `@trickstercache/maintainers` handle in an Issue or PR, or via email at <cncf-trickster-maintainers@lists.cncf.io>. Additional community members comprise our Reviewers team, who may review and approve PRs, but otherwise do not maintain the project. Reviewers are generally engaged in a PR by a Maintainer seeking input or binding approval from someone with additional expertise in the PR's technical domain. Refer to the team for a list of our Reviewers. You can tag all reviewers in issues/commits/PR's using the `@trickstercache/reviewers` handle.
Project: Vector (Observability and Analysis / Observability)
File: datadog-acquisition.md

title: "Accelerating Vector with Datadog" description: "Timber (and Vector) have been acquired by Datadog" date: "2021-02-11" authors: ["binarylogic", "zsherman"] badges: type: announcement tags: ["datadog", "acquisition"] We're excited to announce that Timber and Vector are now officially part of ! When we started building Vector, we set out to provide an entirely new kind of data pipeline. We were guided by a belief that when it comes to collecting, transforming, and routing observability data, teams shouldnt have to accept trade-offs between cost, performance, reliability, and security. They also shouldnt have to stitch together disparate tools just to get their data from point A to B; the ideal solution should be simple, yet robust, and unify the entire pipeline. Weve dedicated ourselves to that challenge, and were proud of the platform weve created. We started talking to the team at Datadog back in 2017. They have a unique ability to take deep technical innovation and make it accessible to engineering teams through an intuitive and seamless user experience. Weve always admired their focus on solving real customer problems and engineering excellence, and the breadth of their quality integrationssomething weve sought to emulate through our work with Vector. Since we launched the project in 2019, Vector has grown beyond our expectations. It is currently downloaded millions of times per month and used by hundreds of forward-thinking enterprises to collect, process, and take control of their observability data. This growth has significantly intensified the demands on the project and our team, dramatically increasing our integration count, creating unprecedented performance challenges, and adding complex enterprise requirements. Joining Datadog means that Vector now has a safe, sustainable, long-term home where we can continue to evolve the project to meet the ever-changing needs of modern engineering teams at scale. We will have the resources to expand the team and execute on an ambitious roadmap, all while drawing on the years of observability experience that the Datadog team brings to the table. We plan to double down on Vectors reliability and performance, solidifying it as the fastest and most reliable observability data platform, and to introduce numerous features designed for enterprise scale deployments of mission-critical observability pipelines. Without the Vector community, this project would not be what it is today. You all have contributed heavily to the life of this project, providing us with more feedback, GitHub issues, pull requests, feature requests, and lively Discord discussions than we can count. We give our sincere thanks to everyone who has taken part in building something that we can all be proud of, and hope to have you with us as we enter this next chapter.
Project: M3 (Observability and Analysis / Observability)
File: installation.md

title: "Installation" menuTitle: "Installation" weight: 11 chapter: true Be sure to take a look at the before installing the operator. Add the `m3db-operator` repo: ``` helm repo add m3db https://m3-helm-charts.storage.googleapis.com/stable ``` Install the `m3db-operator` chart: ``` helm install m3db-operator m3db/m3db-operator ``` Note: If uninstalling an instance of the operator that was installed with Helm, some resources such as the ClusterRole, ClusterRoleBinding, and ServiceAccount may need to be deleted manually. Install the bundled operator manifests in the current namespace: ``` kubectl apply -f https://raw.githubusercontent.com/m3db/m3db-operator/master/bundle.yaml ```
Project: Elastic (Observability and Analysis / Observability)
File: rtrim.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Removes trailing whitespaces from a string. ``` ROW message = " some text ", color = " red " | EVAL message = RTRIM(message) | EVAL color = RTRIM(color) | EVAL message = CONCAT("'", message, "'") | EVAL color = CONCAT("'", color, "'") ```