cwielenb/CNCF-Dataset huggingface dataset:
Project: Cortex (Observability and Analysis / Observability)
File: requests-mirroring-to-secondary-cluster.md

title: "Requests mirroring to secondary cluster" linkTitle: "Requests mirroring to secondary cluster" weight: 4 slug: requests-mirroring-to-secondary-cluster Requests mirroring (or shadowing) is a technique you can use to mirror requests from a primary Cortex cluster to a secondary one. For example, requests mirroring can be used when you need to setup a testing Cortex cluster receiving the same series ingested by a primary one without having control over Prometheus remote write config (if you do, then configuring two remote write entries in Prometheus would be the preferred option). can be used to mirror HTTP requests to a secondary upstream cluster. From a network path perspective, you should run Envoy in front of both clusters distributors, letting Envoy to proxy requests to the primary Cortex cluster and mirror them to a secondary cluster in background. The performances and availability of the secondary cluster have no impact on the requests to the primary one. The response to the client will always be the one from the primary one. In this sense, the requests from Envoy to the secondary cluster are "fire and forget". The following Envoy configuration shows an example with two Cortex clusters. Envoy will listen on port `9900` and will proxies all requests to `cortex-primary:80`, mirroring it to `cortex-secondary:80` too. ```yaml admin: accesslogpath: /dev/null address: socketaddress: { address: 0.0.0.0, portvalue: 9901 } static_resources: listeners: name: cortex_listener address: socketaddress: { address: 0.0.0.0, portvalue: 9900 } filter_chains: filters: name: envoy.httpconnectionmanager config: statprefix: cortexingress route_config: name: all_routes virtual_hosts: name: all_hosts domains: ["*"] routes: match: { prefix: "/" } route: cluster: cortex_primary timeout: 15s requestmirrorpolicies: cluster: cortex_secondary http_filters: name: envoy.router clusters: name: cortex_primary type: STRICT_DNS connect_timeout: 1s hosts: [{ socketaddress: { address: cortex-primary, portvalue: 80 }}] dnsrefreshrate: 5s name: cortex_secondary type: STRICT_DNS connect_timeout: 1s hosts: [{ socketaddress: { address: cortex-secondary, portvalue: 80 }}] dnsrefreshrate: 5s ```
Project: Beats (Observability and Analysis / Observability)
File: bug-report.md

name: Bug about: "Report confirmed bugs. For unconfirmed bugs please visit https://discuss.elastic.co/c/beats" Please post all questions and issues on https://discuss.elastic.co/c/beats before opening a Github Issue. Your questions will reach a wider audience there, and if we confirm that there is a bug, then you can open a new issue. For security vulnerabilities please only send reports to security@elastic.co. See https://www.elastic.co/community/security for more information. Please include configurations and logs if available. For confirmed bugs, please report: Version: Operating System: Discuss Forum URL: Steps to Reproduce:
Project: Checkmk (Observability and Analysis / Observability)
File: 16274.md

key | value | compatible | no version | 2.3.0b1 date | 2023-12-15T10:35:33+00:00 level | 1 class | fix component | checks edition | cre This fixes some unusable services of the "HPE Proliant Servers: Raid Status" plugin. This werk only affects you if you observe unknown "Logical device &lt;ITEM&gt;" services after the upgrade. In case you are affected please run a discovery on the affected hosts and fix the monitoring history as described below. We observed some devices to send `"\x00"` (the null-byte) as their name (`OID .1.3.6.1.4.1.232.3.2.3.1.1.14`). Not all components delt well with it, leading to unacknowlegable downtimes, non matching rules and the like. We now replace all null-bytes with `"\\x00"` (the literal containing the four characters backslash, 'x', 'zero', 'zero'). As of Checkmk 2.3, this should in fact no longer be necessary, but as we need a backportable solution, we change the item consistently in all versions. If this affects you, you might also want to fix the services in the monitoring history by running ``` sed -i 's|\\x00|\\\\x00|' var/checkmk/core/history var/checkmk/core/archive/* ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16314.md

key | value | compatible | yes version | 2.3.0b1 date | 2024-01-24T14:06:42+00:00 level | 1 class | fix component | multisite edition | cre If you edited the builtin dashlets "Host statistics" or "Service statistics" on the main dashboard (CRE) / problem dashboard (CEE) you got an error like "Internal error: size" on saving.
Project: Checkmk (Observability and Analysis / Observability)
File: 16085.md

key | value | date | 2024-02-21T10:36:36+00:00 version | 2.4.0b1 class | fix edition | cee component | agents level | 1 compatible | yes Previously, the agent updater used to detect the underlying platform, in terms of the combination of OS and package manager (e.g., Linux + RPM), automatically by scanning for certrain directories. As multiple package managers may be available on one system, this sometimes lead to unexpected behavior on agent updates when the update mechanism decided to switch to a different platform. Now, the platform will be specified by a file that comes with the agent installation, and the agent updater will rely on this static information instead of the dynamic detection.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: markblocks.md

`markblocks` is a tool that creates and uploads block markers to a specified backend. Marks are uploaded to both block folder and the global marks folder for the provided tenant. See `markblocks -help` for flags usage, and `markblocks -help-all` for full backend configuration flags list. This tool can create two types of marks, depending on the `-mark` flag provided: When `-mark deletion` is provided, this tool uploads a `DeletionMark` which tells the compactor that the block provided should be deleted. This is a destructive operation (although it won't happen immediately, the default delation delay is 12h, see `-compactor.deletion-delay` value), proceed with caution. ``` $ mkdir -p tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2R tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2U $ touch tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2R/meta.json $ tree -f tenant-1 tenant-1 tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2R tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2R/meta.json tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2U 2 directories, 1 file $ go run ./tools/markblocks -mark deletion -tenant tenant-1 -details "Corrupted blocks" 01FSCTA0A4M1YQHZQ4B2VTGS2R 01FSCTA0A4M1YQHZQ4B2VTGS2U level=info time=2022-03-30T08:50:41.277334365Z msg="Successfully uploaded mark." block=01FSCTA0A4M1YQHZQ4B2VTGS2R level=info time=2022-03-30T08:50:41.277359767Z msg="Block does not exist, skipping." block=01FSCTA0A4M1YQHZQ4B2VTGS7Z $ tree -f tenant-1 tenant-1 tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2R tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2R/deletion-mark.json tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2R/meta.json tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2U tenant-1/markers tenant-1/markers/01FSCTA0A4M1YQHZQ4B2VTGS2R-deletion-mark.json 3 directories, 3 files ``` When `-mark no-compact` is provided, this tool uploads a `NoCompactMark` which tells the compactor that the marked blocks should not be compacted. `-details` flag can be used to provide an explanation of why the block is marked as such (who marked it? issue link?). ``` $ mkdir -p tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2R tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2U $ touch tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2R/meta.json $ tree -f tenant-1 tenant-1 tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2R tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2R/meta.json ten ant-1/01FSCTA0A4M1YQHZQ4B2VTGS2U 2 directories, 1 file $ go run ./tools/markblocks -mark no-compact -tenant tenant-1 -details "Blocks with out of order chunks" 01FSCTA0A4M1YQHZQ4B2VTGS2R 01FSCTA0A4M1YQHZQ4B2VTGS2U level=info time=2022-03-30T08:53:13.012462019Z msg="Successfully uploaded mark." block=01FSCTA0A4M1YQHZQ4B2VTGS2R level=info time=2022-03-30T08:53:13.012492902Z msg="Block does not exist, skipping." block=01FSCTA0A4M1YQHZQ4B2VTGS7Z $ tree -f tenant-1 tenant-1 tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2R tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2R/meta.json tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2R/no-compact-mark.json tenant-1/01FSCTA0A4M1YQHZQ4B2VTGS2U tenant-1/markers tenant-1/markers/01FSCTA0A4M1YQHZQ4B2VTGS2R-no-compact-mark.json 3 directories, 3 files ```
Project: Pixie (Observability and Analysis / Observability)
File: index.md

Code is automatically formatted using linters and checked during CI builds. Static checkers also validate other coding style requirements for our most commonly used languages (C++, Go, Typescript, Python, Shell). We expect all production code to be written in either C++ or Go, with the UI written in Typescript. C++ code uses , with some deviations. Refer to . Go style is automatically enforced by linters. Refer to . Typescript code uses , with some deviations. Refer to . Pixie uses inclusive naming in our source code and all our assets. Refer to .
Project: SkyWalking (Observability and Analysis / Observability)
File: virtual-database.md

Virtual databases represent the database nodes detected by . The performance metrics of the databases are also from the Database client-side perspective. For example, JDBC plugins(MySQL, PostgreSQL, MariaDB, MSSQL) in the Java agent could detect the latency of SQL performance and SQL statements. As a result, SkyWalking would show database traffic, latency, success rate, and sampled slow SQLs powered by backend analysis capabilities in this dashboard. The Database access span should have It is an Exit span Span's layer == DATABASE Tag key = `db.statement`, value = SQL statement Tag key = `db.type`, value = the type of Database Span's peer is the network address(IP or domain) of Database server. Ref to know more slow SQL settings.
Project: Graylog (Observability and Analysis / Observability)
File: common-functionality.md

If you want to add a keyboard shortcut, you need to: extend the `hotkeysCollections` in the `hotkeysProvider`. call `useHotkey` hook in the place which provides the functionality you want to execute on keypress. When receiving or sending dates to the backend they are always in UTC and expressed according to ISO 8601, for example `2010-07-30T16:03:25.000Z`. This is also the preferred format to store date times in the state of, for example, UI components. When displaying date times in the UI they are always displayed in the user timezone. The contains the related functionality and provides further information. It can be access using the hook. If you just want to display a date time, you can render the component, which implements methods provided by the `useUserDateTime` hook. If you want to display the relative time in a human-readable format you can render the component. For all other cases where you need to transform a date time you can use the utils. Instead of using `moment` directly, use or (if necessary) extend the `DateTime` utils. It makes it easier to replace moment with an alternative.
Project: Netdata (Observability and Analysis / Observability)
File: rocketchat.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/integrations/rocketchat.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/metadata.yaml" sidebar_label: "RocketChat" learn_status: "Published" learnrelpath: "Alerts & Notifications/Notifications/Centralized Cloud Notifications" message: "DO NOT EDIT THIS FILE DIRECTLY, IT IS GENERATED BY THE NOTIFICATION'S metadata.yaml FILE" endmeta--> <img src="https://netdata.cloud/img/rocketchat.png" width="150"/> From the Netdata Cloud UI, you can manage your space's notification settings and enable the configuration to deliver notifications on RocketChat. <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> A Netdata Cloud account Access to the Netdata Space as an Admin The Netdata Space needs to be on a paid plan You need to have permissions on Mattermost to add new integrations. You need to have a RocketChat app on your workspace to receive the webhooks. Steps to configure your RocketChat to receive notifications from Netdata: In RocketChat, Navigate to Administration > Workspace > Integrations. Click +New at the top right corner. For more details about each parameter, check . After configuring integration, click Save. You will end up with a webhook endpoint that looks like below: `https://your-server.rocket.chat/hooks/YYYYYYYYYYYYYYYYYYYYYYYY/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX` Treat this endpoint as a secret. Anyone who has it will be able to post messages to your RocketChat instance. For more details please check RocketChat's article Incoming webhooks for . Click on the Space settings cog (located above your profile icon) Click on the Notification tab Click on the + Add configuration button (near the top-right corner of your screen) On the RocketChat card click on + Add A modal will be presented to you to enter the required details to enable the configuration: Notification settings* are Netdata specific settings Configuration name - you can optionally provide a name for your configuration you can easily refer to it Rooms - by specifying a list of Rooms you are select to which nodes or areas of your infrastructure you want to be notified using this configuration Notification - you specify which notifications you want to be notified using this configuration: All Alerts and unreachable, All Alerts, Critical only Integration configuration* are the specific notification integration required settings, which vary by notification method. For RocketChat: Webhook URL - URL provided on RocketChat for the channel you want to receive your notifications.
Project: Netdata (Observability and Analysis / Observability)
File: mysql_galera_cluster_state_crit.md

The `mysqlgaleraclusterstatecrit` alert is triggered when the Galera node state is either `Undefined`, `Joining`, or `Error`. This indicates that there is an issue with a Galera node in your MySQL Galera Cluster. MySQL Galera Cluster is a synchronous, multi-master database cluster that provides high availability, no data loss, and scalability for your MySQL databases. It uses Galera replication library and MySQL server to achieve these goals. To troubleshoot the MySQL Galera Cluster State Critical alert, follow these steps: Inspect the MariaDB error log Check the MariaDB error log for any relevant error messages that can help identify the issue. ``` sudo tail -f /var/log/mysql/error.log ``` Check the Galera node's status Connect to the problematic MySQL node and check the Galera node status by running the following query: ``` SHOW STATUS LIKE 'wsrep_%'; ``` Take note of the value of `wsreplocalstate` and `wsreplocalstate_comment`. Diagnose the issue If `wsreplocalstate` is 0 (`Undefined`), it means the node is not part of any cluster. If `wsreplocalstate` is 1 (`Joining`), it means the node is trying to connect or reconnect to the cluster. If `wsreplocalstate` is 5 (`Error`), it means the node has encountered a consistency error. Resolve the issue For an `Undefined` state, check and fix the wsrep configuration settings and restart the node. For a `Joining` state, ensure that the node can communicate with the other nodes in the cluster and make sure that the cluster's state is healthy. Then, retry joining the node to the cluster. For an `Error` state, the node may need to be resynchronized with the cluster. Restart the mysqld process on the affected node, or you may need to perform a full state transfer to recover. Monitor the cluster After resolving the issue, monitor the cluster to ensure that all nodes are healthy and remain in-sync.
Project: Vector (Observability and Analysis / Observability)
File: topologies.md

title: Deployment topologies short: Topologies weight: 2 show_toc: true aliases: ["/setup/deployment/pipelines"] In the previous section we covered the various used to collect and forward data. You combine these strategies to form topologies. This section showcases common topologies and the pros and cons of each. Use these as guidelines to build your own. {{< topologies >}}
Project: Grafana Mimir (Observability and Analysis / Observability)
File: configure-metrics-storage-retention.md

aliases: ../operators-guide/configure/configure-metrics-storage-retention/ description: Learn how to configure Grafana Mimir metrics storage retention. menuTitle: Metrics storage retention title: Configure Grafana Mimir metrics storage retention weight: 70 Grafana Mimir stores metrics in object storage. By default, metrics that are stored in the object storage are never deleted, and the storage utilization will increase over time. You can configure the object storage retention to automatically delete all metrics data older than the configured period. The is the Mimir component that is responsible for enforcing the storage retention. To configure the storage retention, set the CLI flag `-compactor.blocks-retention-period` or change the following YAML configuration: ```yaml limits: compactorblocksretention_period: 1y ``` To configure the storage retention on a per-tenant basis, set overrides in the : ```yaml overrides: tenant1: compactorblocksretention_period: 1y tenant2: compactorblocksretention_period: 2y tenant3: compactorblocksretention_period: 0 ``` Grafana Mimir doesnt support per-series deletion and retention, nor does it support Prometheus' .
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: engine-state.md

It is a user-defined flag to trigger chaos. Setting it to `active` ensures the successful execution of chaos. Patching it with `stop` aborts ongoing experiments. It has a corresponding flag in the chaosengine status field, called `engineStatus` which is updated by the controller based on the actual state of the ChaosEngine. It can be tuned via `engineState` field. It supports `active` and `stop` values. ??? info "View the state specification schema" <table> <tr> <th>Field</th> <td><code>.spec.engineState</code></td> </tr> <tr> <th>Description</th> <td>Flag to control the state of the chaosengine</td> </tr> <tr> <th>Type</th> <td>Mandatory</td> </tr> <tr> <th>Range</th> <td><code>active</code>, <code>stop</code></td> </tr> <tr> <th>Default</th> <td><code>active</code></td> </tr> <tr> <th>Notes</th> <td>The <code>engineState</code> in the spec is a user defined flag to trigger chaos. Setting it to <code>active</code> ensures successful execution of chaos. Patching it with <code>stop</code> aborts ongoing experiments. It has a corresponding flag in the chaosengine status field, called <code>engineStatus</code> which is updated by the controller based on actual state of the ChaosEngine.</td> </tr> </table> Use the following example to tune this: ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: "active" annotationCheck: "false" appinfo: appns: "default" applabel: "app=nginx" appkind: "deployment" chaosServiceAccount: pod-delete-sa experiments: name: pod-delete ```
Project: HertzBeat (Observability and Analysis / Observability)
File: centos.md

id: centos title: CentOS operating system monitoring sidebar_label: CentOS operating system keywords: [open source monitoring tool, open source os monitoring tool, monitoring CentOS operating system metrics] Collect and monitor the general performance Metrics of CentOS 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: Netdata (Observability and Analysis / Observability)
File: power_supply.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/integrations/power_supply.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/metadata.yaml" sidebar_label: "Power Supply" learn_status: "Published" learnrelpath: "Collecting Metrics/Linux Systems/Power Supply" 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/powersupply.svg" width="150"/> Plugin: proc.plugin Module: /sys/class/power_supply <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> This integration monitors Power supply metrics, such as battery status, AC power status and more. 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 | |:--|:-| | device | TBD | Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | powersupply.capacity | capacity | percentage | | powersupply.power | power | W | | powersupply.charge | emptydesign, empty, now, full, fulldesign | Ah | | powersupply.energy | emptydesign, empty, now, full, fulldesign | Wh | | powersupply.voltage | mindesign, min, now, max, maxdesign | V | The following alerts are available: | Alert name | On metric | Description | |:|:-|:| | | powersupply.capacity | percentage of remaining power supply capacity | No action required. There is no configuration file. There are no configuration options. There are no configuration examples.