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

name: "\U0001F6F8 Feature request" about: Suggest an idea that will improve the project title: '' labels: '' assignees: '' <!-- Thanks for filing an issue! Before hitting the button, please answer these questions. Describe in detail the feature/behavior/change you'd like to see. Be ready for followup questions, and please respond in a timely manner. If we think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. -->
Project: Netdata (Observability and Analysis / Observability)
File: amd_gpu.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/integrations/amd_gpu.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/metadata.yaml" sidebar_label: "AMD GPU" learn_status: "Published" learnrelpath: "Collecting Metrics/Hardware Devices and Sensors" 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/amd.svg" width="150"/> Plugin: proc.plugin Module: /sys/class/drm <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> This integration monitors AMD GPU metrics, such as utilization, clock frequency and memory usage. It reads `/sys/class/drm` to collect metrics for every AMD GPU card instance it encounters. This collector is only supported on the following platforms: Linux 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. These metrics refer to the GPU. Labels: | Label | Description | |:--|:-| | product_name | GPU product name (e.g. AMD RX 6600) | Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | amdgpu.gpu_utilization | utilization | percentage | | amdgpu.gpumemutilization | utilization | percentage | | amdgpu.gpuclkfrequency | frequency | MHz | | amdgpu.gpumemclk_frequency | frequency | MHz | | amdgpu.gpumemvramusageperc | usage | percentage | | amdgpu.gpumemvram_usage | free, used | bytes | | amdgpu.gpumemvisvramusage_perc | usage | percentage | | amdgpu.gpumemvisvramusage | free, used | bytes | | amdgpu.gpumemgttusageperc | usage | percentage | | amdgpu.gpumemgtt_usage | free, used | bytes | 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.
Project: Netdata (Observability and Analysis / Observability)
File: systemd_services.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/cgroups.plugin/integrations/systemd_services.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/cgroups.plugin/metadata.yaml" sidebar_label: "Systemd Services" learn_status: "Published" learnrelpath: "Collecting Metrics/Systemd" most_popular: True message: "DO NOT EDIT THIS FILE DIRECTLY, IT IS GENERATED BY THE COLLECTOR'S metadata.yaml FILE" endmeta--> <img src="https://netdata.cloud/img/systemd.svg" width="150"/> Plugin: cgroups.plugin Module: /sys/fs/cgroup <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Monitor Containers for performance, resource usage, and health status. 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. Labels: | Label | Description | |:--|:-| | service_name | Service name | Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | systemd.service.cpu.utilization | user, system | percentage | | systemd.service.memory.usage | ram, swap | MiB | | systemd.service.memory.failcnt | fail | failures/s | | systemd.service.memory.ram.usage | rss, cache, mappedfile, rsshuge | MiB | | systemd.service.memory.writeback | writeback, dirty | MiB | | systemd.service.memory.paging.faults | minor, major | MiB/s | | systemd.service.memory.paging.io | in, out | MiB/s | | systemd.service.disk.io | read, write | KiB/s | | systemd.service.disk.iops | read, write | operations/s | | systemd.service.disk.throttle.io | read, write | KiB/s | | systemd.service.disk.throttle.iops | read, write | operations/s | | systemd.service.disk.queued_iops | read, write | operations/s | | systemd.service.disk.merged_iops | read, write | operations/s | | systemd.service.pids.current | pids | pids | 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.
Project: Checkmk (Observability and Analysis / Observability)
File: 16330.md

key | value | date | 2024-01-24T14:08:45+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes While calculating how much time is left until the resource is full, if the value of the mb in range was too low (e.g. 1e-320) the check used to crash with 'infinite to integer'. This has now been fixed and if the value is too low and causes division with it to result in 'inf', the check will not be executed.
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: custom.md

sidebar_position: 30 To create a custom retriever you must have a `struct` that implements the interface. ```go linenums="1" type Retriever interface { Retrieve(ctx context.Context) ([]byte, error) } ``` The `Retrieve` function is supposed to load the file and to return a `[]byte` of your flag configuration file. You can check existing `Retriever` *(, , ...)* to have an idea on how to do build your own.
Project: Grafana Loki (Observability and Analysis / Observability)
File: getting-in-touch.md

title: Contacting the Loki Team description: How to contact the Loki team weight: 100 For questions regarding Loki: Ask a question in the `#loki` channel of our community Open source Loki users are welcome to post technical questions on the Grafana Labs Community Forums under the Grafana Loki category at . Please be mindful that this is a community-driven support channel moderated by Grafana Labs staff where Loki maintainers and community members answer questions when bandwidth allows. Be sure to review the before posting. Users using Loki via can submit support tickets via the . For questions regarding Enterprise support for Loki, you can get in touch with the Grafana Labs team . Your feedback is always welcome! To submit feedback or a report a potential bug: for bugs, issues and feature suggestions. Grafana UI issues for the Loki data source plugin should be posted directly to the , not the Loki repository. Send an email to , or visit the page. Join us for our monthly on first Thursday of every month alternating between EU (12:00 UTC) and US (17:00 UTC) timezones. Subscribe to the calendar in the doc for being up to date.
Project: SkyWalking (Observability and Analysis / Observability)
File: v6-version-upgrade.md

SkyWalking v6 is widely used in many production environments. Follow the steps in the guide below to learn how to upgrade to a new release. NOTE: The ways to upgrade are not limited to the steps below. Like all applications, you may upgrade SkyWalking using the `canary release` method through the following steps. Deploy a new cluster by using the latest version of SkyWalking OAP cluster with the new database cluster. Once the target service (i.e. the service being monitored) has upgraded the agent.jar (or simply by rebooting), have `collector.backend_service` pointing to the new OAP backend, and use/add a new namespace(`agent.namespace` in ). The namespace will prevent conflicts from arising between different versions. When all target services have been rebooted, the old OAP clusters could be discarded. The `Canary Release` method works for any version upgrades. The reason we require `Canary Release` is that the SkyWalking agent has cache mechanisms, and switching to a new cluster causes the cache to become unavailable for new OAP clusters. In version 6.5.0+ (especially for agent versions), we have . This streamlines the upgrade process as we deploy a new cluster by using the latest version of SkyWalking OAP cluster with the new database cluster, and shift the traffic to the new cluster once and for all. Based on the mechanism, all agents will enter the `cool_down` mode, and come back online. For more details, see the backend setup documentation. NOTE: A known bug in 6.4.0 is that its agent may have re-connection issues; therefore, even though this bot reboot mechanism has been included in 6.4.0, it may not work under some network scenarios, especially in Kubernetes. All versions of SkyWalking 6.x (and even 7.x) are compatible with each other, so users could simply upgrade the OAP servers. As the agent has also been enhanced in the latest versions, according to the SkyWalking team's recommendation, upgrade the agent as soon as practicable.
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-1.3.7.md

Upgrade netty to 4.1.84.Final () OpenJDK Update (October 2022 Patch releases) () Upgrade com.netflix.nebula:nebula-publishing-plugin to 4.6.0 and gradle-docker-compose-plugin to 0.14.12 () Updated Jackson to 2.14.1 () Fixed error handling while reading analyzer mapping rules ()
Project: M3 (Observability and Analysis / Observability)
File: node_endpoint.md

title: "Node Endpoint" menuTitle: "Node Endpoint" weight: 14 chapter: true M3DB stores an field on placement instances that is used for communication between DB nodes and from other components such as the coordinator. The operator allows customizing the format of this endpoint by setting the `nodeEndpointFormat` field on a cluster spec. The format of this field uses [Go templates], with the following template fields currently supported: | Field | Description | | -- | -- | | `PodName` | Name of the pod | | `M3DBService` | Name of the generated M3DB service | | `PodNamespace` | Namespace the pod is in | | `Port` | Port M3DB is serving RPCs on | The default format is: ``` {{ .PodName }}.{{ .M3DBService }}:{{ .Port }} ``` As an example of an override, to expose an M3DB cluster to containers in other Kubernetes namespaces `nodeEndpointFormat` can be set to: ``` {{ .PodName }}.{{ .M3DBService }}.{{ .PodNamespace }}:{{ .Port }} ```
Project: Netdata (Observability and Analysis / Observability)
File: _task-page-template.md

<!-- title: Starts with an active verb, like "Create a widget" or "Delete a widget" description:Short summary (will be displayed in search engines) customediturl:Edit URL of the source file keywords: [keywords, describing, the main topics] --> Short description of why or when the procedure makes sense. <!-- If there is only one requirement, use a paragraph instead of a single bullet item. Bullets are social animals and only appear in groups of 2 or more :) --> Optional. List all needed prerequisites: Prerequisite 1 Prerequisite 2 Prerequisite 3 To do x: Step 1 written in active voice ```bash Code sample for step ``` Step 2 Result of step 2, for example a system reaction; written in passive voice Step 3 See lines 11-24 <!-- Optional --> Optional section that explains the next logical steps. <!-- Optional --> Visit the to learn more about related thing.
Project: Grafana Loki (Observability and Analysis / Observability)
File: geoip.md

title: geoip menuTitle: description: The 'geoip' Promtail pipeline stage. aliases: ../../../clients/promtail/stages/geoip/ weight: The `geoip` stage is a parsing stage that reads an ip address and populates the labelset with geoip fields. is used for the lookup. Populated fields for City db: geoipcityname geoipcountryname geoipcontinentname geoipcontinentcode geoiplocationlatitude geoiplocationlongitude geoippostalcode geoip_timezone geoipsubdivisionname geoipsubdivisioncode Populated fields for ASN (Autonomous System Number) db: geoipautonomoussystem_number geoipautonomoussystem_organization ```yaml geoip: [db: <string>] [source: <string>] [db_type: <string>] ``` For the given pipeline ```yaml regex: expression: "^(?P<ip>\S+) .*" geoip: db: "/path/to/GeoIP2-City.mmdb" source: "ip" db_type: "city" ``` And the log line: ``` "34.120.177.193 - "POST /loki/api/push/ HTTP/1.1" 200 932 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6" ``` The `regex` stage parses the log line and `ip` is extracted. Then the extracted `ip` value is given as `source` to `geoip` stage. The `geoip` stage performs a lookup on the `ip` and populates the following labels: `geoipcityname`: `Kansas City` `geoipcountryname`: `United States` `geoipcontinentname`: `North America` `geoipcontinentcode`: `NA` `geoiplocationlatitude`: `"39.1027` `geoiplocationlongitude`: `-94.5778` `geoippostalcode`: `64184` `geoip_timezone`: `America/Chicago` `geoipsubdivisionname`: `Missouri` `geoipsubdivisioncode`: `MO` If only a subset of these labels are required, you can chain the above pipeline with the `labeldrop` or `labelallow` stage. ```yaml regex: expression: "^(?P<ip>\S+) .*" geoip: db: "/path/to/GeoCity.mmdb" source: "ip" db_type: "city" labelallow: geoipcityname geoipcountryname geoiplocationlatitude geoiplocationlongitude ``` Only the labels listed under `labelallow` will be sent to Loki. ```yaml regex: expression: "^(?P<ip>\S+) .*" geoip: db: "/path/to/GeoCity.mmdb" source: "ip" db_type: "city" labeldrop: geoippostalcode geoipsubdivisioncode ``` All the labels except the ones listed under `labeldrop` will be sent to Loki. ```yaml regex: expression: "^(?P<ip>\S+) .*" geoip: db: "/path/to/GeoIP2-ASN.mmdb" source: "ip" db_type: "asn" ``` And the log line: ``` "34.120.177.193 - "POST /loki/api/push/ HTTP/1.1" 200 932 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6" ``` The `regex` stage parses the log line and `ip` is extracted. Then the extracted `ip` value is given as `source` to `geoip` stage. The `geoip` stage performs a lookup on the `ip` and populates the following labels: `geoipautonomoussystem_number`: `396982` `geoipautonomoussystem_organization`: `GOOGLE-CLOUD-PLATFORM` For more information and real life example, see [Protect PII and add geolocation data: Monitoring legacy systems with Grafana ](/blog/2023/03/14/protect-pii-and-add-geolocation-data-monitoring-legacy-systems-with-grafana/) which has real-life examples on how to infuse dashboards with geo-location data.
Project: Checkmk (Observability and Analysis / Observability)
File: 16361.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-02-26T14:44:18+00:00 level | 1 class | security component | checks edition | cre In order to execute some system commands Checkmk Windows agent writes cmd files to `C:\Windows\Temp\` and afterwards executes them. The permissions of the files were set restrictive but existing files were not properly handled. If a cmd file already existed and was write protected the agent was not able to rewrite the file but did not handle this case and executed the file nevertheless. We thank Michael Baer (SEC Consult Vulnerability Lab) for reporting this issue. Affected Versions: 2.2.0 2.1.0 2.0.0 Indicators of Compromise: The filename of the cmd file needed to be guessed therefore the proof-of-concept creates a lot of files in `C\Windows\Temp` with the filename `cmkall\d+_1.cmd`. These file-creation events could be monitored. 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`. We assigned CVE-2024-0670 to this vulnerability. Changes: This Werk changes the temp folder and adds a subfolder with more restrictive permissions in which the files are created. Also errors are handled better.
Project: Netdata (Observability and Analysis / Observability)
File: semaphore_arrays_used.md

This alarm monitors the percentage of used `System V IPC semaphore arrays (sets)`. If you receive this alert, it means that your system has a high utilization of `IPC semaphore arrays`, which can affect application performance. Check the current usage of semaphore arrays Use the `ipcs -u` command to display a summary of the current usage of semaphore arrays on your system. Look for the "allocated semaphores" section, which indicates the number of semaphore arrays being used. ``` ipcs -u ``` Identify processes using semaphore arrays Use the `ipcs -s` command to list all active semaphore arrays and their associated process IDs (PIDs). This information can help you identify which processes are using semaphore arrays. ``` ipcs -s ``` Investigate and optimize processes using semaphore arrays Based on the information from the previous step, investigate the processes that are using semaphore arrays. If any of these processes can be optimized or terminated to free up semaphore arrays, do so carefully after ensuring that they are not critical to your system. Adjust the semaphore limit on your system If the semaphore array usage is still high after optimizing processes, you may need to increase the semaphore limit on your system. As mentioned earlier, you can adjust the limit in the `/proc/sys/kernel/sem` file. ``` vi /proc/sys/kernel/sem ``` Edit the fourth field to increase the max semaphores limit. Save the file and exit. To apply the changes, run: ``` sysctl -p ``` Please note that increasing the limit might consume more system resources. Monitor your system closely to ensure that it remains stable after making these changes.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-0-5.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 8.0.5 <!-- Auto generated by update changelog github action --> Cloudwatch Logs: Send error down to client. , Folders: Return 409 Conflict status when folder already exists. , TimeSeries: Do not show series in tooltip if it's hidden in the viz. , AzureMonitor: Fix issue where resource group name is missing on the resource picker button. , Chore: Fix AWS auth assuming role with workspace IAM. , DashboardQueryRunner: Fixes unrestrained subscriptions being created. , DateFormats: Fix reading correct setting key for usebrowserlocale. , Links: Fix links to other apps outside Grafana when under sub path. , Snapshots: Fix snapshot absolute time range issue. , Table: Fix data link color. , Time Series: Fix X-axis time format when tick increment is larger than a year. , Tooltip Plugin: Prevent Tooltip render if field is undefined. ,
Project: Grafana (Observability and Analysis / Observability)
File: breaking-changes-v10-3.md

description: Breaking changes for Grafana v10.3 keywords: grafana breaking changes documentation '10.3' '10.2.3' release notes labels: products: cloud enterprise oss title: Breaking changes in Grafana v10.3 weight: -2 Following are breaking changes that you should be aware of when upgrading to Grafana v10.3. Breaking changes that were introduced in release 10.2.3 are also included here and are marked with an asterisk. For our purposes, a breaking change is any change that requires users or operators to do something. This includes: Changes in one part of the system that could cause other components to fail Deprecations or removal of a feature Changes to an API that could break automation Changes that affect some plugins or functions of Grafana Migrations that cant be rolled back For each change, the provided information: Helps you determine if youre affected Describes the change or relevant background information Guides you in how to mitigate for the change or migrate Provides more learning resources For release highlights and deprecations, refer to our . For the specific steps we recommend when you upgrade to v10.3, check out our . <!-- You must use relative references when linking to docs within the Grafana repo. Please do not use absolute URLs. For more information about relrefs, refer to .--> In panels using the extract fields transformation, where one of the extracted names collides with one of the already existing fields, the extracted field will be renamed. Issue . If you use the Table visualization, you might see some inconsistencies in your panels. We have updated the table column naming. This will potentially affect field transformations and/or field overrides. To resolve this, either: Update the transformation you are using Update field override. Issue . Users who have transformations with the Time field might see their transformations are not working. Those panels that have broken transformations will fail to render. This is because we changed the field key. See related PR: . To resolve this, either: Remove the affected panel and re-create it Select the Time field again Edit the time field as Time for transformation in panel.json or dashboard.json. Issue . The following data source permission endpoints have been removed: `GET /datasources/:datasourceId/permissions` `POST /api/datasources/:datasourceId/permissions` `DELETE /datasources/:datasourceId/permissions` `POST /datasources/:datasourceId/enable-permissions` `POST /datasources/:datasourceId/disable-permissions` Please use the following endpoints instead: `GET /api/access-control/datasources/:uid` for listing data source permissions `POST /api/access-control/datasources/:uid/users/:id`, `POST /api/access-control/datasources/:uid/teams/:id`, and `POST /api/access-control/datasources/:uid/buildInRoles/:id` for adding or removing data source permissions If you are using the Grafana provider for Terraform to manage data source permissions, you will need to upgrade your provider to or newer to ensure that data source permission provisioning keeps working. Issue .
Project: Netdata (Observability and Analysis / Observability)
File: README.md

<!-- title: "Health command API tester" customediturl: https://github.com/netdata/netdata/edit/master/tests/health_mgmtapi/README.md sidebar_label: "Health command API tester" learn_status: "Published" learntopictype: "References" learnrelpath: "Developers" --> The directory `tests/health_cmdapi` contains the test script `health-cmdapi-test.sh` for the . The script can be executed with options to prepare the system for the tests, run them and restore the system to its previous state. It depends on the management API being accessible on localhost:19999 and on the responses to the api/v1/alarms?all requests being functional. It also requires read access to the management API key that is usually under `/var/lib/netdata/netdata.api.key` (`@varlibdir_POST@/netdata.api.key`).