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

The `vsphereoutboundpackets_errors` alert is triggered when there is a high number of outbound network errors on a virtual machine's network interface in the last 10 minutes. This alert is related to the vSphere environment and indicates a possible issue with the virtual machine's network configuration or the underlying virtual network infrastructure. Identify the virtual machine with the issue The alert should show you the name or identifier of the virtual machine(s) facing the high number of outbound packet errors. Check the network interface configuration Verify the virtual machine's network interface configuration within vSphere. Please ensure the configuration matches the expected settings and is correctly connected to the right virtual network. Monitor virtual network infrastructure Inspect the virtual switches (vSwitches), port groups, and distributed switches in the vSphere environment. Look for misconfigurations, high packet loss rates, or other issues that may cause these errors. Check physical network infrastructure Investigate if there are any problems with the physical network components, such as NICs (Network Interface Cards), switches, or cables. As issues at the physical layer could also result in network packet errors. Examine virtual machine logs Review the virtual machine's logs for any network-related errors or warnings. This might give you more information about the root cause of the problem. Update network drivers and tools Ensure that the latest version of network drivers and VMware tools are installed on the virtual machine. Outdated or incorrect drivers can result in packet errors. Contact support If you cannot resolve the issue after completing the above steps, contact your vSphere support team for further assistance.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: metrics-queries.md

title: Service graph metrics queries menuTitle: Metrics queries description: Use PromQL queries to access metrics from service graphs weight: 300 A collection of useful PromQL queries for service graphs. In most cases, users want to see a visual representation of their service graph. Grafana uses the service graph metrics created by Tempo and builds that visual for the user. However, in some cases, users may want to interact with the metrics that define that service graph directly. They may want to, for example, programmatically analyze how their services are interconnected and build downstream applications that use this information. To help with this, we've provided a collection of useful PromQL queries that can be used to explore service graph metrics. An instant query will give a single value at the end of the selected time range. are quicker to execute and it often easier to understand their results. We will prefer them in some scenarios: Show me the total calls in the last 7 days for every client/server pair: ```promql sum(increase(tracesservicegraphrequestserversecondscount{}[7d])) by (server, client) > 0 ``` If you'd like to only see when a single service is the server: ```promql sum(increase(tracesservicegraphrequestserversecondscount{server="foo"}[7d])) by (client) > 0 ``` If you'd like to only see when a single service is the client: ```promql sum(increase(tracesservicegraphrequestserversecondscount{client="foo"}[7d])) by (server) > 0 ``` In all of the above queries, you can adjust the interval to change the amount of time this is calculated for. So if you wanted the same analysis done over one day: ```promql sum(increase(tracesservicegraphrequestserversecondscount{}[1d])) by (server, client) > 0 ``` Range queries are nice for calculating service graph info over a time range instead of a single point in time. Taking two of the queries above, we can request the rate over time that any given service acted as the client or server: ```promql sum(rate(tracesservicegraphrequestserversecondscount{server="foo"}[5m])) by (client) > 0 sum(rate(tracesservicegraphrequestserversecondscount{client="foo"}[5m])) by (server) > 0 ``` Notice that our interval dropped to 5m. This is so we only calculate the rate over the past 5 minutes which creates a more responsive graph. These queries will give us latency quantiles for the above rate. If we were interested in how the latency changed over time between any two services we could use these. In the following query the `.9` means we're calculating the 90th percentile. Adjust this value if you want to calculate a different percentile for latency (e.g. p50, p95, p99, etc). ```promql histogramquantile(.9, sum(rate(tracesservicegraphrequestserverseconds_bucket{client="foo"}[5m])) by (server, le)) ``` Using the optional metric for latency of a messaging system to see potential middleware latencies: ```promql histogramquantile(.9, sum(rate(tracesservicegraphrequestmessagingsystemsecondsbucket{}[5m])) by (client, server, le)) ```
Project: Netdata (Observability and Analysis / Observability)
File: pihole_blocklist_last_update.md

This alert indicates that the Pi-hole blocklist (Gravity) file hasn't been updated for an extended period of time. The blocklist file contains domains that have been processed by Pi-hole to filter ads and malicious content. An outdated blocklist may leave your system more vulnerable to unwanted content and threats. Check the current blocklist update status To see how long it has been since the last update, you can use the following command: ``` root@netdata~ # pihole -q -adlist ``` This will display the timestamp of the last update. Rebuild the blocklist If the alert indicates that your blocklist file is outdated, it's essential to update it by running: ``` root@netdata~ # pihole -g ``` This command will download the necessary files and rebuild the blocklist. Check for errors during the update If you encounter any issues during the update, check the `/var/log/pihole.log` file for errors. You can also check the `/var/log/pihole-FTL.log` file for more detailed information on the update process. Verify the blocklist update interval To ensure that your blocklist file is updated regularly, make sure you configure a regular update interval. You can do this by editing the `cron` job for Pi-hole: ``` root@netdata~ # crontab -e ``` This will open an editor. Look for the line containing the `pihole -g` command and adjust the schedule accordingly. For example, to update the blocklist daily, add the following line: ``` 0 0 * /usr/local/bin/pihole -g ``` Save the file and exit the editor to apply the changes. Monitor the blocklist update status After performing the necessary troubleshooting steps, keep an eye on the `piholeblocklistlast_update` alert to ensure that your blocklist file is updated as expected.
Project: Grafana (Observability and Analysis / Observability)
File: query_help.md

replaced with measurement name $measurement = replaced with measurement name $1 - $9 = replaced with part of measurement name (if you separate your measurement name with dots) $col = replaced with column name $tag_exampletag = replaced with the value of the <i>exampletag</i> tag You can also use [[tag_exampletag]] pattern replacement syntax When stacking is enabled it is important that points align If there are missing points for one series it can cause gaps or missing bars You must use fill(0), and select a group by time low limit Use the group by time option below your queries and specify for example 10s if your metrics are written every 10 seconds This will insert zeros for series that are missing measurements and will make stacking work properly Group by time is important, otherwise the query could return many thousands of datapoints that will slow down Grafana Leave the group by time field empty for each query and it will be calculated based on time range and pixel width of the graph If you use fill(0) or fill(null) set a low limit for the auto group by time interval The low limit can only be set in the group by time option below your queries Example: 60s if you write metrics to InfluxDB every 60 seconds
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_registry.LogsEvent.md

title: "Interface: LogsEvent" linkTitle: "LogsEvent" slug: "plugin_registry.LogsEvent" .LogsEvent Event fired when viewing pod logs. data: `Object` | Name | Type | Description | | : | : | : | | `resource?` | `any` | The resource for which the terminal was opened (currently this only happens for Pod instances). | | `status` | `OPENED` \| `CLOSED` | What exactly this event represents. 'OPEN' when the logs dialog is opened. 'CLOSED' when it is closed. | _ type: `LOGS`
Project: Vector (Observability and Analysis / Observability)
File: 2020-12-23-vector-top.md

date: "2020-12-23" title: "Introducing `vector top`" description: "A CLI dashboard interface for monitoring Vector instances." authors: ["lucperkins"] featured: true pr_numbers: [] release: "0.12.0" hideonrelease_notes: false badges: type: "new feature" domains: ["cli"] domains: ["observability"] is a command for the Vector [CLI] that displays both metrics emitted by your Vector instance as well as information about your Vector [topology] through a beautiful dashboard-style interface reminiscent of tools like [htop]. To use it, run `vector top` and specify the URL of the running Vector instance you want to monitor: ```bash vector top --url https://my-vector-instance.prod.acmecorp.biz ``` That pulls up an interface that looks like this: By default, the `vector top` looks for a Vector instance running locally at http://localhost:8686, but you can also monitor remote instances, as in the example above. The information displayed updates every second by default, but you can adjust that using the `--interval` flag. Architecturally, `vector top` interacts directly with Vector's , which was built with `vector top` as a primary consumer. The dashboard UI was created using the excellent [tui-rs] library.
Project: OpenTelemetry (Observability and Analysis / Observability)
File: membership.md

name: Organization Membership Request about: Request membership in a OpenTelemetry Org title: 'REQUEST: New membership for <your-GH-handle>' labels: area/github-membership assignees: '' <!-- Please remember to change the title of this issue by replacing <your-GH-handle> with the actual GitHub handle --> e.g. (at)example_user [ ] I have reviewed the community membership guidelines (https://github.com/open-telemetry/community/blob/main/community-membership.md) [ ] I have enabled 2FA on my GitHub account. See https://github.com/settings/security (use https://slack.cncf.io/ to get an invite) [ ] I am actively contributing to 1 or more OpenTelemetry subprojects [ ] I have two sponsors that meet the sponsor requirements listed in the community membership guidelines. Among other requirements, sponsors must be approvers or maintainers of at least one repository in the organization and not both affiliated with the same company [ ] I have spoken to my sponsors ahead of this application, and they have agreed to sponsor my application <!-- Replace (at) with the `@` sign --> (at)sponsor-1 (at)sponsor-2 Each sponsor should reply to this issue with the comment "I support". Please remember, it is an applicant's responsibility to get their sponsors' confirmation before submitting the request. PRs reviewed / authored Issues responded to Community activities I organized/ran SIG projects I am involved with
Project: Grafana Mimir (Observability and Analysis / Observability)
File: migrationguide.md

This guide is intended to assist in the migration from the `azure-storage-blob-go` module, or previous betas of `azblob`, to the latest releases of the `azblob` module. The redesign of the `azblob` module separates clients into various sub-packages. In previous versions, the public surface area was "flat", so all clients and supporting types were in the `azblob` package. This made it difficult to navigate the public surface area. In `azure-storage-blob-go` a client constructor always requires a `url.URL` and `Pipeline` parameters. In `azblob` a client constructor always requires a `string` URL, any specified credential type, and a `*ClientOptions` for optional values. You pass `nil` to accept default options. ```go // new code client, err := azblob.NewClient("<my storage account URL>", cred, nil) ``` In `azure-storage-blob-go` you created a `Pipeline` with the required credential type. This pipeline was then passed to the client constructor. In `azblob`, you pass the required credential directly to the client constructor. ```go // new code. cred is an AAD token credential created from the azidentity module client, err := azblob.NewClient("<my storage account URL>", cred, nil) ``` The `azure-storage-blob-go` module provided limited support for OAuth token authentication via `NewTokenCredential`. This been replaced by using Azure Identity credentials from . Authentication with a shared key via `NewSharedKeyCredential` remains unchanged. In `azure-storage-blob-go` you created a `Pipeline` with `NewAnonymousCredential` to support anonymous or SAS authentication. In `azblob` you use the construtor `NewClientWithNoCredential()` instead. ```go // new code client, err := azblob.NewClientWithNoCredential("<public blob or blob with SAS URL>", nil) ``` In `azure-storage-blob-go` you explicitly created a `Marker` type that was used to page over results (). In `azblob`, operations that return paginated values return a `*runtime.Pager[T]`. ```go // new code pager := client.NewListBlobsFlatPager("my-container", nil) for pager.More() { page, err := pager.NextPage(context.TODO()) // process results } ``` In `azure-storage-blob-go` you explicitly created a HTTP pipeline with configuration before creating a client. This pipeline instance was then passed as an argument to the client constructor (). In `azblob` a HTTP pipeline is created during client construction. The pipeline is configured through the `azcore.ClientOptions` type. ```go // new code client, err := azblob.NewClient(account, cred, &azblob.ClientOptions{ ClientOptions: azcore.ClientOptions{ // configure HTTP pipeline options here }, }) ```
Project: Netdata (Observability and Analysis / Observability)
File: kern.ipc.msq.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/integrations/kern.ipc.msq.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/metadata.yaml" sidebar_label: "kern.ipc.msq" learn_status: "Published" learnrelpath: "Collecting Metrics/FreeBSD" 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/freebsd.svg" width="150"/> Plugin: freebsd.plugin Module: kern.ipc.msq <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Collect number of IPC message Queues 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. These metrics show statistics IPC messages statistics. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | system.ipcmsqqueues | queues | queues | | system.ipcmsqmessages | messages | messages | | system.ipcmsqsize | allocated, used | bytes | There are no alerts configured by default for this integration. No action required. The configuration file name for this integration is `netdata.conf`. Configuration for this specific integration is located in the `[plugin:freebsd]` section within that file. The file format is a modified INI syntax. The general structure is: ```ini [section1] option1 = some value option2 = some other value [section2] option3 = some third value ``` You can edit the configuration file using the `edit-config` script from the Netdata . ```bash cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata sudo ./edit-config netdata.conf ``` <details><summary>Config options</summary> | Name | Description | Default | Required | |:-|:--|:-|:--:| | kern.ipc.msq | Enable or disable IPC message queue metric. | yes | no | </details> There are no configuration examples.
Project: Netdata (Observability and Analysis / Observability)
File: offline.md

<!-- title: "Install Netdata on offline systems" description: "Install the Netdata Agent on offline/air gapped systems to benefit from real-time, per-second monitoring without connecting to the internet." customediturl: "https://github.com/netdata/netdata/edit/master/packaging/installer/methods/offline.md" sidebar_label: "Offline systems" learn_status: "Published" learnrelpath: "Installation/Installation methods" sidebar_position: 50 --> Our kickstart install script provides support for installing the Netdata Agent on air-gapped systems which do not have a usable internet connection by prefetching all of the required files so that they can be copied to the target system. Currently, we only support using static installs with this method. There are tentative plans to support building locally on offline systems as well, but there is currently no estimate of when this functionality may be implemented. Users who wish to use native packages on offline systems may be able to do so using whatever tooling their distribution already provides for offline package management (such as `apt-offline` on Debian or Ubuntu systems), but this is not officially supported. The first step to installing Netdata on an offline system is to prepare the offline installation source. This can be as a regular user from any internet connected system that has the following tools available: cURL or wget sha256sum or shasum A standard POSIX compliant shell To prepare the offline installation source, simply run: ```bash wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh && sh /tmp/netdata-kickstart.sh --prepare-offline-install-source ./netdata-offline ``` or ```bash curl https://get.netdata.cloud/kickstart.sh > /tmp/netdata-kickstart.sh && sh /tmp/netdata-kickstart.sh --prepare-offline-install-source ./netdata-offline ``` The exact name used for the directory does not matter, you can specify any other name you want in place of `./netdata-offline`. This will create a directory called `netdata-offline` in the current directory and place all the files required for an offline install in it. If you want to use a specific release channel (nightly or stable), it must be specified on this step using the appropriate option for the kickstart script. Once you have prepared the offline install source, you need to copy the offline install source directory to the target system. This can be done in any manner you like, as long as filenames are not changed. After copying the files, simply run the `install.sh` script located in the offline install source directory. It accepts all the [same options as the kickstart script](https://github.com/netdata/netdata/blob/master/packaging/installer/methods/kickstart.md#optional-parameters-to-alter-your-installation) for further customization of the installation, though it will default to not enabling automatic updates (as they are not supported on offline installs).
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-dashboard_screen_create.md

category: DashboardScreen apiurl: '/api/v1/dashboard/screen' title: 'Create a DashboardScreen' type: 'POST' sample_doc: 'dashboard.html' layout: default Required Content-type: application/x-www-form-urlencoded ```name=laiwei-sceen1&pid=0``` ```Status: 200``` ```{"name":"laiwei-sceen1","pid":0,"screen_id":961} ``` For errors responses, see the .
Project: Netdata (Observability and Analysis / Observability)
File: splunk.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/integrations/splunk.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/metadata.yaml" sidebar_label: "Splunk" 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/splunk-black.svg" width="150"/> From the Cloud interface, you can manage your space's notification settings and from these you can add a specific configuration to get notifications delivered on Splunk. <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> To add Splunk notification you need: A Netdata Cloud account Access to the space as an Admin The Space needs to be on a paid plan URI and token for your Splunk HTTP Event Collector. Refer to the for detailed instructions. 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 Splunk 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 - provide a descriptive name for your configuration to easily identify it. Rooms - select the nodes or areas of your infrastructure you want to receive notifications about. Notification - choose the type of notifications you want to receive: All Alerts and unreachable, All Alerts, Critical only. Integration configuration are the specific notification integration required settings, which vary by notification method. For Splunk: HTTP Event Collector URI - The URI of your HTTP event collector in Splunk HTTP Event Collector Token - the token that Splunk provided to you when you created the HTTP Event Collector
Project: Checkmk (Observability and Analysis / Observability)
File: 16040.md

key | value | date | 2024-01-31T07:14:24+00:00 version | 2.4.0b1 class | feature edition | cee component | multisite level | 1 compatible | yes The Top list dashlet displays the top (or bottom) X values of a selected metric. The number of values can be selected, but is limited to 50 values.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_router.md

title: "Module: lib/router" linkTitle: "lib/router" slug: "lib_router" NotFoundRoute: `Object` | Name | Type | | : | : | | `component` | () => `Element` | | `exact` | `boolean` | | `name` | `string` | | `noAuthRequired` | `boolean` | | `path` | `string` | | `sidebar` | ``null`` | createRouteURL(`routeName`, `params?`): `string` | Name | Type | | : | : | | `routeName` | `string` | | `params` | | `string` _ getDefaultRoutes(): `Object` `Object` _ getRoute(`routeName`): | Name | Type | | : | : | | `routeName` | `string` | _ getRoutePath(`route`): `string` | Name | Type | | : | : | | `route` | | `string` _ getRouteUseClusterURL(`route`): `boolean` Should the route use a cluster URL? | Name | Type | | : | : | | `route` | | `boolean` true when a cluster URL contains cluster in the URL. eg. /c/minikube/my-url false, the URL does not contain the cluster. eg. /my-url