cwielenb/CNCF-Dataset huggingface dataset:
Project: Opstrace (Observability and Analysis / Observability)
File: sending-metrics-with-prometheus.md

In this guide we show how to configure a Prometheus instance to securely send metrics to your Opstrace instance. An Opstrace instance. A decision: for which Opstrace tenant would you like to send data? An Opstrace tenant authentication token file (for the tenant of your choice). Also see . A Prometheus instance can be instructed to replicate its state to a remote system by defining a configuration block. What follows is the basic structure of this configuration block to make Prometheus send data to your Opstrace instance: ```yaml remote_write: url: <string> bearertokenfile: <filename> tls_config: insecureskipverify: <boolean> ``` This is the tenant-specific data API endpoint of an Opstrace instance for ingesting metrics. The endpoint URL is constructed using the tenant name and the instance name: ```yaml url: https://cortex.${TENANTNAME}.${INSTANCENAME}.opstrace.io/api/v1/push ``` Example: ```yaml url: https://cortex.default.test.opstrace.io/api/v1/push ``` Your Opstrace instance exposes the metrics ingestion API securely. For authenticating the client towards the Opstrace instance, the client has to present a tenant-specific data API authentication token with every request. To achieve that, we use the `bearertokenfile` parameter: Example: ```yaml bearertokenfile: /var/run/default-tenant/tenant-api-token-default ``` TLS is used for establishing a secure, private transport between the Prometheus instance and the Opstrace instance. By default, the Prometheus instance attempts to verify the certificate exposed by the Opstrace instance against its trust store, for establishing authenticity of the Opstrace instance towards Prometheus. Depending on the `cert_issuer` instance configuration option (see ) you may want to disable server certificate verification for testing purposes. This can be achieved via ```yaml tls_config: insecureskipverify: true ``` This is required for example when using `letsencrypt-staging` as `cert_issuer`. The following resources provide further assistance in understanding and configuring Prometheus' `remote_write` protocol:
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_event.KubeEvent.md

title: "Interface: KubeEvent" linkTitle: "KubeEvent" slug: "libk8sevent.KubeEvent" .KubeEvent involvedObject: `Object` | Name | Type | | : | : | | `apiVersion` | `string` | | `fieldPath` | `string` | | `kind` | `string` | | `name` | `string` | | `namespace` | `string` | | `resourceVersion` | `string` | | `uid` | `string` | _ message: `string` _ metadata: _ reason: `string` _ type: `string`
Project: Grafana (Observability and Analysis / Observability)
File: team_sync.md

aliases: ../../httpapi/externalgroup_sync/ ./externalgroupsync/ canonical: /docs/grafana/latest/developers/httpapi/teamsync/ description: Grafana Team Sync HTTP API keywords: grafana http documentation api team teams group member enterprise labels: products: enterprise oss title: Team Sync HTTP API Team Sync is only available in Grafana Enterprise. Read more about . If you are running Grafana Enterprise, for some endpoints you'll need to have specific permissions. Refer to for more information. `GET /api/teams/:teamId/groups` Required permissions See note in the for an explanation. | Action | Scope | | - | -- | | teams.permissions:read | teams:\* | Example Request: ```http GET /api/teams/1/groups HTTP/1.1 Accept: application/json Content-Type: application/json Authorization: Basic YWRtaW46YWRtaW4= ``` Example Response: ```http HTTP/1.1 200 Content-Type: application/json [ { "orgId": 1, "teamId": 1, "groupId": "cn=editors,ou=groups,dc=grafana,dc=org" } ] ``` Status Codes: 200 - Ok 401 - Unauthorized 403 - Permission denied `POST /api/teams/:teamId/groups` Required permissions See note in the for an explanation. | Action | Scope | | -- | -- | | teams.permissions:write | teams:\* | Example Request: ```http POST /api/teams/1/groups HTTP/1.1 Accept: application/json Content-Type: application/json Authorization: Basic YWRtaW46YWRtaW4= { "groupId": "cn=editors,ou=groups,dc=grafana,dc=org" } ``` Example Response: ```http HTTP/1.1 200 Content-Type: application/json {"message":"Group added to Team"} ``` Status Codes: 200 - Ok 400 - Group is already added to this team 401 - Unauthorized 403 - Permission denied 404 - Team not found `DELETE /api/teams/:teamId/groups?groupId=external-group-id` Required permissions See note in the for an explanation. | Action | Scope | | -- | -- | | teams.permissions:write | teams:\* | Example Request: ```http DELETE /api/teams/1/groups?groupId=cn%3Deditors%2Cou%3Dgroups%2Cdc%3Dgrafana%2Cdc%3Dorg HTTP/1.1 Accept: application/json Content-Type: application/json Authorization: Basic YWRtaW46YWRtaW4= ``` Example Response: ```http HTTP/1.1 200 Content-Type: application/json {"message":"Team Group removed"} ``` Status Codes: 200 - Ok 401 - Unauthorized 403 - Permission denied 404 - Team not found/Group not found
Project: Netdata (Observability and Analysis / Observability)
File: vsphere_outbound_packets_dropped.md

This alert is generated when the number of outbound `packets dropped` on a network interface of a `vSphere Virtual Machine` exceeds a specified threshold in the last 10 minutes. Packet drops are an indication of network congestion or misconfiguration, and can cause degraded performance and application slowdowns. Identify the Virtual Machine (VM) and network interface experiencing the issue: Use the details in the alert to find the Virtual Machine and network interface that triggered the alert. Note the name and location of the VM and the associated network interface. Check for network congestion or misconfiguration: Possible reasons for dropped packets can include network congestion, faulty network hardware, or VM configuration issues. Common ways to check for these problems are: Check the performance charts in the vSphere Client for the affected VM, specifically the `Network` section, to visualize the network usage, dropped packets, and other relevant metrics. Verify the VM's network adapter settings are correct, such as its speed, duplex settings, and MTU size. Check the VM's host machine and its physical network connections for issues, like overutilization or faulty hardware. Review any network traffic shaping policies on the vSphere side, such as rate-limiters or Quality of Service (QoS) configurations. Examine the VM's guest OS network settings for configuration issues, such as incorrect IP addresses, subnet masks, or gateway settings. Diagnose application or protocol issues: If the network settings and hardware appear to be functioning correctly, the dropped packets could be a result of specific application or protocol issues. Inspect the network traffic to see if it's associated with certain applications. In the VM's guest OS, use tools like `tcpdump`, `wireshark`, or `iftop` to capture network packets and check for problematic patterns, or review application logs for any network issues. Address the problem and monitor the situation: Once you've identified and addressed the underlying cause of the dropped packets, continue monitoring the VM's network performance to verify that the issue has been resolved. If the alert persists or the problem comes back, consider escalating the issue to the network engineering team or VMware support for further assistance.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: format.md

title: Format weight: 200 generated_file: true Specify how to format output records. For details, see . ```yaml spec: format: path: /tmp/logs/${tag}/%Y/%m/%d.%H.%M format: type: single_value add_newline: true message_key: msg ``` When type is single_value add '\n' to the end of the message Default: true When type is single_value specify the key holding information Output line formatting: outfile,json,ltsv,csv,msgpack,hash,singlevalue Default: json
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_replicaSet.ReplicaSet.md

title: "Class: ReplicaSet" linkTitle: "ReplicaSet" slug: "libk8sreplicaSet.ReplicaSet" .ReplicaSet `any` `ReplicaSet` new ReplicaSet(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeReplicaSet\>('ReplicaSet').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<KubeReplicaSet\>('ReplicaSet').className `get` spec(): `Object` `Object` | Name | Type | | : | : | | `minReadySeconds` | `number` | | `replicas` | `number` | | `selector` | | | `template` | { `metadata?`: ; `spec`: } | | `template.metadata?` | | | `template.spec` | | _ `get` status(): `Object` `Object` | Name | Type | | : | : | | `availableReplicas` | `number` | | `conditions` | `Omit`<, ``"lastProbeTime"`` \| ``"lastUpdateTime"``\>[] | | `fullyLabeledReplicas` | `number` | | `observedGeneration` | `number` | | `readyReplicas` | `number` | | `replicas` | `number` | getContainers(): [] [] _ getMatchLabelsList(): `string`[] `string`[] _ `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeReplicaSet\>('ReplicaSet').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeReplicaSet\>('ReplicaSet').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeReplicaSet\>('ReplicaSet').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeReplicaSet\>('ReplicaSet').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeReplicaSet\>('ReplicaSet').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeReplicaSet\>('ReplicaSet').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeReplicaSet\>('ReplicaSet').useList
Project: Netdata (Observability and Analysis / Observability)
File: btrfs_data.md

This alert is triggered when the percentage of used Btrfs data space exceeds the configured threshold. Btrfs (B-tree file system) is a modern copy-on-write (CoW) filesystem for Linux which focuses on fault tolerance, repair, and easy administration. This filesystem also provides advanced features like snapshots, checksums, and multi-device spanning. High Btrfs data usage indicates that a significant amount of the allocated space for data blocks in the filesystem is being used. This could be a result of many factors, such as large files, numerous smaller files, or multiple snapshots. Before you attempt any troubleshooting, make sure you have backed up your data to prevent potential data loss or corruption. Add more physical space: You can add a new disk to the filesystem, depending on your infrastructure and disk RAID configuration. Remember to unmount the drive if it's already mounted, then use the `btrfs device add` command to add the new disk and balance the system. Delete snapshots: Review the snapshots in your Btrfs filesystem and delete any unnecessary snapshots. Use the `btrfs subvolume list` command to find snapshots and `btrfs subvolume delete` to remove them. Enable compression: By enabling compression, you can save disk space without deleting files or snapshots. Add the `compress=alg` mount option in your `fstab` configuration file or during the mount procedure, where `alg` is the compression algorithm you want to use (e.g., `zlib`, `lzo`, `zstd`). You can apply compression to existing files using the `btrfs filesystem defragment` command. Enable deduplication: Implement deduplication to identify and merge blocks of data with common sequences using copy-on-write semantics. You can use third-party tools dedicated to Btrfs deduplication, such as duperemove, bees, and dduper. However, research their stability and reliability before employing them. Perform a balance: If the data and metadata are unevenly allocated among disks, especially in Btrfs filesystems with multiple disks, you can perform a balance operation to reallocate space between data and metadata. Use the `btrfs balance` command with appropriate usage parameters to start the balance process.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_networkpolicy.KubeNetworkPolicy.md

title: "Interface: KubeNetworkPolicy" linkTitle: "KubeNetworkPolicy" slug: "libk8snetworkpolicy.KubeNetworkPolicy" .KubeNetworkPolicy `KubeNetworkPolicy` `Optional` apiVersion: `string` . _ egress: [] _ ingress: [] _ kind: `string` Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. In CamelCase. Cannot be updated. `see` . _ metadata: . _ podSelector: _ policyTypes: `string`[]
Project: Netdata (Observability and Analysis / Observability)
File: 1hour_ecc_memory_uncorrectable.md

This alert, `1houreccmemory_uncorrectable`, indicates that there are ECC (Error-Correcting Code) uncorrectable errors detected in your system's memory within the last hour. ECC errors are caused by issues in the system's RAM (Random Access Memory). These uncorrectable errors are severe and may lead to system crashes or data corruption. ECC memory is designed to detect and, in some cases, correct data corruption in the memory, preventing system crashes and providing overall system stability. ECC errors fall into two categories: Correctable Errors: These are errors that the ECC memory can detect and correct, preventing system crashes and ensuring data integrity. Uncorrectable Errors: These are more severe errors that the ECC memory cannot correct, often requiring faulty memory modules to be replaced to prevent system crashes and data corruption. Inspect the memory modules: Power off the system and check the memory modules for any signs of damage or poor contact with the socket. Ensure that the memory modules are seated firmly and there is proper contact. Run memory diagnostics: Run memory diagnostic tools, like to identify any memory errors and verify the memory's health. If errors are detected, it's an indication that the memory modules need to be replaced. Replace faulty memory modules: If uncorrectable errors continue occurring or if diagnostics identify faulty memory modules, consider replacing them. Before doing so, check if the memory modules are still covered under warranty. Check system logs: Review system logs, such as Event Viewer on Windows or `/var/log` on Linux systems, for any related messages or errors that may help to diagnose the issue further. Update firmware: Ensure your system's firmware and BIOS are up-to-date. Manufacturers often release stability and performance improvements that can potentially resolve or mitigate ECC errors.
Project: SkyWalking (Observability and Analysis / Observability)
File: log-agent-native.md

Some of SkyWalking native agents support collecting logs and sending them to OAP server without local files and/or file agents, which are listed in . Java agent provides toolkits for , , and to report logs through gRPC with automatically injected trace context. is a recommended proxy/side that forwards logs (including the use of Kafka MQ to transport logs). When using this, open and enable configs `enableNativeProtoLog`. Java agent provides toolkits for , , and to report logs through files with automatically injected trace context. Log framework config examples: implements a log reporter for the [logging module](https://docs.python.org/3/library/logging.html) with functionalities aligning with the Java toolkits. To explore how to enable the reporting features for your use cases, please refer to the for a detailed guide.
Project: Tracetest (Observability and Analysis / Observability)
File: tracetest_server.md

Manage your tracetest server Manage your tracetest server ``` tracetest server [flags] ``` ``` -h, --help help for server ``` ``` -c, --config string config file will be used by the CLI (default "config.yml") -o, --output string output format [pretty|json|yaml] -s, --server-url string server url -v, --verbose display debug information ``` - CLI to configure, install and execute tests on a Tracetest server - Install a new Tracetest server
Project: Netdata (Observability and Analysis / Observability)
File: postgres_table_bloat_size_perc.md

The `postgrestablebloatsizeperc` alert measures the bloat size percentage in a PostgreSQL database table. If you receive this alert, it means that the bloat size in a particular table in your PostgreSQL database has crossed the warning or critical threshold. In PostgreSQL, bloat size refers to the wasted storage space caused by dead rows and unused space that accumulates in database tables over time. It is a result of frequent database operations (inserts, updates, and deletes), impacting database performance and storage footprint. Investigate the bloat size and impacted table To get a detailed report on bloated tables in your PostgreSQL database, use the extension. First, install the extension if it isn't already installed: ``` CREATE EXTENSION pgstattuple; ``` Then, run the following query to find the bloated tables: ```sql SELECT schemaname, tablename, pgsizepretty(bloatsize) AS bloatsize, round(bloatratio::numeric, 2) AS bloatratio FROM ( SELECT schemaname, tablename, bloatsize, tablesize, (bloatsize / tablesize) * 100 as bloat_ratio FROM pgstattuple.schema_bloat ) sub_query WHERE bloat_ratio > 10 ORDER BY bloat_ratio DESC; ``` Reclaim storage space Reducing the bloat size in PostgreSQL tables involves reclaiming wasted storage space. Here are two approaches: VACUUM: The `VACUUM` command helps clean up dead rows and compact the space used by the table. Use the following command to clean up the impacted table: ``` VACUUM VERBOSE ANALYZE <schemaname>.<tablename>; ``` REINDEX: If the issue persists after using `VACUUM`, consider REINDEXing the table. This command rebuilds the table's indexes, which can improve query performance and reduce bloat. It can be more intrusive than `VACUUM`, be sure you understand its implications before running: ``` REINDEX TABLE <schemaname>.<tablename>; ``` Monitor the bloat size Continue monitoring the bloat size in your PostgreSQL tables by regularly checking the `postgrestablebloatsizeperc` alert on Netdata.
Project: HertzBeat (Observability and Analysis / Observability)
File: alert_feishu.md

id: alert_feishu title: Alert FeiShu robot notification sidebar_label: Alert FeiShu robot notification keywords: [open source monitoring tool, open source alerter, open source feishu bot notification] After the threshold is triggered send alarm information and notify the recipient by FeiShu robot. FeiShu client-> Group settings-> Group robot-> Add new robot-> Set robot name and avatar-> Copy its webhook address after adding successfully Save the key value of the WebHook address of the robot eg webHook address`https://open.feishu.cn/open-apis/bot/v2/hook/3adafc96-23d0-4cd5-8feb-17f6e0b5fcs4` Its robot KEY value is `3adafc96-23d0-4cd5-8feb-17f6e0b5fcs4` Alarm notification->Add new recipient ->Select FeiShu robot notification method->Set FeiShu robot KEY-> Confirm Configure the associated alarm notification strategy Add new notification strategy-> Associate the recipient just set-> Confirm Note Adding a new recipient does not mean that it is effective to receive alarm information. It is also necessary to configure the associated alarm notification strategy, that is, to specify which messages are sent to which recipients. FeiShu group did not receive the robot alarm notification. Please check whether there is any triggered alarm information in the alarm center. Please check whether the robot key is configured correctly and whether the alarm strategy association is configured. Other issues can be fed back through the communication group ISSUE!
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_resourceQuota.ResourceQuota.md

title: "Class: ResourceQuota" linkTitle: "ResourceQuota" slug: "libk8sresourceQuota.ResourceQuota" .ResourceQuota `any` `ResourceQuota` new ResourceQuota(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeResourceQuota\>('resourceQuota').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<KubeResourceQuota\>('resourceQuota').className `get` limits(): `string`[] `string`[] _ `get` requests(): `string`[] `string`[] _ `get` resourceStats(): { `hard`: `string` ; `name`: `string` ; `used`: `string` }[] { `hard`: `string` ; `name`: `string` ; `used`: `string` }[] _ `get` spec(): `spec` `spec` _ `get` status(): `status` `status` `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeResourceQuota\>('resourceQuota').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeResourceQuota\>('resourceQuota').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeResourceQuota\>('resourceQuota').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeResourceQuota\>('resourceQuota').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeResourceQuota\>('resourceQuota').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeResourceQuota\>('resourceQuota').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeResourceQuota\>('resourceQuota').useList