cwielenb/CNCF-Dataset huggingface dataset:
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: v1-1.md

title: Version 1.1 release notes menuTitle: V1.1 description: Release notes for Grafana Pyroscope 1.1 weight: 850 The Pyroscope team is excited to announce the second release. This release allows to retrieve series from persistent storages like local disk and object store and also has a couple of performance improvements (e.g., JFR ingestion is handled a lot more efficiently). As always, feedback is more than welcome, feel free to open issues/discussions. You can reach out to the team using: ```bash docker pull docker.io/grafana/pyroscope:1.1.0 ``` Switched to v1 Golang SDK. Updated multiple dependencies including Go, Ruby, Django, Rust, and more. Introduced meta fetcher that synchronizes filtered metadata locally. Introduced pyroscope packaging via nfpm. Use Grafana flame graph component. 'ExportData' now respects the 'flamegraph.com' related prop. Introduced option to disable RBAC. Introduced a tenant scanner. Refactoring for block compaction to enable shard-splitting. Improved multitenancy default behavior documentation. Addressed various race conditions and bug fixes. Improved URL handling and pprof merges. Fixed various documentation inconsistencies and outdated references. Fixed broken links. Resolved multiple issues related to dotnet and ebpf. Addressed flaky tests and issues in ingestionAdapter. Handle profiles without timestamps. Added tabs to Java docs and updated ebpf docs. Added section for Apple arm64 builds. Updated documentation for contributors. Improved helm documentation. Optimized and clarified querier API calls. Introduced Helm v1.0.0 release. Automation added for brew releases. Helm improvements: setting correct namespace, adding initContainers, hostNetwork, etc. Refactored after dskit upgrade. Updated rideshare examples for ingesting to grafana.com.
Project: Fluentd (Observability and Analysis / Observability)
File: GithubWorkflow.md

Table of Contents The code is hosted on Github (https://github.com/fluent/fluentd). The repository is called `upstream`. Contributors will develop and commit their changes in a clone of upstream repository. Then contributors push their change to their forked repository (`origin`) and create a Pull Request (PR), the PR will be merged to `upstream` repository if it meets the all the necessary requirements. Go to https://github.com/fluent/fluentd then hit the `Fork` button to fork your own copy of repository fluentd to your github account. Clone the forked repo in to your local working directory: ```sh $ git clone https://github.com/$yourgithubaccount/fluentd.git ``` Keep your fork in sync with the main repo, add an `upstream` remote: ```sh $ cd fluentd $ git remote add upstream https://github.com/fluentd/fluentd.git $ git remote -v origin https://github.com/$yourgithubaccount/fluentd.git (fetch) origin https://github.com/$yourgithubaccount/fluentd.git (push) upstream https://github.com/fluentd/fluentd.git (fetch) upstream https://github.com/fluentd/fluentd.git (push) ``` Sync your local `master` branch: ```sh $ git checkout master $ git pull origin master $ git fetch upstream $ git rebase upstream/master ``` Before making any change, create a new branch: ```sh $ git checkout master $ git pull upstream master $ git checkout -b new-feature ``` Make any change on the branch `new-feature` then build and test your codes. Include in what will be committed: ```sh $ git add <file> ``` Commit your changes with `sign-offs` ```sh $ git commit -s ``` Enter your commit message to describe the changes. See the tips for a good commit message at . Likely you go back and edit/build/test some more then `git commit --amend` Push your branch `new-feature` to your forked repository: ```sh $ git push -u origin new-feature ``` Go to your fork at https://github.com/$yourgithubaccount/fluentd Create a Pull Request from the branch you recently pushed by hitting the button `Compare & pull request` next to branch name.
Project: Elastic (Observability and Analysis / Observability)
File: st_x.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Extracts the `x` coordinate from the supplied point. If the points is of type `geo_point` this is equivalent to extracting the `longitude` value. ``` ROW point = TO_GEOPOINT("POINT(42.97109629958868 14.7552534006536)") | EVAL x = STX(point), y = STY(point) ```
Project: Netdata (Observability and Analysis / Observability)
File: consul_client_rpc_requests_exceeded.md

This alert triggers when the rate of rate-limited RPC (Remote Procedure Call) requests made by a Consul server within the specified datacenter has exceeded a certain threshold. If you receive this alert, it means that your Consul server is experiencing an increased number of rate-limited RPC requests, which may affect its performance and availability. Consul is a service mesh solution used for service discovery, configuration, and segmentation. It provides a distributed platform to build robust, scalable, and secured services while simplifying network infrastructure. Remote Procedure Call (RPC) is a protocol that allows a computer to execute a procedure on another computer across a network. In the context of Consul, RPC requests are used for communication between Consul servers and clients. Check the Consul server logs for any relevant error messages or warnings. These logs can provide valuable information on the cause of the increased RPC requests. ``` journalctl -u consul ``` Monitor the Consul server's resource usage, such as CPU and memory utilization, to ensure that it is not running out of resources. High resource usage may cause an increase in rate-limited RPC requests. ``` top -o +%CPU ``` Analyze the Consul client's usage patterns and identify any misconfigured services or clients contributing to the increased RPC requests. Identify any services that may be sending a high number of requests per second or are not appropriately rate-limited. Review the Consul rate-limiting configurations to ensure that they are set appropriately based on the expected workload. Adjust the rate limits if necessary to better accommodate the workload. If the issue persists, consider scaling up the Consul server resources or deploying more Consul servers to handle increased traffic and prevent performance issues.
Project: Checkmk (Observability and Analysis / Observability)
File: 16803.md

key | value | date | 2024-04-24T14:21:32+00:00 version | 2.4.0b1 class | fix edition | cee component | metrics level | 1 compatible | yes Custom graphs can contain elements whose host or service is non-existant. This happens for example when a host is removed from the monitoring after one of its metrics has been added to a custom graph. In such cases, no graph was rendered. Instead, the Checkmk UI displayed the message "Cannot calculate graph recipes" and showed a traceback. As of this werk, the UI instead renders no lines for such elements and denotes them with "n/a" in the graph legend.
Project: Grafana (Observability and Analysis / Observability)
File: configure-oncall.md

aliases: ../../../alerting-rules/manage-contact-points/configure-oncall/ # /docs/grafana/<GRAFANA_VERSION>/alerting/alerting-rules/manage-contact-points/configure-oncall/ ../../../alerting-rules/manage-contact-points/integrations/configure-oncall/ # /docs/grafana/<GRAFANA_VERSION>/alerting/alerting-rules/manage-contact-points/integrations/configure-oncall/ canonical: https://grafana.com/docs/grafana/latest/alerting/configure-notifications/manage-contact-points/integrations/configure-oncall/ description: Configure the Alerting - Grafana OnCall integration to connect alerts generated by Grafana Alerting with Grafana OnCall keywords: grafana alerting oncall integration aliases: ../configure-oncall/ # /docs/grafana/<GRAFANA_VERSION>/alerting/alerting-rules/manage-contact-points/configure-oncall/ labels: products: cloud enterprise oss menuTitle: Grafana OnCall title: Configure Grafana OnCall for Alerting weight: 300 Use the Grafana Alerting - Grafana OnCall integration to effortlessly connect alerts generated by Grafana Alerting with Grafana OnCall, where you can then route them according to defined escalation chains and schedules. You can set up the integration using the Grafana Alerting application or the Grafana OnCall application. For more information on setting it up from the Grafana OnCall application, see . Ensure you have Installed and enabled the Grafana OnCall plugin Ensure your version of Grafana is up-to-date and supports the new features To set up the Grafana OnCall integration using the Grafana Alerting application, complete the following steps. Navigate to Alerts&IRM -> Alerting -> Contact points. Click + Add contact point. Enter a contact point name. From the Integration list, select Grafana OnCall. Note: The Grafana OnCall integration is only available for Grafana Alertmanager. Choose whether to add a new OnCall integration or add an existing one. If you add a new one, enter an Integration name. If you add an existing one, choose from the list of available integrations Click Save contact point. On the Contact points list view page, you can see the contact point with the Grafana OnCall icon. If the integration is not yet being used anywhere in the notification policies tree, it will have Unused as its status in the Health column. It wont receive any notifications, because there are no notifications using that integration. Connect your contact point to a notification policy. For more information on connecting your contact point to a notification policy, see . To view your integration in the Grafana OnCall application and set up routes and escalation chains, click the Link next to the integration on the Contact points list view page in the Type column. This redirects you to the Grafana OnCall integration page in the Grafana OnCall application. From there, you can add . {{% docs/reference %}} {{% /docs/reference %}}
Project: Checkmk (Observability and Analysis / Observability)
File: 16522.md

key | value | date | 2024-02-19T17:24:03+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | no When deleting a comment via the REST-API, only the 'by_id' option leaves the comment selection ambiguous, while the options 'params' or 'query' already have the ability to pinpoint the comment requested. Therefore, the site_id should is not required in these cases.
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: log.md

sidebar_position: 5 The log exporter is here mostly for backward compatibility (originally every variation were logged, but it can be a lot of data for a default configuration). It will use your logger `ffclient.Config.Logger` to log every variation changes. You can configure your output log with the `Format` field. It uses a format. ```go linenums="1" ffclient.Config{ // ... DataExporter: ffclient.DataExporter{ Exporter: &logsexporter.Exporter{ LogFormat: "[{{ .FormattedDate}}] user=\"{{ .UserKey}}\", flag=\"{{ .Key}}\", value=\"{{ .Value}}\"", }, }, // ... } ``` | Field | Description | |-|| | `LogFormat` | (optional)<br/>LogFormat is the configuration of the output format of your log.<br/>You can use all the key from the `exporter.FeatureEvent` + a key called `FormattedDate` that represent the date with the RFC 3339 Format.<br/><br/>Default: `[{{ .FormattedDate}}] user="{{ .UserKey}}", flag="{{ .Key}}", value="{{ .Value}}"` | Check the .
Project: Grafana Pyroscope (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 make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, 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 conduct@grafana.com. The project team will review and investigate all complaints, and will respond in a way that it deems 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
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: capabilities.md

title: Gadget capabilities capabilities traces security capability checks&#34; ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: capabilities namespace: gadget spec: node: ubuntu-hirsute gadget: capabilities runMode: Manual outputMode: Stream filter: namespace: default ``` Start capabilities gadget ```bash $ kubectl annotate -n gadget trace/capabilities \ gadget.kinvolk.io/operation=start ``` Stop capabilities gadget ```bash $ kubectl annotate -n gadget trace/capabilities \ gadget.kinvolk.io/operation=stop ``` Stream
Project: Thanos (Observability and Analysis / Observability)
File: how-to-change-go-version.md

Thanos build system is pinned to certain Golang version. This is to ensure that Golang version changes is done by us in controlled, traceable way. To update Thanos build system to newer Golang: Edit and edit `go: version: <go version>` in YAML to desired version. This will ensure that all artifacts are built with desired Golang version. How to verify? Download tarball, unpack and invoke `thanos --version` Edit and update ` - image: cimg/go:<go version>-node` to desired Golang version. This will ensure that all docker images and go tests are using desired Golang version. How to verify? Invoke `docker pull quay.io/thanos/thanos:<version> --version` Edit and update Go version. Edit and update Go version.
Project: Centreon (Observability and Analysis / Observability)
File: action.md

This module aims to execute actions on the server running the Gorgone daemon or remotly using SSH. | Directive | Description | Default value | | : | :- | : | | command_timeout | Time in seconds before a command is considered timed out | `30` | | whitelist_cmds | Boolean to enable commands whitelist | `false` | | allowed_cmds | Regexp list of allowed commands | | | paranoid_plugins | Block centengine restart/reload if plugin dependencies missing | `false` | ```yaml name: action package: "gorgone::modules::core::action::hooks" enable: true command_timeout: 30 whitelist_cmds: true allowed_cmds: ^sudo\s+(/bin/)?systemctl\s+(reload|restart)\s+(centengine|centreontrapd|cbd)\s*$ ^(sudo\s+)?(/usr/bin/)?service\s+(centengine|centreontrapd|cbd|cbd-sql)\s+(reload|restart)\s*$ ^/usr/sbin/centenginestats\s+-c\s+/etc/centreon-engine/centengine\.cfg\s*$ ^cat\s+/var/lib/centreon-engine/[a-zA-Z0-9\-]+-stats\.json\s*$ ^/usr/lib/centreon/plugins/.*$ ^/bin/perl /usr/share/centreon/bin/anomalydetection --seasonality >> /var/log/centreon/anomalydetection\.log 2>&1\s*$ ^/usr/bin/php -q /usr/share/centreon/cron/centreon-helios\.php >> /var/log/centreon-helios\.log 2>&1\s*$ ^centreon ^mkdir ^/usr/share/centreon/www/modules/centreon-autodiscovery-server/script/runsavediscovered_host ^/usr/share/centreon/bin/centreon -u \"centreon-gorgone\" -p \S+ -w -o CentreonWorker -a processQueue$ ``` | Event | Description | | :- | :-- | | ACTIONREADY | Internal event to notify the core | | PROCESSCOPY | Process file or archive received from another daemon | | COMMAND | Execute a shell command on the server running the daemon or on another server using SSH | | Endpoint | Method | | :- | :-- | | /core/action/command | `POST` | | Header | Value | | :-- | : | | Accept | application/json | | Content-Type | application/json | | Key | Value | | :- | :- | | command | Command to execute | | timeout | Time in seconds before a command is considered timed out | | continueonerror | Behaviour in case of execution issue | ```json [ { "command": "<command to execute>", "timeout": "<timeout in seconds>", "continueonerror": "<boolean>" } ] ``` ```bash curl --request POST "https://hostname:8443/api/core/action/command" \ --header "Accept: application/json" \ --header "Content-Type: application/json" \ --data "[ { \"command\": \"echo 'Test command' >> /tmp/here.log\" } ]" ```
Project: Netdata (Observability and Analysis / Observability)
File: interface_inbound_errors.md

Troubleshoot errors related to network congestion Network congestion can cause packets to be dropped, leading to interface inbound errors. To determine if congestion is the issue, you can monitor the network for any signs of excessive workload or high utilization rates. Use `ifconfig` to check the network interface utilization: ``` ifconfig <your_interface> ``` Check the network switch/router logs for any indication of high utilization, errors or warnings. Use monitoring tools like `iftop`, `nload`, or `iptraf` to monitor network traffic and identify any bottle-necks or usage spikes. If you find that congestion is causing the inbound errors, consider ways to alleviate the issue including upgrading your network infrastructure or load balancing the traffic. Troubleshoot errors caused by faulty network equipment Faulty network devices, such as switches and routers, can introduce errors in packets. To identify the cause, you should review the logs and statistics of any network devices in the path of the communication between the sender and this system. Check the logs of the network equipment for any indications of errors, problems or unusual behavior. Review the error counters and statistics of the network equipment to identify any trends or issues. Consider replacing or upgrading faulty equipment if it is found to be responsible for inbound errors. Troubleshoot errors caused by software or configuration issues Incorrect configurations or software issues can also contribute to interface inbound errors. Some steps to troubleshoot these potential causes are: Review the system logs for any errors or warnings related to the network subsystem. Ensure that the network interface is configured correctly, and proper drivers are installed and up-to-date. Examine the system's firewall and security settings to verify that there are no inappropriate blockings or restrictions that may be causing the errors. In conclusion, by following these troubleshooting steps, you should be able to identify and resolve the cause of interface inbound errors on your FreeBSD system. Remember to monitor the situation regularly and address any new issues that may arise to ensure a stable and efficient networking environment.
Project: Netdata (Observability and Analysis / Observability)
File: nfs_server.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/integrations/nfs_server.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/metadata.yaml" sidebar_label: "NFS Server" learn_status: "Published" learnrelpath: "Collecting Metrics/Linux Systems/Filesystem/NFS" most_popular: False message: "DO NOT EDIT THIS FILE DIRECTLY, IT IS GENERATED BY THE COLLECTOR'S metadata.yaml FILE" endmeta--> <img src="https://netdata.cloud/img/nfs.png" width="150"/> Plugin: proc.plugin Module: /proc/net/rpc/nfsd <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> This integration provides statistics from the Linux kernel's NFS Server. This collector is supported on all platforms. This collector supports collecting metrics from multiple instances of this integration, including remote instances. This integration doesn't support auto-detection. The default configuration for this integration does not impose any limits on data collection. The default configuration for this integration is not expected to impose a significant performance impact on the system. Metrics grouped by scope. The scope defines the instance that the metric belongs to. An instance is uniquely identified by a set of labels. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | nfsd.readcache | hits, misses, nocache | reads/s | | nfsd.filehandles | stale | handles/s | | nfsd.io | read, write | kilobytes/s | | nfsd.threads | threads | threads | | nfsd.net | udp, tcp | packets/s | | nfsd.rpc | calls, badformat, badauth | calls/s | | nfsd.proc2 | a dimension per proc2 call | calls/s | | nfsd.proc3 | a dimension per proc3 call | calls/s | | nfsd.proc4 | a dimension per proc4 call | calls/s | | nfsd.proc4ops | a dimension per proc4 operation | operations/s | There are no alerts configured by default for this integration. No action required. There is no configuration file. There are no configuration options. There are no configuration examples.