cwielenb/CNCF-Dataset huggingface dataset:
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: program-types.md

title: 'eBPF Program Types' weight: 50 description: 'Reference documentation for different eBPF programs supported by Inspektor Gadget' Inspektor Gadget automatically loads and attaches the eBPF programs contained in a gadget. This document describes the different types that are supported and specific details about them. The section name specifies the type of the program and the target they should be attached to. The section name must use the `kprobe/<functionname>` or `kretprobe/<functionname>` formats. `<function_name>` is the kernel function that the kprobe will be attached to. The section name must use the `tracepoint/<tracepointname>`. `<tracepointname>` is one of the available tracepoints on `/sys/kernel/debug/tracing/events`. The section name must start with `socket`. Socket programs are attached to all network namespaces matching the filter configuration when running the gadget. Currently we support some iterators and fentry/fexit programs. The section name must use `iter/<itertype>`. ig supports the following `<itertype>`: `ksym` `task` `task_file` `tcp` `udp` `tcp` and `udp` iterators are invoked in different network namespaces matching the filter configuration when running the gadget. You can find the list of iterator types supported by Linux with: `git grep -w ^DEFINEBPFITER_FUNC` in the Linux sources (16 types as of Linux 6.9) `sudo bpftool btf dump id 1 format c |grep 'struct bpfiter_'` in the current kernel The section name must use the `fentry/<functionname` or `fexit/<functionname>`. As in kprobes, `<function_name>` is the kernel function that the kprobe will be attached to. TODO! The section name must use the `classifier/<ingress|egress>/<program_name>` format. SchedCLS programs are attached to the peer of the networking interface of the containers on the host according to the filtering configuration. Inspektor Gadget supports running multiple gadgets that use SchedCLS programs at the same time. Programs must return `TCACTUNSPEC` in order to allow the packet to be processed by other gadgets. The order of execution of the programs is not deterministic, this is something we could visit later on. The section name must use the `<progtype>/<filepath>:<symbol>` format. `<prog_type>` must be either `uprobe` or `uretprobe`. `<file_path>` is the absolute path of an executable or a library, that the uprobe will be attached to. For common libraries, `<file_path>` can also be the library's name, such as `libc`. `<symbol>` is a debugging symbol that can be found in the file mentioned above. The section name must use the `usdt/<file_path>:<providerName>:<probeName>` format. `<file_path>` can be either an absolute path or a library name, same as the field in Uprobe. `<providerName>` and `<probeName>` are two fields that can jointly identify a USDT trace point. The section name must use the `lsm/<hook>` format. The hook points could be found in .
Project: Netdata (Observability and Analysis / Observability)
File: infiniband.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/integrations/infiniband.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/metadata.yaml" sidebar_label: "InfiniBand" learn_status: "Published" learnrelpath: "Collecting Metrics/Linux Systems/Network" 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/network-wired.svg" width="150"/> Plugin: proc.plugin Module: /sys/class/infiniband <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> This integration monitors InfiniBand network inteface statistics. 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 | |:|:-|:-| | ib.bytes | Received, Sent | kilobits/s | | ib.packets | Received, Sent, Mcastrcvd, Mcastsent, Ucastrcvd, Ucastsent | packets/s | | ib.errors | Pktsmalformated, Pktsrcvddiscarded, Pktssentdiscarded, TickWaittosend, Pktsmissedresource, Bufferoverrun, LinkDowned, Linkrecovered, Linkintegrityerr, Linkminorerrors, PktsrcvdwithEBP, Pktsrcvddiscardedbyswitch, Pktssentdiscardedbyswitch | errors/s | | ib.hwerrors | Duplicatedpackets, PktSeqNumgap, Acktimerexpired, Dropmissingbuffer, Dropoutofsequence, NAKsequencercvd, CQEerrReq, CQEerrResp, CQEFlushederrReq, CQEFlushederrResp, RemoteaccesserrReq, RemoteaccesserrResp, Remoteinvalidreq, LocallengtherrResp, RNRNAKPackets, CNPPktsignored, RoCEICRCErrors | errors/s | | ib.hwpackets | RoCEv2Congestionsent, RoCEv2Congestionrcvd, IBCongestionhandled, ATOMICreqrcvd, Connectionreqrcvd, Readreqrcvd, Writereqrcvd, RoCEretransadaptive, RoCEretranstimeout, RoCEslowrestart, RoCEslowrestartcongestion, RoCEslowrestartcount | packets/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.
Project: Checkmk (Observability and Analysis / Observability)
File: 16521.md

key | value | date | 2024-02-19T14:34:33+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | no The Open API schema previously did not reflect the response or the request schema format that was required to create or show BI rules. This werk addresses this issue. Previously, when creating or getting a BI rule, via the REST-API, the schema for hostlabelgroups or servicelabelgroups looked similar to the following: ``` "hostlabelgroups": [ [ "and", [ ["and", "mystery/switch:yes"], ["or", "mystery/switch:no"], ], ], ] ``` This did not match the schema documented in the Open API docs. To fix this, we have now changed the format to the following ``` "hostlabelgroups": [ { "operator": "and", "label_group": [ {"operator": "and", "label": "mystery/switch:yes"}, {"operator": "or", "label": "mystery/switch:no"}, ], }, ] ``` This also aligns with other endpoints that use our new hostlabelgroups or servicelabelgroups, for example the rules endpoints. As this is a breaking change, user scripts should be adjusted accordingly.
Project: Vector (Observability and Analysis / Observability)
File: 2024-02-13-0-36-0-upgrade-guide.md

date: "2024-02-13" title: "0.36 Upgrade Guide" description: "An upgrade guide that addresses breaking changes in 0.36.0" authors: ["jszwedko"] release: "0.36.0" hideonrelease_notes: false badges: type: breaking change Vector's 0.36.0 release includes no breaking changes or deprecations.
Project: Checkmk (Observability and Analysis / Observability)
File: 16643.md

key | value | date | 2024-03-27T15:55:26+00:00 version | 2.4.0b1 class | fix edition | cce component | wato level | 1 compatible | yes To lessen the impact of a setup becoming unlicensed, there is now a 7 day grace period before becoming unlicensed. In this time only warnings will be shown so that users have the opportunity to fix the licensing issues.
Project: Cortex (Observability and Analysis / Observability)
File: encryption-at-rest.md

title: "Encryption at Rest" linkTitle: "Encryption at Rest" weight: 10 slug: encryption-at-rest Cortex supports data encryption at rest for some storage backends. The Cortex S3 client supports the following server-side encryption (SSE) modes: The S3 server-side encryption can be configured as follows. The `s3sseconfig` configures the S3 server-side encryption. ```yaml sse: [type: <string> | default = ""] [kmskeyid: <string> | default = ""] [kmsencryptioncontext: <string> | default = ""] ``` The ruler S3 server-side encryption can be configured similarly to the blocks storage. The per-tenant overrides are supported when using the storage backend configurable the `-ruler-storage.` flag prefix (or their respective YAML config options). The alertmanager S3 server-side encryption can be configured similarly to the blocks storage. The per-tenant overrides are supported when using the storage backend configurable the `-alertmanager-storage.` flag prefix (or their respective YAML config options). The S3 client used by the blocks storage, ruler and alertmanager supports S3 SSE config overrides on a per-tenant basis, using the . The following settings can ben overridden for each tenant: `s3_sse_type`<br /> S3 server-side encryption type. It must be set to enable the SSE config override for a given tenant. `s3_sse_kms_key_id`<br /> S3 server-side encryption KMS Key ID. Ignored if the SSE type override is not set or the type is not `SSE-KMS`. `s3_sse_kms_encryption_context`<br /> S3 server-side encryption KMS encryption context. If unset and the key ID override is set, the encryption context will not be provided to S3. Ignored if the SSE type override is not set or the type is not `SSE-KMS`. Other storage backends may support encryption at rest configuring it directly at the storage level.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: migrate-to-kubernetes-version-1.25.md

title: "Migrate to Kubernetes version 1.25" menuTitle: "Migrate to Kubernetes 1.25" description: "Learn how to migrate the Helm chart to Kubernetes version 1.25" weight: 10 This procedure describes how to prepare a `mimir-distributed` Helm chart release for an upgrade to Kubernetes 1.25. Kubernetes version 1.25 removes the support for the deprecated object. You can learn more about this topic by visiting . Due to how Helm , PodSecurityPolicy objects must already be removed from the release prior to upgrading to Kubernetes version 1.25. If you are using PodSecurityPolicy on Kubernetes 1.24, this is a breaking change. `mimir-distributed` Helm chart versions before 5.0 used PodSecurityPolicy by default in Kubernetes version 1.24. You have Kubernetes version 1.22, 1.23 or 1.24. This procedure is only applicable if `rbac.create` is `true` and `rbac.type` is `psp` in your current Helm values. This was the case by default before Helm chart version 5.0. If `rbac.create` is `false` or `rbac.type` is `scc`, then there is nothing to do, skip the whole procedure. Optionally follow the Kubernetes guide to replace PodSecurityPolicy. Set the `rbac.create` value to `false`. Upgrade the deployment. The chart will not install PodSecurityPolicy objects anymore. {{% admonition type="note" %}} Grafana Mimir does not require any special permissions on the hosts that it runs on. Because of this, you can deploy it in environments that enforce the Kubernetes . {{% /admonition %}} If you have upgraded to Kubernetes 1.25 and see the following error containing PodSecurityPolicy during a Helm release upgrade: ``` resource mapping not found for name: "mimir" namespace: "" from "": no matches for kind "PodSecurityPolicy" in version "policy/v1beta1" ensure CRDs are installed first ``` This happens because Helm stores the current release in a Secret in the namespace. If the current release contains removed resources the `helm` command fails to determine the current state of the release. To remove the PodSecurityPolicy from the Helm release history follow this procedure: Optionally follow the Kubernetes guide to replace PodSecurityPolicy. Set the `rbac.create` value to `false`. Remove PodSecurityPolicy from the Helm release history following the Helm documentation in order to proceed with the upgrade. Upgrade the release. The upgrade should succeed now.
Project: HertzBeat (Observability and Analysis / Observability)
File: linux.md

id: linux title: MonitoringLinux operating system monitoring sidebar_label: Linux operating system keywords: [open source monitoring tool, open source linux monitoring tool, monitoring linux metrics] Collect and monitor the general performance Metrics of Linux operating system. | 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 | Port provided by Linux SSH. The default is 22 | | Username | SSH connection user name, optional | | Password | SSH connection password, optional | | 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 | | -- | -- | -- | | hostname | none | Host name | | version | none | Operating system version | | uptime | none | System running time | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | info | none | CPU model | | cores | cores | Number of CPU cores | | interrupt | number | Number of CPU interrupts | | load | none | Average load of CPU in the last 1/5/15 minutes | | context_switch | number | Number of current context switches | | usage | % | CPU usage | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | total | Mb | Total memory capacity | | used | Mb | User program memory | | free | Mb | Free memory capacity | | buff_cache | Mb | Memory occupied by cache | | available | Mb | Remaining available memory capacity | | usage | % | Memory usage | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | disk_num | blocks | Total number of disks | | partition_num | partitions | Total number of partitions | | block_write | blocks | Total number of blocks written to disk | | block_read | blocks | Number of blocks read from disk | | write_rate | iops | Rate of writing disk blocks per second | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | interface_name | none | Network card name | | receive_bytes | byte | Inbound data traffic(bytes) | | transmit_bytes | byte | Outbound data traffic(bytes) | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | filesystem | none | File system name | | used | Mb | Used disk size | | available | Mb | Available disk size | | usage | % | usage | | mounted | none | Mount point directory |
Project: Checkmk (Observability and Analysis / Observability)
File: 16492.md

key | value | date | 2024-02-15T10:04:03+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes The version and hardware information for a NetApp system was only displayed for the first retrieved node. With this werk we now display information for each retrieved node.
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: Promtail.md

weight: 4 title: Promtail setup disableToc: true menu: docs: parent: "victorialogs-data-ingestion" weight: 4 aliases: /VictoriaLogs/data-ingestion/Promtail.html is a default log shipper for Grafana Loki. Promtail can be configured to send the collected logs to VictoriaLogs according to the following docs. Specify section in the configuration file for sending the collected logs to : ```yaml clients: url: http://localhost:9428/insert/loki/api/v1/push?streamfields=instance,job,host,app ``` Substitute `localhost:9428` address inside `clients` with the real TCP address of VictoriaLogs. By default VictoriaLogs stores all the ingested logs into a single . Storing all the logs in a single log stream may be not so efficient, so it is recommended to specify `streamfields` query arg with the list of labels, which uniquely identify log streams. There is no need in specifying all the labels Promtail generates there - it is usually enough specifying `instance` and `job` labels. See for details. See also for details on other supported query args. There is no need in specifying `msgfield` and `timefield` query args, since VictoriaLogs automatically extracts log message and timestamp from the ingested Loki data. It is recommended verifying whether the initial setup generates the needed and uses the correct . This can be done by specifying `debug` and inspecting VictoriaLogs logs then: ```yaml clients: url: http://localhost:9428/insert/loki/api/v1/push?streamfields=instance,job,host,app&debug=1 ``` If some must be skipped during data ingestion, then they can be put into `ignore_fields` . For example, the following config instructs VictoriaLogs to ignore `filename` and `stream` fields in the ingested logs: ```yaml clients: url: http://localhost:9428/insert/loki/api/v1/push?streamfields=instance,job,host,app&ignore_fields=filename,stream ``` By default the ingested logs are stored in the `(AccountID=0, ProjectID=0)` . If you need storing logs in other tenant, then specify the needed tenant via `tenant_id` field in the The `tenant_id` must have `AccountID:ProjectID` format, where `AccountID` and `ProjectID` are arbitrary uint32 numbers. For example, the following config instructs VictoriaLogs to store logs in the `(AccountID=12, ProjectID=34)` : ```yaml clients: url: http://localhost:9428/insert/loki/api/v1/push?streamfields=instance,job,host,app&debug=1 tenant_id: "12:34" ``` The ingested log entries can be queried according to . See also docs.
Project: Checkmk (Observability and Analysis / Observability)
File: 16800.md

key | value | date | 2024-04-19T15:28:03+00:00 version | 2.3.0b6 class | fix edition | cre component | wato level | 1 compatible | yes When running the SNMP connection tests for a host that has SNMPv3 credentials configured, the SNMPv1 and SNMPv2 connection tests crashed. With the Inline SNMP backend, the corresponding error message read "argument 2 must be str, not tuple". With the Classic backend, there was no error message at all.
Project: Checkmk (Observability and Analysis / Observability)
File: 16612.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-03-27T14:22:37+00:00 level | 1 class | fix component | notifications edition | cre Previously, it was possible for users with the "Notification configuration" permission to edit notification rules even if they did not have the permission to the plugin that was being used in the rule. When such a user edited such a rule, they were able to overwrite the notification plugin with any plugin they were allowed to use. This werk stops users from editing rules that use notification plugins they don't have access to.
Project: Checkmk (Observability and Analysis / Observability)
File: 16583.md

key | value | date | 2024-03-14T13:43:44+00:00 version | 2.4.0b1 class | fix edition | cre component | wato level | 1 compatible | yes Before this Werk, when subfolders were listed and some of them had the same title, only the last one of the group was displayed. This Werk fixes that problem and now all folders are displayed.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: PROXYPROTOCOL.md

Note: enabling PROXY protocol support does not break existing setups (e.g. non-PROXY connections are still accepted), however it does add a small overhead to the connection handling. To enable PROXY protocol support, set `Config.ProxyProtocolEnabled` to `true` before initializing a `Server` in your application. This enables PROXY protocol for both HTTP and gRPC servers. ```go cfg := &Config{ ProxyProtocolEnabled: true, // ... } server := NewServer(cfg) // ... ``` PROXY protocol is supported by using . Both PROXY v1 and PROXY v2 are supported out of the box. When enabled, incoming connections are checked for the PROXY header, and if present, the connection information is updated to reflect the original source address. Most commonly, you will use the source address via . ```go server.HTTP.HandleFunc("/your-endpoint", func(w http.ResponseWriter, r *http.Request) { ip, _, err := net.SplitHostPort(r.RemoteAddr) // ... }) ```
Project: EaseAgent (Observability and Analysis / Observability)
File: use-on-host.md

Download the agent, Once youve get the EaseAgent, these steps to start the Java agent installation. Create a directory for your EaseAgent, such as /opt/easeagent. On Windows, the EaseAgent must be in a subdirectory of your application servers directory, such as C:\Tomcat 1.0\easeagent. Copy the easeagent.jar file into your new directory. To use the EaseAgent with your JVM, youll need to pass the -javaagent argument. In the commands below, replace EASEAGENTPATH with the path of the EaseAgent directory you created, eg. /opt/easeagent. Pass the -javaagent argument to the command line where you start your app. Make sure to add it before the -jar argument: ``` java -javaagent:$EASEAGENTPATH/easeagent.jar -jar app.jar ``` Pass the -javaagent argument on catalina.sh, catalina.bat or the GUI. Linux with catalina.sh In tomcat catalina.sh file, use the JAVA_OPTS environment variable: ``` export CATALINAOPTS="$CATALINAOPTS -javaagent:EASEAGENTPATH/easeagent.jar" ``` Windows with catalina.bat In tomcat catalina.bat file, set the JAVA_OPTS variable near the top of the file: ``` set "CATALINAOPTS=%CATALINAOPTS% -javaagent:EASEAGENTPATH\easeagent.jar" ``` Windows with GUI On Windows with GUI, add the full EaseAgent path to your Java options: In Apache Tomcat, click Configure Tomcat, and then click Java. In the Java Options text box, enter the following argument: ``` -javaagent:EASEAGENTPATH\easeagent.jar ``` Pass the -javaagent in jetty.sh or the start.ini file: jetty.sh ``` export JAVAOPTIONS="${JAVAOPTIONS} -javaagent:EASEAGENTPATH/easeagent.jar" ``` start.ini ``` -javaagent:EASEAGENTPATH/easeagent.jar ``` If youre using Wildfly 11+, to pass the -javaagent argument on Linux or Windows. Add the Java agent and make it visible to the JBoss modules by adding the following lines to your file. Linux with standalone.conf: ``` JAVAOPTS="$JAVAOPTS -javaagent:EASEAGENTPATH/easeagent.jar" JAVAOPTS="$JAVAOPTS -Djboss.modules.system.pkgs=$JBOSSMODULESSYSTEM_PKGS,com.easeagent" ``` Windows with standalone.bat.conf: ``` set "JAVAOPTS=%JAVAOPTS% -javaagent:EASEAGENTPATH\easeagent.jar" set "JAVAOPTS=%JAVAOPTS% -Djboss.modules.system.pkgs=%JBOSSMODULESSYSTEM_PKGS%,com.easeagent" ``` Deploy your application to start using the EaseAgent to send data to MegaCloud.
Project: Cortex (Observability and Analysis / Observability)
File: how-to-update-the-build-image.md

title: "How to update the build image" linkTitle: "How to update the build image" weight: 5 slug: how-to-update-the-build-image The build image currently can only be updated by a Cortex maintainer. If you're not a maintainer you can still open a PR with the changes, asking a maintainer to assist you publishing the updated image. The procedure is: Update `build-image/Dockerfile` Run `go env` and make sure `GOPROXY=https://proxy.golang.org,direct` (Go's default). Some environment may required `GOPROXY=direct`, and if you push a build image with this, build workflow on GitHub will take a lot longer to download modules. `docker login quay.io`. Note that pushing to `quay.io/cortexproject/build-image` repository can only be done by a maintainer. Build the and publish the image by using `make push-multiarch-build-image`. This will build and push multi-platform docker image (for linux/amd64 and linux/arm64). Running this step successfully requires , but does not require a specific platform. Replace the image tag in `.github/workflows/*` (there may be multiple references) and Makefile (variable `LATESTBUILDIMAGE_TAG`). If you are updating Go's runtime version be sure to change `actions/setup-go`'s `go-version` in ``.github/workflows/*`. Open a PR and make sure the CI with new build-image passes