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

This alert presents the number of slow queries in the last 10 seconds. If you receive this, it indicates a high number of slow queries. The metric is raised in a warning state when the value is larger than 10. If the number of slow queries in the last 10 seconds exceeds 20, then the alert is raised in critical state. Queries are defined as "slow", if they have taken more than `longquerytime` seconds, a predefined variable. Also, the value is measured in real time, not CPU time. Determine which queries are the problem and try to optimise them To identify the slow queries, you can enable the slow-query log of MySQL: Locate the `my.cnf` file Enable the slow-query log by setting the `slowquerylog variable` to `On`. Enter a path where the log files should be stored in the `slowquerylog_file` variable. After you know which queries are the ones taking longer than preferred, you can use the `EXPLAIN` keyword to overview how many rows are accessed, what operations are being done etc. After you've found the cause for the slow queries, you can start optimizing your queries. Consider to use an index and think about how you can change the way you `JOIN` tables. Both of these methods aid to reduce the amount of data that is being accessed without it really being needed.
Project: Vector (Observability and Analysis / Observability)
File: unified.md

title: Unified Architecture description: Collect at the edge, and then aggregate, for maximum flexibility. weight: 3 The unified architecture deploys Vector an and . It combines the with the to create a unified observability pipeline. This is a powerful architecture that we recommend for Vector users that have already deployed the and want to bring Vector to their individual nodes. We recommend this architecture for Vector users that have already deployed the aggregator architecture. This is a natural evolution that hardens your observability pipeline by: Minimizing agent risk by taking over the responsibility of data delivery from your nodes. Improves performance by using Vectors native protocol via the `vector` source and sink. Allows you to shift stateless processing to the edge for natural scalability. Enables more sophisticated failover and disaster recovery strategies. For easy setup and maintenance of this architecture, consider the Vectors or . These are free best effort channels. For enterprise needs, consider Datadog Observability Pipelines, which comes with enterprise-level support. Read more about that .
Project: Grafana (Observability and Analysis / Observability)
File: apiserver.md

The example-apiserver closely resembles the project in code and thus allows the same as kube-apiserver. It is currently used for testing our deployment pipelines for aggregated servers. You can optionally omit the aggregation path altogether and just run this example apiserver as a standalone process. For setting `--grafana.authn.signing-keys-url`, Grafana must be run with `idForwarding = true` while also ensuring you have logged in to the instance at least once. ```shell go run ./pkg/cmd/grafana apiserver \ --runtime-config=example.grafana.app/v0alpha1=true \ --grafana-apiserver-dev-mode \ --grafana.authn.signing-keys-url="http://localhost:3000/api/signing-keys/keys" \ --verbosity 10 \ --secure-port 7443 ``` In dev mode, the standalone server's loopback kubeconfig is written to `./data/grafana-apiserver/apiserver.kubeconfig`. ```shell export KUBECONFIG=./data/grafana-apiserver/apiserver.kubeconfig kubectl api-resources NAME SHORTNAMES APIVERSION NAMESPACED KIND dummy example.grafana.app/v0alpha1 true DummyResource runtime example.grafana.app/v0alpha1 false RuntimeInfo ``` Logs, metrics and traces are supported. See `--grafana.log.`, `--grafana.metrics.` and `--grafana.tracing.*` flags for details. ```shell go run ./pkg/cmd/grafana apiserver \ --runtime-config=example.grafana.app/v0alpha1=true \ --help ``` For example, to enable debug logs, metrics and traces (using ) use the following: ```shell go run ./pkg/cmd/grafana apiserver \ --runtime-config=example.grafana.app/v0alpha1=true \ --secure-port=7443 \ --grafana.log.level=debug \ --verbosity=10 \ --grafana.metrics.enable \ --grafana.tracing.jaeger.address=http://localhost:14268/api/traces \ --grafana.tracing.sampler-param=1 ```
Project: HertzBeat (Observability and Analysis / Observability)
File: SECURITY.md

Use this section to tell people about which versions of your project are currently being supported with security updates. | Version | Supported | |-|--| | Latest Version | :whitecheckmark: | | Any Other Version | :x: | Use this section to tell people how to report a vulnerability. Please report vulnerability disclosures to `security@apache.org`.
Project: Netdata (Observability and Analysis / Observability)
File: 10s_received_packets_storm.md

This alert is triggered when there is a significant increase in the number of received packets within a 10-second interval. It indicates a potential packet storm, which may cause network congestion, dropped packets, and reduced performance. Check network utilization: Monitor network utilization on the affected interface to identify potential bottlenecks, high bandwidth usage, or network saturation. Identify the source: Determine the source of the increased packet rate. This may be caused by a misconfigured application, a faulty network device, or a Denial of Service (DoS) attack. Inspect network devices: Check network devices such as routers, switches, and firewalls for potential issues, misconfigurations, or firmware updates that may resolve the problem. Verify application behavior: Ensure that the applications running on your network are behaving as expected and not generating excessive traffic. Implement rate limiting: If the packet storm is caused by a specific application or service, consider implementing rate limiting to control the number of packets being sent. Monitor network security: Check for signs of a DoS attack or other security threats, and take appropriate action to mitigate the risk.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-1-0-beta2.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 8.1.0-beta2 <!-- Auto generated by update changelog github action --> Alerting: Expand the value string in alert annotations and labels. , Auth: Add Azure HTTP authentication middleware. , Auth: Auth: Pass user role when using the authentication proxy. , Gazetteer: Update countries.json file to allow for linking to 3-letter country codes. , Config: Fix Docker builds by correcting formatting in sample.ini. , Explore: Fix encoding of internal URLs. ,
Project: Vector (Observability and Analysis / Observability)
File: 2019-12-04-rename-datadog-sink-to-datadog_metrics.md

date: "2020-07-13" title: "The `datadog` sink has been renamed to `datadog_metrics`" description: "This ensures that naming is consistent for the upcoming `datadog_logs` sink" authors: ["binarylogic"] pr_numbers: [1314] release: "0.6.0" hideonrelease_notes: false badges: type: "breaking change" domains: ["sinks"] sinks: ["datadog_metrics"] The `datadog` sink has been renamed to `datadog_metrics` to make way for the upcoming `datadog_logs` sink. Make the following changes in your `vector.toml` file: ```diff title="vector.toml" [sinks.datadog] type = "datadog" type = "datadog_metrics" ``` That's it!
Project: Grafana Mimir (Observability and Analysis / Observability)
File: securing-alertmanager.md

aliases: ../../operators-guide/securing/securing-alertmanager/ ../../operators-guide/secure/securing-alertmanager/ description: Learn how to secure the Alertmanager. menuTitle: Securing Alertmanager title: Securing Grafana Mimir Alertmanager weight: 40 By default, the Alertmanager exposes API endpoints that enable a user to configure the Alertmanager. The Alertmanager configuration includes receivers that create network connections to send the alerting notifications. For example, the `webhook` receiver enables a user to configure an arbitrary URL to which the Alertmanager sends a customizable request for every alerting notification. If the Alertmanager network security is not hardened, Grafana Mimir users might configure the Alertmanager to issue requests to any network address both in the local network and the Internet. We recommend hardening the network on which the Alertmanager runs. Although hardening the network is out of the scope for Grafana Mimir, Grafana Mimir provides a basic built-in firewall that blocks connections created by Alertmanager receivers: To block specific network addresses in Alertmanager receivers, set `-alertmanager.receivers-firewall-block-cidr-networks` to a comma-separated list of network CIDRs to block. To block private and local addresses in Alertmanager receivers, set `-alertmanager.receivers-firewall-block-private-addresses=true`. You can override the Alertmanager built-in firewall settings on a per-tenant basis in the overrides section of the . {{< admonition type="note" >}} You can disable the Alertmanager configuration API by setting `-alertmanager.enable-api=false`. {{< /admonition >}}
Project: Elastic (Observability and Analysis / Observability)
File: mv_count.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Converts a multivalued expression into a single valued column containing a count of the number of values. ``` ROW a=["foo", "zoo", "bar"] | EVAL counta = MVCOUNT(a) ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16329.md

key | value | date | 2024-01-24T09:23:40+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes mk_redis used to expose the password in the process name because of the '-a' argument. This has been fixed using the environment variable REDISCLI_AUTH.
Project: Krkn (Observability and Analysis / Chaos Engineering)
File: cpu_hog.md

This scenario is based on the arcaflow plugin. The purpose of this scenario is to create cpu pressure on a particular node of the Kubernetes/OpenShift cluster for a time span. To enable this plugin add the pointer to the scenario input file `scenarios/arcaflow/cpu-hog/input.yaml` as described in the Usage section. This scenario takes a list of objects named `input_list` with the following properties: kubeconfig : string the kubeconfig needed by the deployer to deploy the sysbench plugin in the target cluster namespace : string the namespace where the scenario container will be deployed Note: this parameter will be automatically filled by kraken if the `kubeconfig_path` property is correctly set node_selector : key-value map the node label that will be used as `nodeSelector` by the pod to target a specific cluster node duration : string stop stress test after N seconds. One can also specify the units of time in seconds, minutes, hours, days or years with the suffix s, m, h, d or y. cpu_count : int the number of CPU cores to be used (0 means all) cpu_method : string a fine-grained control of which cpu stressors to use (ackermann, cfloat etc. see for all the cpu_method options) cpu_load_percentage : int the CPU load by percentage To perform several load tests in the same run simultaneously (eg. stress two or more nodes in the same run) add another item to the `inputlist` with the same properties (and eventually different values eg. different nodeselectors to schedule the pod on different nodes). To reduce (or increase) the parallelism change the value `parallelism` in `workload.yaml` file
Project: Kepler (Observability and Analysis / Observability)
File: ginkgov2.md

title: upgarde to ginkgo v2 authors: Sam Yuan reviewers: n/A approvers: n/A creation-date: 2022-11-02 last-updated: 2022-11-02 tracking-links: # link to related GitHub issues Upgrade test framework ginkgo to v2 version, so that able to use to see test coverage in visual way. Same as Summary update go mod to ginkgo v2 update go vendor update test codes document as sample pass CI Test coverage up to 50% after this change, we are able to Click at left side bar to run all test case at local. For any package, open a file click run package tests. Find test coverage in visual way, green for covered, red for not. n/A
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-9-0-4.md

aliases: [] hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 9.0.4 <!-- Auto generated by update changelog github action --> Browse/Search: Make browser back work properly when visiting Browse or search. , Logs: Improve getLogRowContext API. , Loki: Improve handling of empty responses. , Plugins: Always validate root URL if specified in signature manifest. , Preferences: Get home dashboard from teams. , SQLStore: Support Upserting multiple rows. , Traces: Add more template variables in Tempo & Zipkin. , Traces: Remove serviceMap feature flag. , Access Control: Fix missing folder permissions. , Access control: Fix org user removal for OSS users. , Alerting: Fix Slack notification preview. , Alerting: Fix Slack push notifications. , Alerting: Fixes slack push notifications. , Alerting: Preserve new-lines from custom email templates in rendered email. , Insights: Fix dashboard and data source insights pages. (Enterprise) Log: Fix text logging for unsupported types. , Loki: Fix `show context` not working in some occasions. , Loki: Fix incorrect TopK value type in query builder. ,
Project: Checkmk (Observability and Analysis / Observability)
File: 16238.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-02-27T12:50:29+00:00 level | 1 class | feature component | checks edition | cre You're affected if your awsec2limits check reported "Unknown resource" and you're using "m7i.large". The aws resource names are changing from time to time and we will need to find a more stable solution for that in the future. But for now, this will be fixed by adding the resource name "m7i.large" to our internal list of aws resources.
Project: Netdata (Observability and Analysis / Observability)
File: page_types.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/integrations/page_types.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/metadata.yaml" sidebar_label: "Page types" learn_status: "Published" learnrelpath: "Collecting Metrics/Linux Systems/Memory" 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/microchip.svg" width="150"/> Plugin: proc.plugin Module: /proc/pagetypeinfo <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> This integration provides metrics about the system's memory page types This collector is supported on all platforms. 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 | |:|:-|:-| | mem.pagetype_global | a dimension per pagesize | B | Labels: | Label | Description | |:--|:-| | node_id | TBD | | node_zone | TBD | | node_type | TBD | Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | mem.pagetype | a dimension per pagesize | B | 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: Krkn (Observability and Analysis / Chaos Engineering)
File: config.md

Set the scenarios to inject and the tunings like duration to wait between each scenario in the config file located at . NOTE: can be used if leveraging the to install the infrastructure pieces. Config components: This section defines scenarios and specific data to the chaos run Either openshift or kubernetes depending on the type of cluster you want to run chaos on. The prometheus url/route and bearer token are automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes. exit_on_failure: Exit when a post action check or cerberus run fails publish_kraken_status: Can be accessed at http://0.0.0.0:8081 (or what signal_address and port you set in signal address section) signal_state: State you want kraken to start at; will wait for the RUN signal to start running a chaos iteration. When set to PAUSE before running the scenarios, refer to for more details signal_address: Address to listen/post the signal state to port: port to listen/post the signal state to chaos_scenarios: List of different types of chaos scenarios you want to run with paths to their specific yaml file configurations If a scenario has a post action check script, it will be run before and after each scenario to validate the component under test starts and ends at the same state Currently the scenarios are run one after another (in sequence) and will exit if one of the scenarios fail, without moving onto the next one Chaos scenario types: container_scenarios plugin_scenarios node_scenarios time_scenarios clustershutdown_scenarios namespace_scenarios zone_outages application_outages pvc_scenarios network_chaos Parameters to set for enabling of cerberus checks at the end of each executed scenario. The given url will pinged after the scenario and post action check have been completed for each scenario and iteration. cerberus_enabled: Enable it when cerberus is previously installed cerberus_url: When cerberus_enabled is set to True, provide the url where cerberus publishes go/no-go signal check_applicaton_routes: When enabled will look for application unavailability using the routes specified in the cerberus config and fails the run There are 2 main sections defined in this part of the config and ; read more about each of these configurations in their respective docs wait_duration: Duration to wait between each chaos scenario iterations: Number of times to execute the scenarios daemon_mode: True or False; If true, iterations are set to infinity which means that the kraken will cause chaos forever and number of iterations is ignored
Project: Tracetest (Observability and Analysis / Observability)
File: tracetest_version.md

Display this CLI tool version Display this CLI tool version ``` tracetest version [flags] ``` ``` -h, --help help for version ``` ``` -c, --config string config file will be used by the CLI (default "config.yml") -o, --output string output format [pretty|json|yaml] -s, --server-url string server url -v, --verbose display debug information ``` - CLI to configure, install and execute tests on a Tracetest server
Project: Checkmk (Observability and Analysis / Observability)
File: 16378.md

key | value | date | 2024-02-20T21:25:44+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes The Checkmk agents for Linux, Solaris, AIX, OpenWrt and FreeBSD now ignore \*.dpkg-tmp files in the plugins folder. They previously executed them inadvertedly as plugins. This mostly fails silently (or even succeedes), but sometimes it is reported by the "Check_MK Agent" service.
Project: Vector (Observability and Analysis / Observability)
File: 2023-07-05-0-31-0-upgrade-guide.md

date: "2023-07-05" title: "0.31 Upgrade Guide" description: "An upgrade guide that addresses breaking changes in 0.31.0" authors: ["stephenwakely", "tobz"] release: "0.31.0" hideonrelease_notes: false badges: type: breaking change Vector's 0.31.0 release includes breaking changes: and potentially impactful changes: We cover them below to help you upgrade quickly: Over the course of many of the previous releases, we've been working to deprecate the usage of older internal metrics as we worked towards implementing full support for the [Component Specification][component_spec], which dictates the basic metrics that all components, or the basic metrics all components of a specific type, are expected to emit. We've made enough progress on this work that we've gone ahead and removed many of the deprecated metrics from this release. First, below is a list of all metrics we've removed: `eventsintotal` (superceded by `componentreceivedevents_total`) `eventsouttotal` (superceded by `componentsentevents_total`) `processedbytestotal` (superceded by either `componentreceivedbytes_total` or `componentsentbytes_total`, more below) `processedeventstotal` (superceded by either `componentreceivedevents_total` or `componentsentevents_total`, more below) `processingerrorstotal` (superceded by `componenterrorstotal`) `eventsfailedtotal` (superceded by `componenterrorstotal`) Most of the removals have straightforward replacements, but the `processed_`-prefixed metrics involve a small amount of logic. For sources, `processedbytestotal` is superceded by `componentreceivedbytestotal`, and `processedevents_total` is superceded by `componentreceivedeventstotal`. For **sinks**, `processedbytes_total` is superceded by `componentsentbytestotal`, and `processedevents_total` is superceded by `componentsentevents_total`. A small note is that a small number of components still emit some of these metrics, as they provided additional tags and information that is disallowed by the Component Specification. They will be removed in a future version once we can rectify those discrepancies, but they are effectively removed as of this release: you cannot depend on them still existing. Prior to this Version, metrics emitted by Vector were inconsistently measuring the byte size of the events that were being sent and received. These metrics have been updated for all components so they always emit an estimate of the size of the event should it be serialized to JSON. Measuring the events like this allows a consistent measurement to be applied across all components regardless of how the source or sink serializes the event when connecting to the external service. The handling of AWS S3 endpoints for the `aws_s3` source and sink has changed due to an upgrade of the SDK that we use. For S3-compatible APIs like Cloudflare R2 you may find that you need to remove the bucket name from the endpoint, if you have it specified. For example `https://xxxxxxxxxxxxxxxxxxxxxxxxxxx.r2.cloudflarestorage.com/<bucket name>` should be written as `https://xxxxxxxxxxxxxxxxxxxxxxxxxxx.r2.cloudflarestorage.com`.
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: process-collector.md

title: Gadget process-collector The process-collector gadget gathers information about running processes ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: process-collector namespace: gadget spec: node: minikube gadget: process-collector filter: namespace: default labels: role: demo runMode: Manual outputMode: Status ``` Create a snapshot of the currently running processes. Once taken, the snapshot is not updated automatically. However one can call the collect operation again at any time to update the snapshot. ```bash $ kubectl annotate -n gadget trace/process-collector \ gadget.kinvolk.io/operation=collect ``` Status