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

id: dm title: Monitoring DM database sidebar_label: DM Database keywords: [open source monitoring tool, open source database monitoring tool, monitoring DM database metrics] Collect and monitor the general performance metrics of the DM database. DM8+ is supported. | Parameter name | Parameter help description | | - | - | | Monitor Host | Monitored peer IPV4, IPV6 or domain name. Note without protocol headers (eg: https://, http://). | | Monitor Name | Identifies the name of this monitor. The name needs to be unique. | | Port | The port provided by the database externally, the default is 5236. | | Query Timeout | Set the timeout when the SQL query does not respond to data, in ms milliseconds, the default is 3000 milliseconds. | | database name | database instance name, optional. | | username | database connection username, optional | | password | database connection password, optional | | URL | Database connection URL, optional | | Collection Interval | Monitor periodical collection data interval, in seconds, 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, and then continue to add and modify operations if the detection is successful | | Description Remarks | More remarks that identify and describe this monitoring, users can remark information here | | Metric Name | Metric Unit | Metric Help Description | | | -- | | | PORT_NUM | None | Database exposed service port | | CTL_PATH | None | Control File Path | | MAX_SESSIONS | None | Maximum database connections | | Metric Name | Metric Unit | Metric Help Description | | -- | -- | | | status$ | None | Open/Close status of DM database | | Metric Name | Metric Unit | Metric Help Description | | - | -- | - | | dmsqlthd | None | Thread for writing dmsql dmserver | | dmiothd | None | IO threads, controlled by IOTHRGROUPS parameter, default is 2 threads | | dmquitthd | None | Thread used to perform a graceful shutdown of the database |
Project: Elastic (Observability and Analysis / Observability)
File: GeneralArchitectureGuide.md

Elasticsearch supports and , configurable via (e.g. `elasticsearch.yml` file), command line arguments and REST APIs. The class is the building block for Elasticsearch server settings. Each `Setting` can take multiple declarations to define setting characteristics. All setting values first come from the node-local `elasticsearch.yml` file, if they are set therein, before falling back to the default specified in their `Setting` declaration. with `Property.Dynamic` can be updated during runtime, but must be paired with a and registered in the `ClusterSettings` via a utility like to catch and immediately apply dynamic changes. NB that a common dynamic Setting bug is always reading the value directly from , which holds the default and dynamically updated values, but not the node-local `elasticsearch.yml` value. The scope of a Setting must also be declared, such as `Property.IndexScope` for a setting that applies to indexes, or `Property.NodeScope` for a cluster-level setting. tracks the . Ultimately the `ClusterSettings` get loaded via the . Additional settings from the various plugins are [collected during node construction] and passed into the . The Plugin interface has a method via which each plugin can declare additional settings. Externally, and (and the corresponding REST endpoints) allow users to dynamically change cluster and index settings, respectively. Internally, `AbstractScopedSettings` (parent class of `ClusterSettings`) has various helper methods to track dynamic changes: it keeps a consumer lambdas to run updates when settings are changed in the cluster state. The `ClusterApplierService` through to the `AbstractScopedSettings`, invoking the consumers registered therein for each updated setting. Index settings are always persisted. They can only be modified on an existing index, and setting values are persisted as part of the `IndexMetadata`. Cluster settings, however, can be either persisted or transient depending on how they are tied to (). Changes to persisted cluster settings will survive a full cluster restart; whereas changes made to transient cluster settings will reset to their default values, or the `elasticsearch.yml` values, if the cluster state must ever be reloaded from persisted state. (what warrants a plugin?) (what plugins do we have?) (Overview of our testing frameworks. Discuss base test classes.)
Project: Netdata (Observability and Analysis / Observability)
File: postgres_db_cache_io_ratio.md

The `postgresdbcacheioratio` alert is related to PostgreSQL databases and measures the `cache hit ratio` in the last minute. If you receive this alert, it means that your database server cache is not as efficient as it should be, and your system is frequently reading data from disk instead of cache, causing possible slow performance and higher I/O workload. Cache hit ratio is an indicator of how frequently the data required for a query is found in the cache instead of reading it directly from disk. Higher cache hit ratios mean increased query performance and less disk I/O, which can greatly impact your database performance. Determine if the cache hit ratio issue is affecting your overall database performance using `htop`: ``` htop ``` Check the `Load average` gauge, if it's in the safe zone (green), the cache hit ratio issue might not be affecting overall performance. If it's in the yellow or red zone, further troubleshooting is necessary. Check per-database cache hit ratio: Run the following query to see cache hit ratios for each database: ``` SELECT dbname, (blockcachehitkb / (blockcachemissreadkb + blockcachehitkb)) * 100 AS cachehitratio FROM (SELECT datname as dbname, sum(blksread * 8.0 / 1024) as blockcachemissread_kb, sum(blkshit * 8.0 / 1024) as blockcachehitkb FROM pgstatdatabase GROUP BY datname) T; ``` Analyze the results to determine which databases have a low cache hit ratio. Analyze PostgreSQL cache settings: Check the cache settings in the `postgresql.conf` file. You may need to increase the `shared_buffers` parameter to allocate more memory for caching purposes, if there is available memory on the host. For example, set increased shared_buffers value: ``` shared_buffers = 2GB # Change the value according to your host's available memory. ``` Restart the PostgreSQL service to apply the changes: ``` sudo systemctl restart postgresql ``` Monitor the cache hit ratio to determine if the changes improved performance. It might take some time for the changes to take effect, so be patient and monitor the cache hit ratio and overall system health over time.
Project: OpenMetrics (Observability and Analysis / Observability)
File: README.md

The OpenMetrics.md is the source of the RFC text. To generate the output text, is used. This requires Ruby. From the top of the repository: bundle install bundle exec kdrfc specification/OpenMetrics.md mv -v specification/OpenMetrics.txt specification/draft-richih-opsawg-openmetrics-00.txt ta/parsers/badhelp0/metrics | ./bin/openmetricsvalidator 2021/06/08 20:04:20 failed to validate input: "INVALID" "\n" is not a valid start token cat ./tests/testdata/parsers/simple_counter/metrics | ./bin/openmetricsvalidator 2021/06/08 20:04:30 successfully validated input ```
Project: Headlamp (Observability and Analysis / Observability)
File: testing.md

title: Testing weight: 5 Can Headlamp work well with busy clusters? Limits we want to test for to begin with: 10,000 pods 1,000 nodes 10,000 events 15 clusters (300 clusters max) Steps: Create load in a cluster Run Headlamp and see if it works well compared to low load performance profiles CPU/memory usage feel is a toolkit that enables setting up a cluster of thousands of Nodes in seconds. Under the scene, all Nodes are simulated to behave like real ones, so the overall approach employs a pretty low resource footprint that you can easily play around on your laptop. Maybe you need to delete a cluster and create a fresh one. ```bash kwokctl delete cluster kwokctl create cluster ``` Make sure your kubectl context is set to 'kwok-kwok'. ```bash kubectl config get-contexts ``` This will create 900 nodes, 9000 pods, and 1000 events as fast as possible. Then it will create 1 event per second up to a total of 9000 events. Also one per second: 100 new nodes, and 1000 new pods. Finally it will create 15 clusters. ```bash cd load-tests npm install echo "Creating initial activity: 900 nodes, 9000 pods, and 1000 events" node scripts/create-nodes.js 900 0 node scripts/create-pods.js 9000 0 node scripts/create-events.js 1000 0 node scripts/create-deployments.js 500 0 node scripts/create-clusters.js 15 0 ``` To make some activity after the initial data is loaded. ```bash echo "" echo "creating 1 node, 1 pod, and 1 event per second" node scripts/create-events.js 9000 1 & node scripts/create-nodes.js 100 1 & node scripts/create-pods.js 1000 1 & ``` Kwok clusters can take up a lot of resources even doing nothing, due to the Kubernetes API server using resources even when idle. So when you're done, you can delete them like this. ```bash kwokctl delete cluster --name=kwok node scripts/create-clusters.js 15 0 --delete ```
Project: Grafana Loki (Observability and Analysis / Observability)
File: labelallow.md

title: labelallow menuTitle: description: The 'labelallow' Promtail pipeline stage. aliases: ../../../clients/promtail/stages/labelallow/ weight: The labelallow stage is an action stage that allows only the provided labels to be included in the label set that is sent to Loki with the log entry. ```yaml labelallow: [<string>] ... ``` For the given pipeline: ```yaml kubernetessdconfigs: role: pod pipeline_stages: docker: {} labelallow: kubernetespodname kubernetescontainername ``` Given the following incoming labels: `kubernetespodname`: `"loki-pqrs"` `kubernetescontainername`: `"loki"` `kubernetespodtemplate_hash`: `"79f5db67b"` `kubernetescontrollerrevision_hash`: `"774858987d"` Only the below labels would be sent to `loki` `kubernetespodname`: `"loki-pqrs"` `kubernetescontainername`: `"loki"`
Project: Checkmk (Observability and Analysis / Observability)
File: 15025.md

key | value | date | 2023-12-18T13:50:29+00:00 version | 2.3.0b1 class | fix edition | cre component | core level | 1 compatible | no For a dual stack host check mk will create PING IPv4 and Ping IPv6 services automatically. Those services are created by the core configuration and cannot be deactivated. With the CMC core two Ping IPv4/6 services would appear on the host, the nagios core ignores the user defined service. The core configuration now only creates the respective PING service for the main interface of the host. If you have a user defined Ping IPv4/6 service it will replace the old auto generated one with the next Activate Changes.
Project: Opstrace (Observability and Analysis / Observability)
File: 1-bug-report.md

name: "\U0001F41B Bug report" about: Create a report to help us improve title: '' labels: bug assignees: '' Describe the bug A clear and concise description of what the bug is. (Please provide textual output rather than screenshots, if possible.) To Reproduce Steps to reproduce the behavior. Expected behavior _A clear and concise description of what you expected to happen.
Project: Promscale (Observability and Analysis / Observability)
File: PULL_REQUEST_TEMPLATE.md

<!-- Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue. Linking an issue can be done by mentioning a key word (`closes #111`, `fixes #222`, `resolve #333`) or manually on github.com, even after the pull request is created. Note: If your PR involves benchmarks, you can run the `Benchmarks` workflow by adding `action:benchmarks` label. The PR must be opened from Promscale branch so that Github actions can leave a comment comparing results against `master`. --> Please take into account the following non-code changes that you may need to make with your PR: [ ] CHANGELOG entry for user-facing changes [ ] Updated the relevant documentation
Project: HertzBeat (Observability and Analysis / Observability)
File: alert_webhook.md

id: alert_webhook title: Alert WebHook callback notification sidebar_label: Alert webHook notification keywords: [open source monitoring tool, open source alerter, open source webhook notification] After the threshold is triggered send alarm information and call the Webhook interface through post request to notify the recipient. Alarm notification->Add new recipient ->Select WebHook notification method-> Set WebHook callback address -> Confirm Configure the associated alarm notification strategy Add new notification strategy-> Associate the recipient just set-> Confirm Note Adding a new recipient does not mean that it is effective to receive alarm information. It is also necessary to configure the associated alarm notification strategy, that is, to specify which messages are sent to which recipients. Content formatJSON ```json { "id":76456, "target":"available", "alertDefineId":232, "priority":0, "content":": UN_CONNECTABLE", "tag": { "monitorId": 3543534545, "monitorName":"API_poetry.didi.top" }, "status":0, "times":1, "gmtCreate":"2022-02-25T13:32:13", "gmtUpdate":"2022-02-25T13:32:13" } ``` | | | |--|--| | id | integer($int64) title: Alarm record entity primary key index ID | | target | string title: Alert target object: monitor availability-available metrics-app.metrics.field | | alertDefineId integer($int64) title: Alarm definition ID associated with the alarm | | priority | string($byte) title: Alarm level 0: high-emergency-critical alarm-red 1: medium-critical-critical alarm-orange 2: low-warning-warning alarm-yellow | | content | string title: The actual content of the alarm notification | | status | string($byte) title: Alarm status: 0-normal alarm (to be processed) 1-threshold triggered but not reached the number of alarms 2-recovered alarm 3-processed | | times | integer($int32) title: Alarm threshold trigger times | | firstTriggerTime | integer($int64) title: Alarm trigger time (timestamp in milliseconds) | | lastTriggerTime | integer($int64) title: Alarm trigger time (timestamp in milliseconds) | | nextEvalInterval | integer($int64) title: Alarm evaluation interval (milliseconds) | | tags | example: {key1:value1} | | gmtCreate | string($date-time) title: Record the latest creation time (timestamp in milliseconds) | | gmtUpdate | string($date-time) | WebHook callback did not take effect Please check whether there is any triggered alarm information in the alarm center. Please check whether the configured webhook callback address is correct. Other issues can be fed back through the communication group ISSUE!
Project: Grafana Mimir (Observability and Analysis / Observability)
File: BENCHMARK.md

Validating the Kubernetes Swagger API ``` goos: linux goarch: amd64 pkg: github.com/go-openapi/validate cpu: AMD Ryzen 7 5800X 8-Core Processor BenchmarkKubernetesSpec/validatingkubernetes_API-16 1 8549863982 ns/op 7067424936 B/op 59583275 allocs/op ``` ``` go test -bench Spec goos: linux goarch: amd64 pkg: github.com/go-openapi/validate cpu: AMD Ryzen 7 5800X 8-Core Processor BenchmarkKubernetesSpec/validatingkubernetes_API-16 1 4064535557 ns/op 3379715592 B/op 25320330 allocs/op ``` ``` goos: linux goarch: amd64 pkg: github.com/go-openapi/validate cpu: AMD Ryzen 7 5800X 8-Core Processor BenchmarkKubernetesSpec/validatingkubernetes_API-16 1 3758414145 ns/op 2593881496 B/op 17111373 allocs/op ```
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_vpa.KubeVPA.md

title: "Interface: KubeVPA" linkTitle: "KubeVPA" slug: "libk8svpa.KubeVPA" .KubeVPA `KubeVPA` `Optional` apiVersion: `string` . _ kind: `string` Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. In CamelCase. Cannot be updated. `see` . _ metadata: . _ spec: `VpaSpec` _ status: `VpaStatus`
Project: Grafana Mimir (Observability and Analysis / Observability)
File: v5.1.md

title: "Grafana Mimir Helm chart version 5.1 release notes" menuTitle: "V5.1 release notes" description: "Release notes for Grafana Mimir Helm chart version 5.1" weight: 300 Grafana Labs is excited to announce version 5.1 of the Grafana Mimir Helm chart, which is compatible with Grafana Mimir v2.10 or Grafana Enterprise Metrics (GEM) v2.10. The `mimir-distributed` Helm chart is the best way to install Mimir on Kubernetes. The highlights that follow include the top features, enhancements, and bugfixes in this release. For a comprehensive list of changes, see the . Deployments now set `maxUnavailable` to 0 and `maxSurge` to `15%` by default to avoid becoming unavailable during rollout. Please note that if you have set `maxSurge=0`, the upgrade will fail to execute with the following error ``` Invalid value: intstr.IntOrString{Type:0, IntVal:0, StrVal:""}: may not be 0 when `maxSurge` is 0 ``` and you have to adjust your values of `maxSurge` and `maxUnavailable`. Notable enhancements are as follows: Pod management policy is now configurable for store-gateways and compactors. Nginx now listens on IPv6 pod interface as well if available. Distributor and querier CPU utilization better in line with CPU request by using `GOMAXPROCS`. : Updated the Mimir and GEM images to 2.10.2. These include some bugfixes and update grpc-go library to 1.57.1 and golang.org/x/net to 0.17, which include fix for CVE-2023-44487. : Updated the Mimir and GEM images to 2.10.3. These include a fix to the previous release. Update grpc-go library to 1.57.2-dev that includes a fix for a bug introduced in 1.57.1. : Updated the Mimir and GEM images to 2.10.4. This updates otelhttp library to v0.44.0 as a mitigation for CVE-2023-45142. For GEM it also fixes memory leak in Admin client. : Updated the memcached-exporter dependency to version 0.14.1 which includes a fix for CVE-2023-39325.
Project: Grafana (Observability and Analysis / Observability)
File: configure-pyroscope-data-source.md

description: Configure your Pyroscope data source for Grafana. keywords: configure profiling pyroscope labels: products: cloud enterprise oss title: Configure the Grafana Pyroscope data source menuTitle: Configure Pyroscope weight: 200 To configure basic settings for the data source, complete the following steps: Click Connections in the left-side menu. Under Your connections, click Data sources. Enter `Grafana Pyroscope` in the search bar. Click Grafana Pyroscope to display the Settings tab of the data source. Set the data source's basic configuration options: | Name | Description | | -- | | | `Name` | A name to specify the data source in panels, queries, and Explore. | | `Default` | The default data source will be pre-selected for new panels. | | `URL` | The URL of the Grafana Pyroscope instance, for example, `http://localhost:4100`. | | `Basic Auth` | Enable basic authentication to the data source. | | `User` | User name for basic authentication. | | `Password` | Password for basic authentication. | | `Minimal step` | Used for queries returning timeseries data. The Pyroscope backend, similar to Prometheus, scrapes profiles at certain intervals. To prevent querying at smaller interval, use Minimal step same or higher than your Pyroscope scrape interval. This prevents returning too many data points to the frontend. | {{% docs/reference %}} {{% /docs/reference %}}
Project: Elastic (Observability and Analysis / Observability)
File: st_intersects.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Returns true if two geometries intersect. They intersect if they have any point in common, including their interior points (points along lines or within polygons). This is the inverse of the <<esql-stdisjoint,STDISJOINT>> function. In mathematical terms: ST_Intersects(A, B) A B ``` FROM airports | WHERE STINTERSECTS(location, TOGEOSHAPE("POLYGON((42 14, 43 14, 43 15, 42 15, 42 14))")) ```
Project: Botkube (Observability and Analysis / Observability)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thank you for your contribution. Before you submit the pull request: Follow contributing guidelines, templates, the recommended Git workflow, and any related documentation. Test your changes and attach their results to the pull request. Update the relevant documentation. --> Changes proposed in this pull request: ... <!-- Describe necessary steps to test the changes. You can refer to the existing documentation if some steps are already described. --> <!-- If you refer to a particular issue, provide its number. To close the issue after the pull request merge, use `Resolves #123` or `Fixes #123`. Otherwise, use `See also #123` or just `#123`. -->
Project: Graylog (Observability and Analysis / Observability)
File: ListGroupItem.md

```js import { ListGroup } from 'components/bootstrap'; <ListGroup> <ListGroupItem>Item 1</ListGroupItem> <ListGroupItem>Item 2</ListGroupItem> <ListGroupItem>Item 3</ListGroupItem> </ListGroup> ``` ```js import { ListGroup } from 'components/bootstrap'; <ListGroup> <ListGroupItem href="#">Link 1</ListGroupItem> <ListGroupItem href="#">Link 2</ListGroupItem> <ListGroupItem href="#">Link 3</ListGroupItem> </ListGroup> ``` ```js import { ListGroup } from 'components/bootstrap'; <ListGroup> <ListGroupItem href="#" active>Link 1</ListGroupItem> <ListGroupItem href="#">Link 2</ListGroupItem> <ListGroupItem href="#" disabled>Link 3</ListGroupItem> </ListGroup> ``` ```js import { ListGroup } from 'components/bootstrap'; const styles = ['Danger', 'Warning', 'Success', 'Info']; <ListGroup componentClass="ol"> {styles.map((style, i) => ( <ListGroupItem key={`lgi-${style}`} bsStyle={style.toLowerCase()} listItem>{i + 1}&#41; {style}</ListGroupItem> ))} </ListGroup> ``` ```js import { ListGroup } from 'components/bootstrap'; <ListGroup> <ListGroupItem header="Heading 1">Some body text</ListGroupItem> <ListGroupItem header="Heading 2" href="#"> Linked item </ListGroupItem> <ListGroupItem header="Heading 3" bsStyle="danger"> Danger styling </ListGroupItem> </ListGroup> ```
Project: Graylog (Observability and Analysis / Observability)
File: Fonts.md

Font settings are accessible from within `theme.fonts` object. ```jsx noeditor import React, { useEffect } from 'react'; import styled, { useTheme } from 'styled-components'; import ColorSwatch, { Swatch } from './Colors'; const { fonts } = useTheme(); const FontFamilies = () => ( <ul> {Object.entries(fonts.family).map(([fontId, fontNames]) => ( <li style={{ fontFamily: fontNames }} key={fontId}> <b>{fontId}</b>: {fontNames} </li> ))} </ul> ); <FontFamilies /> ``` ```jsx noeditor import React, { useEffect } from 'react'; import styled, { useTheme } from 'styled-components'; import ColorSwatch, { Swatch } from './Colors'; import { ROOTFONTSIZE } from 'theme/constants'; const { fonts } = useTheme(); const FontSizes = () => ( <ul> {Object.entries(fonts.size).map(([sizeId, sizeValue]) => ( <li style={{ fontSize: sizeValue }} key={sizeId}> <b>{sizeId}</b>: {sizeValue} {sizeId !== 'root' && <i> ({sizeValue.replace(/rem|em/i, '') * ROOTFONTSIZE}px)</i>} </li> ))} </ul> ); <FontSizes /> ``` The default line height works well for all text, no matter its size. Make sure to always rely on the default line height and do not define a custom line height for text. This way we can unify the font style across the application. Sometimes you may want to define a line height for an element like an icon to adjust its height. In case the element height should not be relative to the text size, make sure to define the line height in `px` and not in `rem` or without a unit. ```jsx noeditor import React, { useEffect } from 'react'; import styled, { useTheme } from 'styled-components'; import ColorSwatch, { Swatch } from './Colors'; const { fonts } = useTheme(); const FontLineHeights = () => ( <ul> {Object.entries(fonts.lineHeight).map(([lineHeightId, lineHeightValue]) => ( <li key={lineHeightId}><b>{lineHeightId}</b>: {lineHeightValue}</li> ))} </ul> ); <FontLineHeights /> ```