cwielenb/CNCF-Dataset huggingface dataset:
Project: Vector (Observability and Analysis / Observability)
File: concurrency-model.md

title: Concurrency model weight: 2 tags: ["concurrency", "pipeline", "state"] {{< svg "img/concurrency-model.svg" >}} Vector implements a concurrency model that scales naturally with incoming data volume as shown above. Each Vector is responsible for defining the unit of concurrency and implementing it accordingly. This allows for a natural concurrency model that adapts to however Vector is being used, avoiding the need for tedious concurrency tuning and configuration. For example, the implements concurrency across the number of files it's tailing, and the [`socket` source][socket] implements concurrency across the number active open connection it's maintaining. As covered in the documentation, Vector's concurrency relies on stateless function transforms that can be parallelized. Task transforms cannot be parallelized, currently, and so can introduce bottlenecks in processing (we hope to improve this ).
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_registry.PluginLoadingErrorEvent.md

title: "Interface: PluginLoadingErrorEvent" linkTitle: "PluginLoadingErrorEvent" slug: "plugin_registry.PluginLoadingErrorEvent" .PluginLoadingErrorEvent Event fired when there is an error while loading a plugin. data: `Object` | Name | Type | Description | | : | : | : | | `error` | `Error` | The error that occurred while loading the plugin. | | `pluginInfo` | { `name`: `string` ; `version`: `string` } | Information about the plugin. | | `pluginInfo.name` | `string` | The name of the plugin. | | `pluginInfo.version` | `string` | The version of the plugin. | _ type: `PLUGINLOADINGERROR`
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: sqs.md

sidebar_position: 6 The SQS exporter will collect the data and create an event in the queue for each evaluation we receive. ```go ffclient.Config{ // ... cfg, _ := config.LoadDefaultConfig(context.TODO()) DataExporter: ffclient.DataExporter{ // ... Exporter: &sqsexporter.Exporter{ QueueURL: "https://sqs.eu-west-1.amazonaws.com/XXX/test-queue", AwsConfig: &cfg, }, }, // ... } ``` | Field | Description | ||-| | `QueueURL ` | URL of your SQS queue.<br/>You can find it in your AWS console. | | `AwsConfig ` | An instance of `aws.Config` that configures your access to AWS (see ). | Check the .
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-nodata_list.md

category: NoData apiurl: '/api/v1/nodata' title: "Nodata List" type: 'GET' sample_doc: 'nodata.html' layout: default Required ```Status: 200``` ```[ { "id": 2, "name": "owl_nodate", "obj": "docker-agent", "obj_type": "host", "metric": "test.metric", "tags": "", "dstype": "GAUGE", "step": 60, "mock": -2, "creator": "root" } ]```
Project: Netdata (Observability and Analysis / Observability)
File: vcsa_software_updates_health.md

The `vcsasoftwareupdates_health` alert monitors the software updates availability status for a VMware vCenter Server Appliance (VCSA). The alert can have different statuses depending on the software updates state, with critical indicating that security updates are available. Follow these troubleshooting steps according to the alert status: Critical (security updates available): Access the vCenter Server Appliance Management Interface (VAMI) by browsing to `https://<vcsa-address>:5480`. Log in with the appropriate user credentials (typically `root` user). Click on the `Update` menu item. Review the available patches and updates, especially those related to security. Click `Stage and Install` to download and install the security updates. Monitor the progress of the update installation and, if needed, address any issues that might occur during the process. Warning (error retrieving information on software updates): Access the vCenter Server Appliance Management Interface (VAMI) by browsing to `https://<vcsa-address>:5480`. Log in with the appropriate user credentials (typically `root` user). Click on the `Update` menu item. Check for any error messages in the `Update` section. Ensure that the VCSA has access to the internet and can reach the VMware update repositories. Verify that there are no issues with the system time or SSL certificates. If the issue persists, consider searching for relevant information in the VMware Knowledge Base or contacting VMware Support. Clear (no updates available, non-security updates available, or unknown status): No immediate action is required. However, it's a good practice to periodically check for updates to ensure the VMware vCenter Server Appliance remains up-to-date and secure.
Project: Grafana (Observability and Analysis / Observability)
File: back-up-grafana.md

headless: true labels: products: enterprise oss title: Back up Grafana This topic explains how to back up a local Grafana deployment, including configuration, plugin data, and the Grafana database. Copy Grafana configuration files that you might have modified in your Grafana deployment to a backup directory. The Grafana configuration files are located in the following directories: Default configuration: `$WORKING_DIR/defaults.ini` (Don't change this file) Custom configuration: `$WORKING_DIR/custom.ini` For more information on where to find configuration files, refer to . {{% admonition type="note" %}} If you installed Grafana using the `deb` or `rpm` packages, then your configuration file is located at `/etc/grafana/grafana.ini`. This path is specified in the Grafana `init.d` script using `--config` file parameter. {{% /admonition %}} Installing plugins in Grafana creates a folder for each plugin with its associated files and data. Copy all files and folders recursively from this location to your backup repository. The Grafana plugin files are located in the following directories: Default location for plugins in a binary or source installation: `$WORKING_DIR/data/plugins` Default location for plugins in a `deb` or `rpm` package: `/var/lib/grafana/plugins`. This path is specified in the Grafana init.d script using `--config` file parameter. We recommend that you back up your Grafana database so that you can roll back to a previous version, if required. The default Grafana database is SQLite, which stores its data in a single file on disk. To back up this file, copy it to your backup repository. {{% admonition type="note" %}} To ensure data integrity, shut down your Grafana service before backing up the SQLite database. {{% /admonition %}} The SQLite database file is located in one of the following directories: Default location for SQLite data in a binary or source installation: `$WORKING_DIR/data/grafana.db` Default location for SQLite data in a `deb` or `rpm` package: `/var/lib/grafana/grafana.db`. This path is specified in the Grafana init.d script using `--config` file parameter. To back up or restore a MySQL Grafana database, run the following commands: ```bash backup: mysqldump -u root -p[rootpassword] [grafana] > grafanabackup.sql restore: mysql -u root -p grafana < grafana_backup.sql ``` To back up or restore a Postgres Grafana database, run the following commands: ```bash backup: pgdump grafana > grafanabackup restore: psql grafana < grafana_backup ```
Project: Grafana Mimir (Observability and Analysis / Observability)
File: authentication-and-authorization.md

aliases: ../../operators-guide/securing/authentication-and-authorization/ ../../operators-guide/secure/authentication-and-authorization/ description: Learn how to configure and run Grafana Mimir with multi-tenancy. menuTitle: Authentication and authorization title: Grafana Mimir authentication and authorization weight: 20 Grafana Mimir is a multi-tenant system where tenants can query metrics and alerts that include their tenant ID. The query takes the tenant ID from the `X-Scope-OrgID` parameter that exists in the HTTP header of each request, for example `X-Scope-OrgID: <TENANT-ID>`. You can federate queries across multiple tenants by using `true` in `-tenant-federation.enabled=true`. When you specify tenant IDs, separate them with a pipe (`|`) character in the `X-Scope-OrgID` header, as in the example `X-Scope-OrgID: tenant-1|tenant-2|tenant-3`. To protect Grafana Mimir from accidental or malicious calls, you must add a layer of protection such as a reverse proxy that authenticates requests and injects the appropriate tenant ID into the `X-Scope-OrgID` header. For more information about Prometheus remote write configuration, refer to . To use bearer authentication with a token stored in a file, the remote write configuration block includes the following parameters: ```yaml authorization: type: Bearer credentials_file: <PATH TO BEARER TOKEN FILE> ``` To use basic authentication with a username and password stored in a file, the remote write configuration block includes the following parameters: ```yaml basic_auth: username: <AUTHENTICATION PROXY USERNAME> password_file: <PATH TO AUTHENTICATION PROXY PASSWORD FILE> ``` To configure the `X-Scope-OrgID` header directly, the remote write configuration block includes the following parameters: ```yaml headers: "X-Scope-OrgID": <TENANT ID> ``` In trusted environments where you want to split series on Prometheus labels, you can run between a Prometheus server and Grafana Mimir. {{< admonition type="note" >}} cortex-tenant is a third-party community project that's not maintained by Grafana Labs. {{< /admonition >}} When proxying the timeseries to Grafana Mimir, you can configure cortex-tenant to use specified labels as the `X-Scope-OrgID` header. To configure cortex-tenant, refer to . To disable multi-tenant functionality, pass the following argument to every Grafana Mimir component: `-auth.multitenancy-enabled=false` After you disable multi-tenancy, Grafana Mimir components internally set the tenant ID to the string `anonymous` for every request. To set an alternative tenant ID, use the `-auth.no-auth-tenant` flag. {{< admonition type="note" >}} Not all tenant IDs are valid. For more information about tenant ID restrictions, refer to . {{< /admonition >}}
Project: Elastic APM (Observability and Analysis / Observability)
File: test-plan.md

name: Test Plan about: Create a new manual test plan meta issue labels: "test-plan" When picking up a test case, please add your name to this overview beforehand and tick the checkbox when finished. Testing can be started when the first build candidate (BC) is available in the CFT region. Thanks to https://github.com/elastic/apm-server/issues/8303 further smoke tests are run automatically on ESS now. Consider extending the smoke tests to include more test cases which we'd like to cover <!-- Add any issues / PRs which were worked on during the milestone release https://github.com/elastic/go-docappender/pulls--> <!-- Add any issues / PRs which were worked on during the milestone release https://github.com/elastic/apm-data/pulls--> <!-- Replace MAJOR.MINOR with the appropriate versions below --> <!-- Label the relevant MAJOR.MINOR Issues / PRs with the `test-plan` label https://github.com/elastic/apm-server/issues?page=1&q=-label%3Atest-plan+label%3AvMAJOR.MINOR.0+-label%3Atest-plan-ok--> <!-- --> Add yourself as assignee on the PR before you start testing. <!-- Link any regressions to this issue. -->
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: setup.md

sort: 2 weight: 2 title: Setup menu: docs: parent: "operator" weight: 2 aliases: /operator/setup.html You can use one of the following official helm-charts with `vmoperator`: (includes the `victoria-metrics-operator` helm-chart and other components for full-fledged k8s monitoring, is an alternative for ). For installing VictoriaMetrics operator with helm-chart follow the instructions from README of the corresponding helm-chart ( or ). in addition, you can use for installing VictoriaMetrics operator with helm-chart. Obtain release from releases page: We suggest use the latest release. ```sh export VMVERSION=`basename $(curl -fs -o/dev/null -w %{redirecturl} https://github.com/VictoriaMetrics/operator/releases/latest)` wget https://github.com/VictoriaMetrics/operator/releases/download/$VMVERSION/bundlecrd.zip unzip bundle_crd.zip ``` Operator use `monitoring-system` namespace, but you can install it to specific namespace with command: ```sh sed -i "s/namespace: monitoring-system/namespace: YOUR_NAMESPACE/g" release/operator/* ``` First of all, you have to create : ```sh kubectl apply -f release/crds ``` Then you need RBAC for operator, relevant configuration for the release can be found at `release/operator/rbac.yaml`. Change configuration for operator at `release/operator/manager.yaml`, possible settings: and apply it: ```sh kubectl apply -f release/operator/ ``` Check the status of operator ```sh kubectl get pods -n monitoring-system ``` You can install operator using by pointing to the remote kustomization file. ```sh export VMVERSION=`basename $(curl -fs -o/dev/null -w %{redirecturl} https://github.com/VictoriaMetrics/operator/releases/latest)` cat << EOF > kustomization.yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: github.com/VictoriaMetrics/operator/config/default?ref=${VM_VERSION} images: name: victoriametrics/operator newTag: ${VM_VERSION} EOF ``` You can change , or use your custom namespace see . Build template ```sh kustomize build . -o monitoring.yaml ``` Apply manifests ```sh kubectl apply -f monitoring.yaml ``` Check the status of operator ```sh kubectl get pods -n monitoring-system ``` There is no need in an additional configuration for ARM. Operator and VictoriaMetrics have full support for it. You can read detailed instructions about operator configuring in .
Project: Netis (Observability and Analysis / Observability)
File: CHANGES.md

The list of the most significant changes made in Netis Packet Agent over time. Support agent control plane for agent daemon over zeromq. Support option check for '--nofilter' option invalid usage. In version 0.3.5 or later, pktminerg will exit directly in the following cases: if you enable '--nofilter' option without specifying gre bind device(-B) in online mode. if you enable '--nofilter' option and gre bind device(-B) is same as packet captured interface(-i) in online mode. Support MTU discovery strategy. Support send GRE packets to multi-remoteip Support send GRE packets from binded device (network interface). Support systemd Add Windows support Remove rpm install boost library dependencies. Initial release. Capture packets from an NIC interface, encapsulate them with GRE and send them to a remote machine for monitoring and analysis. All with ease. For first use: , , , , , . Package for Linux installs EM64T bits. Linux installer allows root, RPM installs.
Project: Grafana (Observability and Analysis / Observability)
File: query-profile-data.md

description: Use the query editor to explore your Pyroscope data. keywords: query profiling pyroscope labels: products: cloud enterprise oss title: Query profile data menuTitle: Query profile data weight: 300 The Pyroscope data source query editor gives you access to a profile type selector, a label selector, and collapsible options. To access the query editor: Sign into Grafana or Grafana Cloud. Select your Pyroscope data source. From the menu, choose Explore. Select a profile type from the drop-down menu. {{< figure src="/media/docs/pyroscope/query-editor/select-profile.png" class="docs-image--no-shadow" max-width="450px" caption="Profile selector" >}} Use the labels selector input to filter by labels. Pyroscope uses similar syntax to Prometheus to filter labels. Refer to for available operators and syntax. While the label selector can be left empty to query all profiles without filtering by labels, the profile type or app must be selected for the query to be valid. Grafana doesn't show any data if the profile type or app isnt selected when a query runs. Expand the Options section to view Query Type and Group by. Select a query type to return the profile data. Data is shown in the , metric data visualized in a graph, or both. You can only select both options in Explore. The panels used on dashboards allow only one visualization. Using Group by, you can group metric data by a specified label. Without any Group by label, metric data aggregates over all the labels into single time series. You can use multiple labels to group by. Group by only effects the metric data and doesn't change the profile data results. Profiles can be visualized in a flame graph. Refer to the to learn about the visualization and its features. Pyroscope returns profiles aggregated over a selected time range. The absolute values in the flame graph grow as the time range gets bigger while keeping the relative values meaningful. You can zoom in on the time range to get a higher granularity profile up to the point of a single scrape interval. Metrics results represent the aggregated sum value over time of the selected profile type. This allows you to quickly see any spikes in the value of the scraped profiles and zoom in to a particular time range. {{% docs/reference %}} {{% /docs/reference %}}
Project: Netdata (Observability and Analysis / Observability)
File: nvme_device_critical_warnings_state.md

This alert is triggered when an `NVMe device` experiences `critical warnings`. The alert is focusing on your `NVMe` (Non-Volatile Memory Express) SSD storage device which is designed for high-performance and low-latency storage. A critical warning state indicates that the NVMe device has experienced an event, error, or condition which could negatively impact performance, data integrity or device longevity. This could result from a variety of reasons such as high temperature, hardware failures, internal errors, or device reaching end of life. Identify the affected NVMe device(s): This alert provides information in the `info` field about the affected device. It should look like: "NVMe device ${label:device} has critical warnings", where `${label:device}` will be replaced with the actual device name. Check device SMART information: `SMART` (Self-Monitoring, Analysis, and Reporting Technology) provides detailed information about the current health and performance of your NVMe device. To check SMART information for the affected NVMe device, use `smartctl` command: ``` sudo smartctl -a /dev/nvme0n1 ``` Replace `/dev/nvme0n1` with the actual device name identified in step 1. Evaluate the SMART information for critical issues: Review the output of the `smartctl` command to identify the critical warnings or any other concerning attributes. You might see high temperature, high uncorrectable error counts, or high percent of used endurance. These values might help you diagnose the issue with your NVMe device. Take appropriate action based on SMART data: If the temperature of the device is high, ensure proper cooling and airflow in the system. If the device is reaching its end of life, plan for a replacement or backup. If the device has high uncorrectable error counts, consider backing up critical data and contact the manufacturer for support, as this could indicate a possible hardware failure. Make sure to replace, stop the usage of, or seek support for the problematic NVMe device(s) depending on the analysis.
Project: PowerfulSeal (Observability and Analysis / Chaos Engineering)
File: 1_index.md

layout: default title: Welcome nav_order: 1 description: "" permalink: / {:class="img-responsive" width="150px"} {: .fs-9 } PowerfulSeal injects failure into your Kubernetes clusters, so that you can detect problems as early as possible. It allows for writing scenarios describing complete . {: .fs-6 .fw-300 } {: .btn .btn-primary .fs-5 .mb-4 .mb-md-0 .mr-2 } {: .btn .fs-5 .mb-4 .mb-md-0 } works with `Kubernetes`, `OpenStack`, `AWS`, `Azure`, `GCP` and local machines `Prometheus` and `Datadog` metrics collection `yaml` describing chaos experiments multiple Just to give you a taste, here's an example policy. It will kill a single pod, and then check that the service continues responding to HTTP probes, to verify its resiliency to one of its pods going down. ```yaml scenarios: name: Kill one pod in my namespace, make sure the service responds steps: podAction: matches: namespace: myapp filters: randomSample: size: 1 actions: kill: probability: 0.75 probeHTTP: target: service: name: my-service namespace: myapp endpoint: /healthz ``` {: .btn .btn-primary .fs-5 .mb-4 .mb-md-0 .mr-2 } Powerfulseal is distributed by an .
Project: Checkmk (Observability and Analysis / Observability)
File: 16318.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-02-16T07:42:06+00:00 level | 1 class | fix component | wato edition | cre If you used "Save & run connection tests" on the host properties page with SNMP credentials configured, the configured password was not used for the executed tests. A workaround was to enter the password on the "Test connection" page again.
Project: SOFATracer (Observability and Analysis / Observability)
File: Ask_Question.md

name: Ask Question about: Ask a question about usage or feature describe your question clearly describe your use scenes (why need this feature) describe the advice or solution you'd like SOFATracer version: JVM version (e.g. `java -version`): OS version (e.g. `uname -a`): Maven version: IDE version:
Project: Promscale (Observability and Analysis / Observability)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: '' assignees: '' Describe the bug <A clear and concise description of what the bug is.> To Reproduce <Steps to reproduce the behavior:> Expected behavior <A clear and concise description of what you expected to happen.> Screenshots If applicable, add screenshots to help explain your problem. Configuration (as applicable) Promscale Connector: TimescaleDB: Prometheus: Jaeger: OpenTelemetry: Version Distribution/OS: Promscale: TimescaleDB: Additional context <Add any other context about the problem here.>
Project: Netdata (Observability and Analysis / Observability)
File: 10min_dbengine_global_io_errors.md

The Database Engine works like a traditional database. It dedicates a certain amount of RAM to data caching and indexing, while the rest of the data resides compressed on disk. Unlike other memory modes, the amount of historical metrics stored is based on the amount of disk space you allocate and the effective compression ratio, not a fixed number of metrics collected. By using both RAM and disk space, the database engine allows for long-term storage of per-second metrics inside of the Netdata Agent itself. The Netdata Agent monitors the number of IO errors in the last 10 minutes. The dbengine is experiencing I/O errors (CRC errors, out of space, bad disk, etc.). This alert is triggered in critical state when the number of IO errors is greater that 0.
Project: Tracetest (Observability and Analysis / Observability)
File: tracetest_get.md

Get resource Get a resource from your Tracetest server ``` tracetest get analyzer|config|datastore|demo|env|organization|pollingprofile|test|testrunner|testsuite|variableset [flags] ``` ``` -h, --help help for get --id string id of the resource to get ``` ``` -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
Project: Checkmk (Observability and Analysis / Observability)
File: 16349.md

key | value | compatible | yes version | 2.3.0b1 date | 2024-01-17T07:36:58+00:00 level | 1 class | fix component | wato edition | cre This fix renames "Crash Dumps" to "Crash Reports" and mark them as medium sensitive, renames "Local Files" to "Local Files and MKPs". That's somewhat redundant, but it helps to better understand what is packed.