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

This alert is triggered when the TCP memory usage on your system is higher than the allowed limit. High TCP memory utilization can cause applications to become unresponsive and result in poor system performance. To resolve the TCP memory alert, you can follow these steps: Verify the current TCP memory usage: Check the current values of TCP memory buffers by running the following command: ``` cat /proc/sys/net/ipv4/tcp_mem ``` The output consists of three values: low, pressure (memory pressure), and high (memory limit). Monitor system performance: Use the `vmstat` command to monitor the system's performance and understand the memory consumption in detail: ``` vmstat 5 ``` This will display the system's statistics every 5 seconds. Pay attention to the `si` and `so` columns, which represent swap-ins and swap-outs. High values in these columns may indicate memory pressure on the system. Identify high memory-consuming processes: Use the `top` command to identify processes that consume the most memory: ``` top -o %MEM ``` Look for processes with high memory usage and determine if they are necessary for your system. If they are not, consider stopping or killing these processes to free up memory. Increase the TCP memory: Follow the steps mentioned in the provided guide to increase the TCP memory. This includes: Increase the `tcp_mem` bounds using the `sysctl` command. Verify the change and test it with the same workload that triggered the alarm originally. If the change works, make it permanent by adding the new values to `/etc/sysctl.conf`. Reload the sysctl settings with `sysctl -p`.
Project: Thanos (Observability and Analysis / Observability)
File: 202005-scalable-rule-storage.md

type: proposal title: Scalable Rule Storage status: complete menu: proposals-done There is no way to scale rule evaluation and storage today except functionally sharding rules onto multiple instances of the `thanos rule` component. However, we have already solved scaling storage of time-series across multiple processes: `thanos receive`. To scale rule evaluations and storage this proposal proposes to allow the `thanos rule` component to have a stateless mode, storing results of queries by sending it to a `thanos receive` hashring instead of storing them locally. A few large rules can create a significant amount of resulting time-series, which limits the scalability of Thanos Rule, as it uses a single embedded TSDB. Additionally, scaling out the rule component in terms of rule evaluations causes further defragmentation of TSDB blocks, as multiple rule instances produce hard to deduplicate samples. While doable with vertical compaction, it might cause some operational complexity and unnecessary load on the system. Allow scaling storage and execution of rule evaluations. Run all rule component e2e tests with new mode as well. Allow specifying one of the following flags: `--remote-write` `--remote-write.config` or `--remote-write.config-file` flag following the same scheme as `--remote-write.tenant-label-name` which label-value to use to set the tenant to be communicated to the receive component If any of these are specified the ruler would run a stateless mode, without local storage, and instead writing samples to the configured remote server, which must implement the `storepb.WritableStore` gRPC service. Continue to allow spreading load only by functionally sharding rules. Implement functionality alongside the existing architecture of the rule component. This it stands this proposal does not cover any multi tenancy aspects of the receive component there are two strategies that we could go with: Have a configurable label that determines the tenant in requests. Change the receive component to instead of using a header to determine the tenant use a label of the series being written. As the first exists, this proposal will continue with this approach and potentially reevaluate in the future. For a start this functionality will be implemented alongside the current embedded TSDB. Once experience with this new mode has been gathered, it may be reevaluated to remove the embedded TSDB, but no changes planned for now. Alternatively the receive component could also be embedded into the rule component in an attempt to minimize code paths, but retain functionality.
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_disconnect_sent_reason_not_normal.md

This alert indicates that VerneMQ, a high-performance, distributed MQTT message broker, is sending an abnormal number of v5 DISCONNECT packets in the last minute. This may signify an issue in the MQTT messaging system and impact the functioning of IoT devices or other MQTT clients connected to VerneMQ. In MQTT v5, the DISCONNECT packet is sent by a client or server to indicate the end of a session. A "not normal" DISCONNECT packet, generally refers to a DISCONNECT packet sent with a reason code other than "Normal Disconnection" (0x00). These reason codes might include: Protocol errors Invalid DISCONNECT payloads Authorization or authentication violations Exceeded keep-alive timers Server/connection errors User-triggered disconnects A high number of not normal DISCONNECT packets, might indicate an issue in your MQTT infrastructure, misconfigured clients, or security breaches. Inspect VerneMQ logs: VerneMQ logs can provide detailed information about connections, disconnections, and possible issues. Check the VerneMQ logs for errors and information about unusual disconnects. ``` cat /var/log/vernemq/console.log cat /var/log/vernemq/error.log ``` Monitor VerneMQ status: Use the `vmq-admin` command-line tool to monitor VerneMQ and view its runtime status. Check the number of connected clients, subscriptions, and sessions. ``` sudo vmq-admin cluster show sudo vmq-admin session show sudo vmq-admin listener show ``` Check clients and configurations: Review client configurations for potential errors, like incorrect authentication credentials, misconfigured keep-alive timers, or invalid packet formats. If possible, isolate problematic clients and test their behavior. Consider resource limitations: If your VerneMQ instance is reaching resource limitations (CPU, memory, network), it might automatically terminate some connections to maintain performance. Monitor system resources using the `top` command or tools like Netdata. Evaluate security: If the issue persists, consider checking the security of your MQTT infrastructure. Investigate possible cyber threats, such as a DDoS attack or unauthorized clients attempting to connect.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-4-2.md

hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 8.4.2 <!-- Auto generated by update changelog github action --> OAuth: Add setting to skip org assignment for external users. , Tracing: Add option to map tag names to log label names in trace to logs settings. , Explore: Fix closing split pane when logs panel is used. ,
Project: Elastic (Observability and Analysis / Observability)
File: mv_dedupe.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Remove duplicate values from a multivalued field. ``` ROW a=["foo", "foo", "bar", "foo"] | EVAL dedupea = MVDEDUPE(a) ``` Note: `MV_DEDUPE` may, but won't always, sort the values in the column.
Project: SkyWalking (Observability and Analysis / Observability)
File: Compatible-with-other-javaagent-bytecode-processing.md

When using the SkyWalking agent, some other agents, such as Arthas, can't work properly. https://github.com/apache/skywalking/pull/4858 The retransform classes in the Java agent conflict with the SkyWalking agent, as illustrated in this The SkyWalking agent uses ByteBuddy to transform classes when the Java application starts. ByteBuddy generates auxiliary classes with different random names every time. When another Java agent retransforms the same class, it triggers the SkyWalking agent to enhance the class again. Since the bytecode has been regenerated by ByteBuddy, the fields and imported class names have been modified, and the JVM verifications on class bytecode have failed, the retransform classes would therefore be unsuccessful. Enable the class cache feature Add JVM parameters: `-Dskywalking.agent.iscacheenhancedclass=true -Dskywalking.agent.classcache_mode=MEMORY` Or uncomment the following options in `agent.conf`: ``` agent.iscacheenhancedclass = ${SWAGENTCACHECLASS:false} agent.classcachemode = ${SWAGENTCLASSCACHEMODE:MEMORY} ``` If the class cache feature is enabled, save the instrumented class bytecode to memory or a temporary file. When other Java agents retransform the same class, the SkyWalking agent first attempts to load from the cache. If the cached class is found, it will be used directly without regenerating an auxiliary class with a new random name. Then, the process of the subsequent Java agent will not be affected. Class cache save mode We recommend saving cache classes to memory, if it takes up more memory space. Alternatively, you can use the local file system. Set the class cache mode in one of the folliwng ways: `-Dskywalking.agent.classcachemode=MEMORY` : save cache classes to Java memory. `-Dskywalking.agent.classcachemode=FILE` : save cache classes to SkyWalking agent path '/class-cache'. Or modify these options in `agent.conf`: `agent.classcachemode = ${SWAGENTCLASSCACHEMODE:MEMORY}` `agent.classcachemode = ${SWAGENTCLASSCACHEMODE:FILE}`
Project: Checkmk (Observability and Analysis / Observability)
File: 16626.md

key | value | date | 2024-03-20T13:23:59+00:00 version | 2.4.0b1 class | feature edition | cre component | omd level | 1 compatible | yes Werk 16501 introduced a command to start a background job which triggers the regeneration of the API specification. This werk now includes execution of this command also during omd start, restart, and reload. With this mechanism the execution during `cmk-update-config` is no longer needed. Based on Werk 15724 the specification is now updated in these situations: Create the initial spec after a site has been created Update the spec after a site has been copied, restored or renamed Update the spec when the apache process is started, restarted or reloaded
Project: Netdata (Observability and Analysis / Observability)
File: ping_host_latency.md

This alert calculates the average latency (`ping round-trip time`) to a network host (${label:host}) over the last 10 seconds. If you receive this alert, it means there might be issues with your network connectivity or host responsiveness. Latency is the time it takes for a packet of data to travel from the sender to the receiver, and back from the receiver to the sender. In this case, we're measuring the latency using the `ping` command, which sends an ICMP echo request to the host and then waits for the ICMP echo reply. Double-check the network connection: Verify the network connectivity between your system and the target host. Check if the host is accessible via other tools such as `traceroute` or `mtr`. ``` traceroute ${label:host} mtr ${label:host} ``` Check for packet loss: Packet loss can make latency appear higher than it actually is. Use the `ping` command to check for packet loss: ``` ping -c 10 ${label:host} ``` Look for the percentage of packet loss in the output. Investigate the host: If no packet loss is detected and the network connection is stable, the problem might be related to the host itself. Check the host for overloaded resources, such as high CPU usage, disk I/O, or network traffic. Check DNS resolution: If the alert's `${label:host}` is a domain name, make sure that DNS resolution is working properly: ``` nslookup ${label:host} ``` Verify firewall and routing: Check if any firewall rules or routing policies might be affecting the network traffic between your system and the target host.
Project: Cortex (Observability and Analysis / Observability)
File: glossary.md

title: "Glossary" linkTitle: "Glossary" weight: 999 slug: glossary The blocks storage is a Cortex storage engine based on Prometheus TSDB, which only requires an object store (eg. AWS S3, Google GCS, ...) as backend storage. For more information, please refer to the documentation. A chunk is an object containing compressed timestamp-value pairs. A single chunk contains timestamp-value pairs for several series. Churn is the frequency at which series become idle. A series become idle once it's not exported anymore by the monitored targets. Typically, series become idle when the monitored target itself disappear (eg. the process or node gets terminated). Series flushing is the operation run by ingesters to offload time series from memory and store them in the long-term storage. The HA Tracker is a feature of Cortex distributor which is used to deduplicate received series coming from two (or more) Prometheus servers configured in HA pairs. For more information, please refer to the guide "". The hash ring is a distributed data structure used by Cortex for sharding, replication and service discovery. The hash ring data structure gets shared across Cortex replicas via gossip or a key-value store. For more information, please refer to the documentation. See . See . A sample is a single timestamped value in a time series. For example, given the series `nodecpuseconds_total{instance="10.0.0.1",mode="system"}` its stream of values (samples) could be: ``` 11775 @1603812134 11790 @1603812149 11805 @1603812164 11819 @1603812179 11834 @1603812194 ``` In the Prometheus ecosystem, a series (or time series) is a single stream of timestamped values belonging to the same metric, with the same set of label key-value pairs. For example, given a single metric `nodecpuseconds_total` you may have multiple series, each one uniquely identified by the combination of metric name and unique label key-value pairs: ``` nodecpuseconds_total{instance="10.0.0.1",mode="system"} nodecpuseconds_total{instance="10.0.0.1",mode="user"} nodecpuseconds_total{instance="10.0.0.2",mode="system"} nodecpuseconds_total{instance="10.0.0.2",mode="user"} ``` A tenant (also called "user" or "org") is the owner of a set of series written to and queried from Cortex. Cortex multi-tenancy support allows you to isolate series belonging to different tenants. For example, if you have two tenants `team-A` and `team-B`, `team-A` series will be isolated from `team-B`, and each team will be able to query only their own series. For more information, please refer to: See . See . The Write-Ahead Log (WAL) is an append only log stored on disk used by ingesters to recover their in-memory state after the process gets restarted, either after a clear shutdown or an abruptly termination. For more information, please refer to .
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: seccomp.md

title: Gadget seccomp The seccomp gadget traces system calls for each container in order to generate seccomp policies. The seccomp policies can be generated in two ways: on demand with the gadget.kinvolk.io/operation=generate annotation. In this case, the Trace.Spec.Filter should specify the namespace and pod name to the exclusion of other fields because there can be only one SeccompProfile written in the Trace.Status.Output or in the SeccompProfile resource named by Trace.Spec.Output. The on-demand generation supports the outputMode Status and ExternalResource. automatically when containers matching the Trace.Spec.Filter terminate. In this case, all filters are supported. The at-termination generation supports the outputMode ExternalResource and Stream. The seccomp policies can be written in the Status field of the Trace custom resource, or in SeccompProfiles custom resources managed by the [Kubernetes Security Profiles Operator](https://github.com/kubernetes-sigs/security-profiles-operator). SeccompProfiles will have the following annotations: seccomp.gadget.kinvolk.io/trace: the namespaced name of the Trace custom resource that generated this SeccompProfile seccomp.gadget.kinvolk.io/node: the node where this SeccompProfile was generated seccomp.gadget.kinvolk.io/pod: the pod namespaced name of the pod that was traced seccomp.gadget.kinvolk.io/container: the container name in the pod that was traced seccomp.gadget.kinvolk.io/ownerReference-APIVersion: the ownerReference&#39;s APIVersion of the pod that was traced seccomp.gadget.kinvolk.io/ownerReference-Kind: the ownerReference&#39;s Kind of the pod that was traced seccomp.gadget.kinvolk.io/ownerReference-Name: the ownerReference&#39;s Name of the pod that was traced seccomp.gadget.kinvolk.io/ownerReference-UID: the ownerReference&#39;s UID of the pod that was traced SeccompProfiles will have the same labels as the Trace custom resource that generated them. They don&#39;t have meaning for the seccomp gadget. They are merely copied for convenience. ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: seccomp namespace: gadget labels: team: devops spec: node: minikube gadget: seccomp filter: namespace: default runMode: Manual outputMode: ExternalResource output: gadget/myseccomp ``` Start recording syscalls ```bash $ kubectl annotate -n gadget trace/seccomp \ gadget.kinvolk.io/operation=start ``` Generate a seccomp profile for the pod specified in Trace.Spec.Filter. The namespace and pod name should be specified at the exclusion of other fields. ```bash $ kubectl annotate -n gadget trace/seccomp \ gadget.kinvolk.io/operation=generate ``` Stop recording syscalls ```bash $ kubectl annotate -n gadget trace/seccomp \ gadget.kinvolk.io/operation=stop ``` ExternalResource Status Stream
Project: Elastic (Observability and Analysis / Observability)
File: mv_slice.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Returns a subset of the multivalued field using the start and end index values. ``` row a = [1, 2, 2, 3] | eval a1 = mvslice(a, 1), a2 = mvslice(a, 2, 3) ```
Project: Checkmk (Observability and Analysis / Observability)
File: 15719.md

key | value | compatible | yes version | 2.3.0b1 date | 2024-01-18T06:57:22+00:00 level | 1 class | fix component | checks edition | cre In case a docker node section can not be computed by the mk_docker agent plugin, the "Docker node info" service reports about the error in detail. Until this werk, the "Check_MK" service did also raise an issue regarding the missing agent section, like: "Missing monitoring data for plugins: dockernodedisk_usage". This duplicate information is now suppressed, reducing the number of notification Checkmk produces in such situations.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_networkpolicy.NetworkPolicy.md

title: "Class: NetworkPolicy" linkTitle: "NetworkPolicy" slug: "libk8snetworkpolicy.NetworkPolicy" .NetworkPolicy `any` `NetworkPolicy` new NetworkPolicy(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeNetworkPolicy\>('NetworkPolicy').constructor `Static` apiEndpoint: `Object` | Name | Type | | : | : | | `scale?` | { `get`: (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> ; `put`: (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> } | | `scale.get` | (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> | | `scale.put` | (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> | _ `Static` className: `string` makeKubeObject<KubeNetworkPolicy\>('NetworkPolicy').className `Static` `get` pluralName(): `string` `string` `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeNetworkPolicy\>('NetworkPolicy').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeNetworkPolicy\>('NetworkPolicy').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeNetworkPolicy\>('NetworkPolicy').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeNetworkPolicy\>('NetworkPolicy').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeNetworkPolicy\>('NetworkPolicy').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeNetworkPolicy\>('NetworkPolicy').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeNetworkPolicy\>('NetworkPolicy').useList
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_registry.DefaultAppBarAction.md

title: "Enumeration: DefaultAppBarAction" linkTitle: "DefaultAppBarAction" slug: "plugin_registry.DefaultAppBarAction" .DefaultAppBarAction CLUSTER = `"CLUSTER"` _ NOTIFICATION = `"NOTIFICATION"` _ SETTINGS = `"SETTINGS"` _ USER = `"USER"`
Project: Grafana Mimir (Observability and Analysis / Observability)
File: about-tenant-ids.md

aliases: ../configuring/about-tenant-ids/ description: Learn about tenant ID restrictions. menuTitle: Tenant IDs title: About Grafana Mimir tenant IDs weight: 10 Within a Grafana Mimir cluster, the tenant ID is the unique identifier of a tenant. For information about how Grafana Mimir components use tenant IDs, refer to . Tenant IDs must be less-than or equal-to 150 bytes or characters in length and can only include the following supported characters: Alphanumeric characters `0-9` `a-z` `A-Z` Special characters Exclamation point (`!`) Hyphen (`-`) Underscore (`_`) Single period (`.`) Asterisk (`*`) Single quote (`'`) Open parenthesis (`(`) Close parenthesis (`)`) {{< admonition type="note" >}} For security reasons, `.` and `..` aren't valid tenant IDs. {{< /admonition >}} {{< admonition type="note" >}} `mimir_cluster` isn't a valid tenant ID because Mimir uses the name internally. {{< /admonition >}} All other characters, including slashes and whitespace, aren't supported.