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

id: greptime-init title: Use Time Series Database GreptimeDB to Store Metrics Data (Optional) sidebar_label: Use GreptimeDB Store Metrics HertzBeat's historical data storage relies on the time series database, you can choose one of them to install and initialize, or not to install (note but it is strongly recommended to configure in the production environment) We recommend VictoriaMetrics for long term support. GreptimeDB is an open-source time-series database with a special focus on scalability, analytical capabilities and efficiency. It's designed to work on infrastructure of the cloud era, and users benefit from its elasticity and commodity storage. If you do not configure a time series database, only the last hour of historical data is retained. Refer to the official website Download and install Docker environment Docker tools download refer to . After the installation you can check if the Docker version normally output at the terminal. ``` $ docker -v Docker version 20.10.12, build e91ed57 ``` Install GreptimeDB with Docker ```shell $ docker run -p 4000-4004:4000-4004 \ -p 4242:4242 -v /opt/greptimedb:/tmp/greptimedb \ --name greptime \ greptime/greptimedb standalone start \ --http-addr 0.0.0.0:4000 \ --rpc-addr 0.0.0.0:4001 \ ``` `-v /opt/greptimedb:/tmp/greptimedb` is local persistent mount of greptimedb data directory. `/opt/greptimedb` should be replaced with the actual local directory. use```$ docker ps``` to check if the database started successfully Configure HertzBeat's configuration file Modify `hertzbeat/config/application.yml` configuration file NoteThe docker container way need to mount application.yml file locally, while you can use installation package way to unzip and modify `hertzbeat/config/application.yml` Replace `warehouse.store.greptime` data source parameters, URL account and password. ```yaml warehouse: store: jpa: enabled: false greptime: enabled: true endpoint: localhost:4001 ``` Restart HertzBeat Do both the time series databases Greptime, IoTDB or TDengine need to be configured? Can they both be used? You don't need to configure all of them, you can choose one of them. Use the enable parameter to control whether it is used or not. You can also install and configure neither, which only affects the historical chart data.
Project: Netdata (Observability and Analysis / Observability)
File: 1min_netdev_budget_ran_outs.md

Your system communicates with the devices attached to it through interrupt requests. In a nutshell, when an interrupt occurs, the operating system stops what it was doing and starts addressing that interrupt. Network interfaces can receive thousands of packets per second. To avoid burying the system with thousands of interrupts, the Linux kernel uses the NAPI polling framework. In this way, we can replace hundreds of hardware interrupts with one poll by managing them with a few Soft Interrupt ReQuests (Soft IRQs). Ksoftirqd is a per-CPU kernel thread responsible for handling those unserved Soft Interrupt ReQuests (Soft IRQs). The Netdata agent inspects the average number of times Ksoftirqd ran out of netdev_budget or CPU time when there was still work to be done. This abnormality may cause packet overflow on the intermediate buffers and, as a result, drop packet on your network interfaces. The default value of the netdev_budget is 300. However, this may not be enough in some cases, such as: Multiple interfaces operating at 1Gbps, or even a single interface at 10Gbps. Lower powered systems processing very large amounts of network traffic. The design of NAPI allows the network driver to go into a polling mode, buffering the packets it receives into a ring-buffer, and raises a soft interrupt to start a NAPI polling cycle instead of being hard-interrupted for every packet. Linux kernel through NAPI will poll data from the buffer until the netdevbudgetusecs times out or the number of packets reaches the netdev_budget limit. netdevbudgetusecs variable defines the maximum number of microseconds in one NAPI polling cycle. netdev_budget variable defines the maximum number of packets taken from all interfaces in one polling cycle. Increase the netdev_budget value. Check your current value. ``` root@netdata~ $ sysctl net.core.netdev_budget net.core.netdev_budget = 300 ``` Try to increase it gradually with increments of 100. ``` root@netdata~ $ sysctl -w net.core.netdev_budget=400 ``` Verify the change and test it with the same workload that triggered the alarm originally. If the problem still exists, try to increment it again. ``` root@netdata~ $ sysctl net.core.netdev_budget net.core.netdev_budget = 400 ``` If this change works for your system, you could make it permanently. Bump this `net.core.netdevbudget=<desiredvalue>` entry under `/etc/sysctl.conf` Reload the sysctl settings. ``` root@netdata~ $ sysctl -p ```
Project: Grafana Loki (Observability and Analysis / Observability)
File: blocking-queries.md

title: Blocking Queries menuTitle: description: Describes how to configure Loki to block expensive queries using per-tenant overrides. weight: In certain situations, you may not be able to control the queries being sent to your Loki installation. These queries may be intentionally or unintentionally expensive to run, and they may affect the overall stability or cost of running your service. You can block queries using , like so: ```yaml overrides: "tenant-id": blocked_queries: pattern: 'sum(rate({env="prod"}[1m]))' pattern: '.prod.' regex: true types: metric pattern: '.prod.' regex: true types: filter,limited hash: 2943214005 # hash of {stream="stdout",pod="loki-canary-9w49x"} types: filter,limited ``` {{% admonition type="note" %}} Changes to these configurations do not require a restart; they are defined in the . {{% /admonition %}} The available query types are: `metric`: a query with an aggregation, e.g. `sum(rate({env="prod"}[1m]))` `filter`: a query with a log filter, e.g. `{env="prod"} |= "error"` `limited`: a query without a filter or a metric aggregation The `hash` option uses a hash of the query string, represented as a 32-bit unsigned integer. This can often be easier to use than query strings that are long or require lots of string escaping. A `query_hash` field is logged with every query request in the `query-frontend` and `querier` logs, for easy reference. Here's an example log line: ```logfmt level=info ts=2023-03-30T09:08:15.2614555Z caller=metrics.go:152 component=frontend org_id=29 latency=fast query="{stream=\"stdout\",pod=\"loki-canary-9w49x\"}" queryhash=2943214005 querytype=limited range_type=range ... ``` {{% admonition type="note" %}} The order of patterns is preserved, so the first matching pattern will be used. {{% /admonition %}} Blocked queries are logged, as well as counted in the `lokiblockedqueries` metric on a per-tenant basis. Queries received via the API and executed as will be blocked.
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: monitoring.md

sort: 6 weight: 6 title: Monitoring menu: docs: parent: "operator" weight: 6 aliases: /operator/monitoring.html VictoriaMetrics operator exports internal metrics in Prometheus exposition format at `/metrics` page. These metrics can be scraped via or Prometheus. Official Grafana dashboard available for . <img src="monitoring_operator-dashboard.png" width=1200> Graphs on the dashboards contain useful hints - hover the `i` icon in the top left corner of each graph to read it. Alerting rules for VictoriaMetrics operator are available . In helm-chart operator self-scrapes metrics by default. This helm-chart also includes and . With you can use following parameter in `values.yaml`: ```yaml serviceMonitor: enabled: true ``` This parameter makes helm-chart to create a scrape-object for installed operator instance. You will also need to deploy a (vmsingle)[./resources/vmsingle.md] where the metrics will be collected. With pure operator installation you can use config with separate vmsingle and scrape object for operator like that: ```yaml apiVersion: operator.victoriametrics.com/v1beta1 kind: VMServiceScrape metadata: name: vmoperator namespace: monitoring spec: selector: matchLabels: app.kubernetes.io/instance: vm-operator app.kubernetes.io/name: victoria-metrics-operator endpoints: port: http namespaceSelector: matchNames: monitoring ``` See more info about object . You will also need a where the metrics will be collected.
Project: Fluentd (Observability and Analysis / Observability)
File: CONTRIBUTING.md

We'd love your contribution. Here are the guidelines! RESOURCES of and may help you. If you have further questions about Fluentd and plugins, please direct these to . Don't use Github issue for asking questions. Here are examples: I installed xxx plugin but it doesn't work. Why? Fluentd starts but logs are not sent to xxx. Am I wrong? I want to do xxx. How to realize it with plugins? We may close such questions to keep clear repository for developers and users. Github issue is mainly for submitting a bug report or feature request. See below. If you can't judge your case is a bug or not, use community forum or slack first. If you find a bug of Fluentd or a mistake in the documentation, you can help us by submitting an issue to Fluentd. Even better you can submit a Pull Request with a fix. Fluentd*: Use repository. Fill issue template. Documentation*: Use repository. If you find a bug of 3rd party plugins, please submit an issue to each plugin repository. And use repository for td-agent related issues. Note: Before report the issue, check latest version first. Sometimes users report fixed bug with older version. Here are some things that would increase a chance that your patch is accepted: Write tests. Run tests before send Pull Request by `bundle exec rake test` Write a . Fluentd repositories needs on PR. Please add `Signed-off-by` to the commit(See DCO link for more detail). There are some patches which are hard to write tests, e.g. process handling, concurrency issue or etc. In such case, please don't hesitate to submit a Pull Request. We can discuss how to manage a patch on Pull Request :)
Project: Grafana Mimir (Observability and Analysis / Observability)
File: memberlist-and-the-gossip-protocol.md

aliases: ../../operators-guide/architecture/memberlist-and-the-gossip-protocol/ description: Memberlist manages Grafana Mimir cluster membership and node detection failure. menuTitle: Memberlist and gossip protocol title: Grafana Mimir memberlist and gossip protocol weight: 80 is a Go library that manages cluster membership, node failure detection, and message passing using a gossip-based protocol. Memberlist is eventually consistent and network partitions are partially tolerated by attempting to communicate to potentially dead nodes through multiple routes. By default, Grafana Mimir uses memberlist to implement a to share the data structures between instances. When using a memberlist-based KV store, each instance maintains a copy of the hash rings. Each Mimir instance updates a hash ring locally and uses memberlist to propagate the changes to other instances. Updates generated locally and updates received from other instances are merged together to form the current state of the ring on the instance. To configure memberlist, refer to . When using a memberlist-based KV store, every Grafana Mimir instance propagates the hash ring data structures to other instances using the following techniques: Propagating only the differences introduced in recent changes. Propagating the full hash ring data structure. Every `-memberlist.gossip-interval` an instance randomly selects a subset of all Grafana Mimir cluster instances configured by `-memberlist.gossip-nodes` and sends the latest changes to the selected instances. This operation is performed frequently and it's the primary technique used to propagate changes. In addition, every `-memberlist.pullpush-interval` an instance randomly selects another instance in the Grafana Mimir cluster and transfers the full content of the KV store, including all hash rings (unless `-memberlist.pullpush-interval` is zero, which disables this behavior). After this operation is complete, the two instances have the same content as the KV store. This operation is computationally more expensive, and as a result, it's performed less frequently. The operation ensures that the hash rings periodically reconcile to a common state.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_persistentVolumeClaim.KubePersistentVolumeClaim.md

title: "Interface: KubePersistentVolumeClaim" linkTitle: "KubePersistentVolumeClaim" slug: "libk8spersistentVolumeClaim.KubePersistentVolumeClaim" .KubePersistentVolumeClaim `KubePersistentVolumeClaim` `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: . _ `Optional` spec: `Object` | Name | Type | | : | : | | `accessModes?` | `string`[] | | `resources?` | { `limits?`: `object` ; `requests`: { `[other: string]`: `any`; `storage?`: `string` } } | | `resources.limits?` | `object` | | `resources.requests` | { `[other: string]`: `any`; `storage?`: `string` } | | `resources.requests.storage?` | `string` | | `storageClassName?` | `string` | | `volumeMode?` | `string` | | `volumeName?` | `string` | _ `Optional` status: `Object` | Name | Type | | : | : | | `accessModes?` | `string`[] | | `capacity?` | { `storage?`: `string` } | | `capacity.storage?` | `string` | | `phase?` | `string` |
Project: HertzBeat (Observability and Analysis / Observability)
File: api.md

id: api title: Monitoring HTTP API sidebar_label: HTTP API keywords: [open source monitoring tool, monitoring http api] Call HTTP API interface, check whether the interface is available, and monitor its response time and other Metrics. | Parameter name | Parameter help description | | -- | -- | | Monitoring Host | Monitored IPV4, IPV6 or domain name. NoteWithout protocol header (eg: https://, http://) | | Monitoring name | Identify the name of this monitoring. The name needs to be unique | | Port | Ports provided by website, http generally defaults to 80 and https generally defaults to 443 | | Relative path | Suffix path of website address except IP port. For example, the relative path of `www.tancloud.cn/console` website is `/console` | | Request mode | Set the request mode of interface callGET, POST, PUT, DELETE | | Enable HTTPS | Whether to access the website through HTTPS. NoteWhen HTTPS is enabled, the default corresponding port needs to be changed to 443 | | Username | User name used for interface Basic authentication or Digest authentication | | Password | Password used for interface Basic authentication or Digest authentication | | Content-Type | Set the resource type when carrying the BODY request body data request | | Request BODY | Set the carry BODY request body data, which is valid when PUT or POST request method is used | | Collection interval | Interval time of monitor periodic data collection, unit: second, and the minimum interval that can be set is 30 seconds | | Whether to detect | Whether to detect and check the availability of monitoring before adding monitoring. Adding and modifying operations will continue only after the detection is successful | | Description remarks | For more information about identifying and describing this monitoring, users can note information here | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | responseTime | ms | Website response time |
Project: Netdata (Observability and Analysis / Observability)
File: system_uptime.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/integrations/system_uptime.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/metadata.yaml" sidebar_label: "System Uptime" learn_status: "Published" learnrelpath: "Collecting Metrics/Linux Systems/System" 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/linuxserver.svg" width="150"/> Plugin: proc.plugin Module: /proc/uptime <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> The amount of time the system has been up (running). Uptime is a critical aspect of overall system performance: Availability: Uptime monitoring can show whether a server is consistently available or experiences frequent downtimes. Performance Monitoring: While server uptime alone doesn't provide detailed performance data, analyzing the duration and frequency of downtimes can help identify patterns or trends. Proactive problem detection: If server uptime monitoring reveals unexpected downtimes or a decreasing uptime trend, it can serve as an early warning sign of potential problems. Root cause analysis: When investigating server downtime, the uptime metric alone may not provide enough information to pinpoint the exact cause. Load balancing: Uptime data can indirectly indicate load balancing issues if certain servers have significantly lower uptimes than others. Optimize maintenance efforts: Servers with consistently low uptimes or frequent downtimes may require more attention. Compliance requirements: Server uptime data can be used to demonstrate compliance with regulatory requirements or SLAs that mandate a minimum level of server availability. This collector is only supported on the following platforms: linux This collector only supports collecting metrics from a single instance of this integration. 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. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | system.uptime | uptime | seconds | There are no alerts configured by default for this integration. No action required. There is no configuration file. There are no configuration options. There are no configuration examples.
Project: Vector (Observability and Analysis / Observability)
File: 2020-04-17-new-sinks.md

date: "2020-04-17" title: "4 New Sinks!" description: "Papertrail, Honeycomb, Pulsar, and DataDog Logs" authors: ["binarylogic"] pr_numbers: [1835, 1847, 1665, 1832] release: "0.9.0" hideonrelease_notes: false badges: type: "new feature" domains: ["sinks"] We all love a good sink. Now you can enjoy our latest offerings: Expanding support is a fundamental requirement we're aiming to achieve before hitting .
Project: Checkmk (Observability and Analysis / Observability)
File: 15297.md

key | value | compatible | no version | 2.3.0b1 date | 2023-10-24T08:48:21+00:00 level | 1 class | fix component | agents edition | cre Changes made in <a href="https://checkmk.com/werk/14839">Werk #14839</a> where only applied to the linux agent plugin of mk_oracle. Now those changes are also applied to mk_oracle.ps1
Project: SkyWalking (Observability and Analysis / Observability)
File: backend-ip-port.md

The backend uses IP and port binding in order to allow the OS to have multiple IPs. The binding/listening IP and port are specified by the core module ```yaml core: default: restHost: 0.0.0.0 restPort: 12800 restContextPath: / gRPCHost: 0.0.0.0 gRPCPort: 11800 ``` There are two IP/port pairs for gRPC and HTTP REST services. Most agents and probes use gRPC service for better performance and code readability. Some agents use REST service because gRPC may not be supported in that language. The UI uses REST service, but the data is always in GraphQL format. For users unfamiliar with IP binding, note that once IP binding is complete, the client could only use this IP to access the service. For example, if `172.09.13.28` is bound, even if you are in this machine, you must use `172.09.13.28`, rather than `127.0.0.1` or `localhost`, to access the service. The IP and port in the core module are provided by default. But it is common for some module providers, such as receiver modules, to provide other IP and port settings.
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-1.3.9.md

Upgrade Netty to 4.1.90.Final ( Upgrade `Jackson` from 2.14.1 to 2.14.2 () Add support for ppc64le architecture () Upgrade `snakeyaml` from 1.33 to 2.0 () OpenJDK Update (January 2023 Patch releases) () Upgrade `joda` from 2.10.13 to 2.12.2 ()
Project: Teletrace (Observability and Analysis / Observability)
File: README.md

Here you will find the source code and configurations for Teletrace's documentation, the docs site is generated using . To run the docs side locally, first make sure you have python 3 installed, then from the `website` directory: ```bash python -m venv venv source venv/bin/activate pip install -r requirements.txt mkdocs serve ``` Open <http://localhost:8000> in your browser.
Project: Opstrace (Observability and Analysis / Observability)
File: roadmap.md

<!-- markdownlint-disable MD036 --> The Opstrace Distribution provides a foundation that solves many that people have today. But we know there is still a lot more to do to have a complete observability distribution that is more than just private, secure and cost-effective. This high-level roadmap highlights features along our path toward that goal. Synthetic Monitoring Reliably receive alerts if some part of your product is not available in some part of the world. Total cost of ownership detailed in the UI Opstrace will show how much it costs to store metrics and logs inside of the product. No more spreadsheets and guessing but instead actionable information that is automatically kept up to date. Tracing Tracing suffers similar problems to logs and metricsit's expensive to operate and even more difficult to set up. Not to mention the wide-ranging privacy concerns with sending any of your data out to a 3rd party provider. And if you're using existing open source tools to run it in your own account, it's even harder to do, with more ongoing maintenance burden. Despite all this, we will provide distributed tracing as a deliberate feature, making it just as easy, secure, and private as logs and metrics. Additional Integrations We will prioritize additional integrations based on the needs of our users, so let us know in GitHub or the community Slack what you're interested in. Azure Support We do plan on building an Azure version. That is why we started with two clouds (AWS and GCP) since we believe it's easier to got from 2 to `n` instead of 1 to `n`. As for timelines for azure we don't have any yet; it depends on how many requests we get for it and who is willing to help. We welcome you to join our and ask us questions, make proposals, and/or just chat about what we're doing.