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

id: prometheus title: Monitoring Prometheus Task sidebar_label: Prometheus Task Monitor keywords: [ open source monitoring tool, Prometheus protocol monitoring ] Collect metric data of applications that support the Prometheus protocol. | Parameter name | Parameter help description | ||--| | Target Host | Monitored IPV4, IPV6 or domain name. NoteWithout protocol header (eg: https://, http://) | | Task Name | Identify the name of this monitoring. The name needs to be unique. | | Port | Monitor HTTP port. | | Endpoint Path | Monitor the path of HTTP interfaces, Note It needs to start with /. | | Query Timeout | Set the data collection timeout, unit: ms, default: 6000ms. | | HTTPS | HTTPS enable,optional,default:false. | | Headers | HTTP request headers,optional. | | Params | Request params,optional. | | Content-Type | ContentType,optional. | | BODY | Request body,optional. | | Auth Type | Authentication methods, optional values include: `Basic Auth`, `Digest Auth`,optional. | | Username | Username,optional. | | Password | Password,optional. | | Collection interval | Interval time of monitor periodic data collection, unit: second, and the minimum interval that can be set is 30 seconds. | | Bind Tags | Used to classify and manage monitoring resources. | | Description remarks | For more information about identifying and describing this monitoring, users can note information here. | The exposed monitoring address of the application is: `http://127.0.0.1:8080/actuator/prometheus` You can use the following configuration: Target Host: `127.0.0.1` Port: `8080` Endpoint Path: `/actuator/prometheus` Keep the rest of the settings default.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-tpl_delete.md

category: Template apiurl: '/api/v1/template/#{template_id}' title: "Delete Template" type: 'DELETE' sample_doc: 'template.html' layout: default Delete a Template Required ex. /api/v1/template/225 ```Status: 200``` ```{"message":"template 225 has been deleted"}```
Project: Vector (Observability and Analysis / Observability)
File: debian.md

title: Install Vector on Debian short: Debian supported_installers: ["APT", "dpkg", "Vector installer", "Docker"] weight: 4 [Debian], also known as Debian GNU/Linux, is a Linux distribution composed of free and open-source software, developed by the community-supported Debian Project. This page covers installing and managing Vector on the Debian operating system. {{< supported-installers >}}
Project: Checkmk (Observability and Analysis / Observability)
File: 16605.md

key | value | date | 2024-04-02T06:44:07+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes The CurrentConnections metric was calculated "per second". We now directly show the number of connections returned by the service.
Project: M3 (Observability and Analysis / Observability)
File: overview.md

title: "Overview" weight: 1 M3 Query and M3 Coordinator are written entirely in Go, M3 Query is as a query engine for and M3 Coordinator is a remote read/write endpoint for Prometheus and M3DB. To learn more about Prometheus's remote endpoints and storage, . M3 Query is a service that exposes all metrics query endpoints along with metrics time series metadata APIs that return dimensions and labels of metrics that reside in a M3DB cluster. Note: M3 Coordinator, and by proxy M3DB, by default includes the M3 Query endpoints accessible on port 7201. For production deployments it is recommended to deploy it as a dedicated service to ensure you can scale the memory heavy query role separately from the metrics ingestion write path of writes through M3 Coordinator to M3DB database role nodes. This allows excessive queries to primarily affect the dedicated M3 Query service instead of interrupting service to the write ingestion pipeline. e M3DB with strong guarantees that data was replicated to a quorum of nodes and that the data was durable if desired. M3DB, inspired by and , is a distributed time series database released as open source by . It can be used for storing realtime metrics at long retention. Here are some attributes of the project: Distributed time series storage, single nodes use a WAL commit log and persists time windows per shard independently Cluster management built on top of Built-in synchronous replication with configurable durability and read consistency (one, majority, all, etc) M3TSZ float64 compression inspired by Gorilla TSZ compression, configurable as lossless or lossy Arbitrary time precision configurable from seconds to nanoseconds precision, able to switch precision with any write Configurable out of order writes, currently limited to the size of the configured time window's block size Due to the nature of the requirements for the project, which are primarily to reduce the cost of ingesting and storing billions of timeseries and providing fast scalable reads, there are a few limitations currently that make M3DB not suitable for use as a general purpose time series database. The project has aimed to avoid compactions when at all possible, currently the only compactions M3DB performs are in-memory for the mutable compressed time series window (default configured at 2 hours). As such out of order writes are limited to the size of a single compressed time series window. Consequently backfilling large amounts of data is not currently possible. The project has also optimized the storage and retrieval of float64 values, as such there is no way to use it as a general time series database of arbitrary data structures just yet.
Project: Netdata (Observability and Analysis / Observability)
File: consul_autopilot_health_status.md

This alert checks the health status of the Consul cluster regarding its autopilot functionality. If you receive this alert, it means that the Consul datacenter is experiencing issues, and its health status has been reported as `unhealthy` by the Consul server. Consul's autopilot feature provides automatic management and stabilization features for Consul server clusters, ensuring that the clusters remain in a healthy state. These features include server health monitoring, automatic dead server reaping, and stable server introduction. An unhealthy Consul cluster could experience issues regarding its operations, services, leader elections, and cluster consistency. In this alert scenario, the cluster health functionality is not working correctly, and it could lead to stability and performance problems. Here are some steps to troubleshoot the consulautopilothealth_status alert: Check the logs of the Consul server to identify any error messages or warning signs. The logs will often provide insights into the underlying problems. ``` journalctl -u consul ``` Inspect the Consul health status using the Consul CLI or API: ``` consul operator autopilot get-config ``` Using the Consul HTTP API: ``` curl http://<consul_server>:8500/v1/operator/autopilot/health ``` Verify the configuration of Consul servers, check the `retry_join` and addresses of the Consul servers in the configuration file: ``` cat /etc/consul.d/consul.hcl | grep retry_join ``` Ensure that there is a sufficient number of Consul servers and that they are healthy. The `consul members` command will show the status of cluster members: ``` consul members ``` Check the network connectivity between Consul servers by running network diagnostics like ping and traceroute. Review Consul documentation to gain a deeper understanding of the autopilot health issues and potential configuration problems.
Project: Grafana Loki (Observability and Analysis / Observability)
File: logfmt.md

title: logfmt menuTitle: description: The 'logfmt' Promtail pipeline stage. The logfmt parsing stage reads logfmt log lines and extracts the data into labels. aliases: ../../../clients/promtail/stages/logfmt/ weight: The `logfmt` stage is a parsing stage that reads the log line as and allows extraction of data into labels. ```yaml logfmt: mapping: [ <string>: <string> ... ] [source: <string>] ``` This stage uses the unmarshaler, which means non-string types like numbers or booleans will be unmarshaled into those types. The extracted data can hold non-string values, and this stage does not do any type conversions; downstream stages will need to perform correct type conversion of these values as necessary. Please refer to the for how to do this. If the value extracted is a complex type, its value is extracted as a string. For the given pipeline: ```yaml logfmt: mapping: timestamp: time app: duration: unknown: ``` Given the following log line: ``` time=2012-11-01T22:08:41+00:00 app=loki level=WARN duration=125 message="this is a log line" extra="user=foo"" ``` The following key-value pairs would be created in the set of extracted data: `timestamp`: `2012-11-01T22:08:41+00:00` `app`: `loki` `duration`: `125` For the given pipeline: ```yaml logfmt: mapping: extra: logfmt: mapping: user: source: extra ``` And the given log line: ``` time=2012-11-01T22:08:41+00:00 app=loki level=WARN duration=125 message="this is a log line" extra="user=foo" ``` The first stage would create the following key-value pairs in the set of extracted data: `extra`: `user=foo` The second stage will parse the value of `extra` from the extracted data as logfmt and append the following key-value pairs to the set of extracted data: `user`: `foo`
Project: Weave Scope (Observability and Analysis / Observability)
File: README.md

klog ==== klog is a permanant fork of https://github.com/golang/glog. original README from glog is below glog ==== Leveled execution logs for Go. This is an efficient pure Go implementation of leveled logs in the manner of the open source C++ package https://github.com/google/glog By binding methods to booleans it is possible to use the log package without paying the expense of evaluating the arguments to the log. Through the -vmodule flag, the package also provides fine-grained control over logging at the file level. The comment from glog.go introduces the ideas: Package glog implements logging analogous to the Google-internal C++ INFO/ERROR/V setup. It provides functions Info, Warning, Error, Fatal, plus formatting variants such as Infof. It also provides V-style logging controlled by the -v and -vmodule=file=2 flags. Basic examples: glog.Info("Prepare to repel boarders") glog.Fatalf("Initialization failed: %s", err) See the documentation for the V function for an explanation of these examples: if glog.V(2) { glog.Info("Starting transaction...") } glog.V(2).Infoln("Processed", nItems, "elements") The repository contains an open source version of the log package used inside Google. The master copy of the source lives inside Google, not here. The code in this repo is for export only and is not itself under development. Feature requests will be ignored. Send bug reports to golang-nuts@googlegroups.com.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_roleBinding.RoleBinding.md

title: "Class: RoleBinding" linkTitle: "RoleBinding" slug: "libk8sroleBinding.RoleBinding" .RoleBinding `any` `RoleBinding` new RoleBinding(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeRoleBinding\>('roleBinding').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<KubeRoleBinding\>('roleBinding').className `get` roleRef(): `any` `any` _ `get` subjects(): { `apiGroup`: `string` ; `kind`: `string` ; `name`: `string` ; `namespace`: `string` }[] { `apiGroup`: `string` ; `kind`: `string` ; `name`: `string` ; `namespace`: `string` }[] `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeRoleBinding\>('roleBinding').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeRoleBinding\>('roleBinding').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeRoleBinding\>('roleBinding').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeRoleBinding\>('roleBinding').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeRoleBinding\>('roleBinding').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeRoleBinding\>('roleBinding').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeRoleBinding\>('roleBinding').useList
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: execsnoop.md

title: Gadget execsnoop execsnoop shows new created processes, with container details. ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: execsnoop namespace: gadget spec: node: ubuntu-hirsute gadget: execsnoop runMode: Manual outputMode: Stream filter: namespace: default ``` Start execsnoop gadget ```bash $ kubectl annotate -n gadget trace/execsnoop \ gadget.kinvolk.io/operation=start ``` Stop execsnoop gadget ```bash $ kubectl annotate -n gadget trace/execsnoop \ gadget.kinvolk.io/operation=stop ``` Stream
Project: Checkmk (Observability and Analysis / Observability)
File: 16485.md

key | value | date | 2024-03-11T12:51:50+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes When creating hosts in a folder with umlauts in the name via one of the `host_config` endpoints the endpoint would return an error 400 even though the query was correct. Now the hosts are created correctly.
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: CONTRIBUTING.md

Thank you for your interest in contributing to Pyroscope! We welcome all people who want to contribute in a healthy and constructive manner within our community. To help us create a safe and positive community experience for all, we require all participants to adhere to the . This document is a guide to help you through the process of contributing to Pyroscope. Set up your . Read the we use. Check out the list of .
Project: Checkmk (Observability and Analysis / Observability)
File: 16654.md

key | value | date | 2024-03-20T08:45:21+00:00 version | 2.4.0b1 class | fix edition | cre component | wato level | 1 compatible | yes When disabling the "Hide internal folder names in Setup" setting, the internal name must be set by the user when creating folders. Previously, the field was still modifiable when editing the folder properties, however no changes to it were saved. This werk now marks the field as read only when editing the folder properties.
Project: Elastic (Observability and Analysis / Observability)
File: case.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Accepts pairs of conditions and values. The function returns the value that belongs to the first condition that evaluates to `true`. If the number of arguments is odd, the last argument is the default value which is returned when no condition matches. If the number of arguments is even, and no condition matches, the function returns `null`. ``` FROM employees | EVAL type = CASE( languages <= 1, "monolingual", languages <= 2, "bilingual", "polyglot") | KEEP emp_no, languages, type ```
Project: Netdata (Observability and Analysis / Observability)
File: microsoft_teams.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/integrations/microsoft_teams.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/metadata.yaml" sidebar_label: "Microsoft Teams" 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/teams.svg" width="150"/> From the Netdata Cloud UI, you can manage your space's notification settings and enable the configuration to deliver notifications to a Microsoft Teams channel. <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> To add Microsoft Teams notifications integration to your Netdata Cloud space you will need the following: A Netdata Cloud account. Access to the Netdata Cloud space as an Admin. The Space to be on a paid plan. A . Note that this is a paid account. The integration gets enabled at a team's channel level. Click on the `...` (aka three dots) icon showing up next to the channel name, it should appear when you hover over it. Click on `Connectors`. Look for the `Incoming Webhook` connector and click configure. Provide a name for your Incoming Webhook Connector, for example Netdata Alerts. You can also customize it with a proper icon instead of using the default image. Click `Create`. The Incoming Webhook URL is created. That is the URL to be provided to the Netdata Cloud configuration. 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 Microsoft Teams 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 Microsoft Teams: Microsoft Teams Incoming Webhook URL - the Incoming Webhook URL that was generated earlier.
Project: Checkmk (Observability and Analysis / Observability)
File: 16674.md

key | value | date | 2024-04-02T15:57:33+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes This is only relevant for plugin developers. If some Dictionary entries are thematically closer related to each other than others they can now be configured and displayed as such.
Project: Graylog (Observability and Analysis / Observability)
File: Table.md

<h3>Regular Table</h3> ```js <Table> <thead> <tr> <th>#</th> <th>Col 1</th> <th>Col 2</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Foo Bar</td> <td>active</td> </tr> <tr> <td>2</td> <td>Lorem Ipsum</td> <td>active</td> </tr> <tr> <td>3</td> <td>Ex salutatus</td> <td>active</td> </tr> <tr> <td>4</td> <td>Usu petentium</td> <td>active</td> </tr> </tbody> </Table> ``` <h3>Table with Options</h3> ```js <Table bordered condensed striped hover> <thead> <tr> <th>#</th> <th>Col 1</th> <th>Col 2</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Foo Bar</td> <td>active</td> </tr> <tr> <td>2</td> <td>Lorem Ipsum</td> <td>active</td> </tr> <tr> <td>3</td> <td>Ex salutatus</td> <td>active</td> </tr> <tr> <td>4</td> <td>Usu petentium</td> <td>active</td> </tr> </tbody> </Table> ``` <h3>Variant Rows</h3> ```js <Table hover> <thead> <tr> <th>#</th> <th>Col 1</th> <th>Col 2</th> </tr> </thead> <tbody> <tr className="warning"> <td>1</td> <td>Foo Bar</td> <td>active</td> </tr> <tr className="success"> <td>2</td> <td>Lorem Ipsum</td> <td>active</td> </tr> <tr className="info"> <td>3</td> <td>Ex salutatus</td> <td>active</td> </tr> <tr className="danger"> <td>4</td> <td>Usu petentium</td> <td>active</td> </tr> <tr className="active"> <td>5</td> <td>Odio choro</td> <td>active</td> </tr> </tbody> </Table> ```
Project: Prometheus (Observability and Analysis / Observability)
File: MAINTAINERS.md

General maintainers: Bryan Boreham (bjboreham@gmail.com / @bboreham) Levi Harrison (levi@leviharrison.dev / @LeviHarrison) Ayoub Mrini (ayoubmrini424@gmail.com / @machine424) Julien Pivotto (roidelapluie@prometheus.io / @roidelapluie) Maintainers for specific parts of the codebase: `cmd` `promtool`: David Leadbeater (<dgl@dgl.cx> / @dgl) `discovery` `k8s`: Frederic Branczyk (<fbranczyk@gmail.com> / @brancz) `documentation` `prometheus-mixin`: Matthias Loibl (<mail@matthiasloibl.com> / @metalmatze) `model/histogram` and other code related to native histograms: Bjrn Rabenstein (<beorn@grafana.com> / @beorn7), George Krajcsovits (<gyorgy.krajcsovits@grafana.com> / @krajorama) `storage` `remote`: Callum Styan (<callumstyan@gmail.com> / @cstyan), Bartomiej Potka (<bwplotka@gmail.com> / @bwplotka), Tom Wilkie (<tom.wilkie@gmail.com> / @tomwilkie) `otlptranslator`: Arve Knudsen (<arve.knudsen@gmail.com> / @aknuds1), Jess Vzquez (<jesus.vazquez@grafana.com> / @jesusvazquez) `tsdb`: Ganesh Vernekar (<ganesh@grafana.com> / @codesome), Bartomiej Potka (<bwplotka@gmail.com> / @bwplotka), Jess Vzquez (<jesus.vazquez@grafana.com> / @jesusvazquez) `agent`: Robert Fratto (<robert.fratto@grafana.com> / @rfratto) `web` `ui`: Julius Volz (<julius.volz@gmail.com> / @juliusv) `module`: Augustin Husson (<husson.augustin@gmail.com> @nexucis) `Makefile` and related build configuration: Simon Pasquier (<pasquier.simon@gmail.com> / @simonpasquier), Ben Kochie (<superq@gmail.com> / @SuperQ) For the sake of brevity, not all subtrees are explicitly listed. Due to the size of this repository, the natural changes in focus of maintainers over time, and nuances of where particular features live, this list will always be incomplete and out of date. However the listed maintainer(s) should be able to direct a PR/question to the right person. v3 release coordinators: Alex Greenbank (<alex.greenbank@grafana.com> / @alexgreenbank) Carrie Edwards (<carrie.edwards@grafana.com> / @carrieedwards) Fiona Liao (<fiona.liao@grafana.com> / @fionaliao) Jan Fajerski (<github@fajerski.name> / @jan--f) Jess Vzquez (<jesus.vazquez@grafana.com> / @jesusvazquez) Nico Pazos (<nicolas.pazos-mendez@grafana.com> / @npazosmendez) Owen Williams (<owen.williams@grafana.com> / @ywwg) Tom Braack (<me@shorez.de> / @sh0rez)
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: kube_events_timestamp.md

title: Kubernetes Events Timestamp weight: 200 generated_file: true Fluentd Filter plugin to select particular timestamp into an additional field Added time field name Default: triggerts Time field names in order of relevance Default: event.eventTime, event.lastTimestamp, event.firstTimestamp {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: Flow metadata: name: es-flow spec: filters: kubeeventstimestamp: timestamp_fields: "event.eventTime" "event.lastTimestamp" "event.firstTimestamp" mappedtimekey: mytimefield selectors: {} localOutputRefs: es-output {{</ highlight >}} Fluentd config result: {{< highlight xml >}} <filter > @type kubeeventstimestamp @id test-kube-events-timestamp timestamp_fields ["event.eventTime","event.lastTimestamp","event.firstTimestamp"] mappedtimekey mytimefield </filter> {{</ highlight >}}