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

This alert, `anomaliesanomalyprobabilities`, is generated by the Netdata agent when the average anomaly probability over the last 2 minutes is 50. An anomaly probability is a value calculated by the machine learning (ML) component in Netdata, aiming to detect unusual events or behavior in system metrics. Anomaly probability is a percentage calculated by the Netdata's ML feature that represents the probability of an observed metric value being considered an anomaly. A higher anomaly probability indicates a higher chance that the system behavior is deviating from its historical patterns or expected behavior. An average anomaly probability of 50 indicates that there might be some unusual events, metrics, or behavior in your monitored system. This might not necessarily indicate an issue, but rather, it raises suspicious deviations in the system metrics that are worth investigating. Investigate the unusual events or behavior The first step is to identify the metric(s) or series of metric values that are causing the alert. Look for changes in the monitored metrics or a combination of metrics that deviate significantly from their historical patterns. Check system performance and resource usage Use the overview and anomalies tab to explore the metrics that could be contributing to anomalies. Inspect system logs System logs can provide valuable information about unusual events or behaviors. Check system logs using tools like `journalctl`, `dmesg`, or `tail` for any error messages, warnings, or critical events that might be related to the anomaly. Review the alert settings In some cases, the alert may be caused by overly strict or sensitive settings, leading to the triggering of false positives. Review the settings and consider adjusting the anomaly probability threshold, if necessary.
Project: M3 (Observability and Analysis / Observability)
File: quickstart-http-steps.md

You can use the {{% apiendpoint %}}json/write endpoint to write a tagged metric to M3 with the following data in the request body, all fields are required: `tags`: An object of at least one `name`/`value` pairs `timestamp`: The UNIX timestamp for the data `value`: The float64 value for the data {{% notice tip %}} The examples below use `name` as the name for one of the tags, which is a Prometheus reserved tag that allows you to query metrics using the value of the tag to filter results. {{% /notice %}} {{% notice tip %}} Label names may contain ASCII letters, numbers, underscores, and Unicode characters. They must match the regex `. {{% /notice %}} {{< tabs name="write_metrics" >}} {{< tab name="Command 1" >}} {{< codeinclude file="docs/includes/write-metrics-1.sh" language="shell" >}} {{< /tab >}} {{< tab name="Command 2" >}} {{< codeinclude file="docs/includes/write-metrics-2.sh" language="shell" >}} {{< /tab >}} {{< tab name="Command 3" >}} {{< codeinclude file="docs/includes/write-metrics-3.sh" language="shell" >}} {{< /tab >}} {{< /tabs >}}
Project: Grafana (Observability and Analysis / Observability)
File: upgrading-go-version.md

Notes on upgrading Go version. Example PR: https://github.com/grafana/grafana/pull/79329 Then, run `go mod tidy` and `go work sync`. Also run `make drone` so changes to `.star` files are reflected and `drone.yml` is updated. Take a look in `.github/workflows` folder for what `go` version is being used there in various workflows. Make sure to create a PR with the corresponding changes in `grafana/grafana-enterprise` repository.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: LICENSE.md

Copyright (C) 2014 by Oleku Konko Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: fsslower.md

title: Gadget fsslower fsslower shows open, read, write and fsync operations slower than a threshold The following parameters are supported: filesystem: Which filesystem to trace [btrfs, ext4, nfs, xfs] minlatency: Min latency to trace, in ms. (default 10) ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: fsslower namespace: gadget spec: node: ubuntu-hirsute gadget: fsslower runMode: Manual outputMode: Stream filter: namespace: default ``` Start fsslower gadget ```bash $ kubectl annotate -n gadget trace/fsslower \ gadget.kinvolk.io/operation=start ``` Stop fsslower gadget ```bash $ kubectl annotate -n gadget trace/fsslower \ gadget.kinvolk.io/operation=stop ``` Stream
Project: Krkn (Observability and Analysis / Chaos Engineering)
File: managedcluster_scenarios.md

scenarios provide a way to integrate kraken with and . ManagedCluster scenarios leverage to inject faults into the ManagedClusters. The following ManagedCluster chaos scenarios are supported: managedcluster_start_scenario: Scenario to start the ManagedCluster instance. managedcluster_stop_scenario: Scenario to stop the ManagedCluster instance. managedcluster_stop_start_scenario: Scenario to stop and then start the ManagedCluster instance. start_klusterlet_scenario: Scenario to start the klusterlet of the ManagedCluster instance. stop_klusterlet_scenario: Scenario to stop the klusterlet of the ManagedCluster instance. stop_start_klusterlet_scenario: Scenario to stop and start the klusterlet of the ManagedCluster instance. ManagedCluster scenarios can be injected by placing the ManagedCluster scenarios config files under `managedcluster_scenarios` option in the Kraken config. Refer to config file. ``` managedcluster_scenarios: actions: # ManagedCluster chaos scenarios to be injected managedclusterstopstart_scenario managedcluster_name: cluster1 # ManagedCluster on which scenario has to be injected; can set multiple names separated by comma instance_count: 1 # Number of managedcluster to perform action/select that match the label selector runs: 1 # Number of times to inject each scenario under actions (will perform on same ManagedCluster each time) timeout: 420 # Duration to wait for completion of ManagedCluster scenario injection actions: stopstartklusterlet_scenario managedcluster_name: cluster1 instance_count: 1 runs: 1 timeout: 60 ```
Project: Elastic (Observability and Analysis / Observability)
File: to_cartesianshape.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Converts an input value to a `cartesian_shape` value. A string will only be successfully converted if it respects WKT format. ``` ROW wkt = ["POINT(4297.11 -1475.53)", "POLYGON ((3339584.72 1118889.97, 4452779.63 4865942.27, 2226389.81 4865942.27, 1113194.90 2273030.92, 3339584.72 1118889.97))"] | MV_EXPAND wkt | EVAL geom = TO_CARTESIANSHAPE(wkt) ```
Project: Tracetest (Observability and Analysis / Observability)
File: tracetest_list.md

List resources List resources from your Tracetest server ``` tracetest list analyzer|config|datastore|demo|env|organization|pollingprofile|test|testrunner|testsuite|variableset [flags] ``` ``` --all All -h, --help help for list --skip int32 Skip number --sortBy string Sort by --sortDirection string Sort direction (default "desc") --take int32 Take number (default 20) ``` ``` -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: SkyWalking (Observability and Analysis / Observability)
File: banyandb.md

is a dedicated storage implementation developed by the SkyWalking Team and the community. Activate BanyanDB as the storage, and set storage provider to banyandb. The OAP requires BanyanDB 0.6 server. From this version, BanyanDB provides general compatibility. ```yaml storage: banyandb: targets: ${SWSTORAGEBANYANDB_TARGETS:127.0.0.1:17912} maxBulkSize: ${SWSTORAGEBANYANDBMAXBULK_SIZE:5000} flushInterval: ${SWSTORAGEBANYANDBFLUSHINTERVAL:15} metricsShardsNumber: ${SWSTORAGEBANYANDBMETRICSSHARDS_NUMBER:1} recordShardsNumber: ${SWSTORAGEBANYANDBRECORDSHARDS_NUMBER:1} superDatasetShardsFactor: ${SWSTORAGEBANYANDBSUPERDATASETSHARDS_FACTOR:2} concurrentWriteThreads: ${SWSTORAGEBANYANDBCONCURRENTWRITE_THREADS:15} profileTaskQueryMaxSize: ${SWSTORAGEBANYANDBPROFILETASKQUERYMAX_SIZE:200} segmentIntervalDays: ${SWSTORAGEBANYANDBSEGMENTINTERVAL_DAYS:1} superDatasetSegmentIntervalDays: ${SWSTORAGEBANYANDBSUPERDATASETSEGMENTINTERVAL_DAYS:1} specificGroupSettings: ${SWSTORAGEBANYANDBSPECIFICGROUP_SETTINGS:""} ``` BanyanDB Server supports two installation modes: standalone and cluster. The standalone mode is suitable for small-scale deployments, while the cluster mode is suitable for large-scale deployments. Standalone mode: `targets` is the IP address/host name and port of the BanyanDB server. Cluster mode: `targets` is the IP address/host name and port of the `liaison` nodes, separated by commas. `liaison` nodes are the entry points of the BanyanDB cluster. For more details, please refer to the documents of and subprojects.
Project: Vector (Observability and Analysis / Observability)
File: nixos.md

title: Install Vector on NixOS short: NixOS supported_installers: ["Nix", "Docker"] weight: 6 [NixOS] is a Linux distribution built on top of the Nix package manager. This page covers installing and managing Vector on NixOS. Nixpkgs has a for Vector, the options for which may be viewed on the . This can be used to deploy and configure Vector on a NixOS system. For example, place into a system's `configuration.nix`: ```nix services.vector = { enable = true; journaldAccess = true; settings = builtins.fromTOML '' [sources.journald] type = "journald" currentbootonly = true [sources.vector_metrics] type = "internal_metrics" [sinks.loki] type = "loki" inputs = [ "journald" ] endpoint = "https://loki.mycompany.com" [sinks.loki.labels] source = "journald" [sinks.prometheus_exporter] type = "prometheus_exporter" inputs = [ "vector_metrics" ] address = "[::]:9598" ''; }; ``` The module will also verify that the Vector configuration is valid before enabling any changes. See also the [Nix] package page. {{< supported-installers >}}
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: 20220706-recommendation-definition.md

This proposal aims at definition for universal resource optimization. <!-- TOC --> <!-- /TOC --> RecommendationRule defines which resources are required to recommend and what is the runInterval. ```go // RecommendationRuleSpec defines resources and runInterval to recommend type RecommendationRuleSpec struct { // ResourceSelector indicates how to select resources(e.g. a set of Deployments) for an Recommendation. // +required // +kubebuilder:validation:Required ResourceSelectors []ResourceSelector `json:"resourceSelectors"` // RunInterval between two recommendation RunInterval time.Duration `json:"runInterval,omitempty"` } // ResourceSelector describes how the resources will be selected. type ResourceSelector struct { // Kind of the resource, e.g. Deployment Kind string `json:"kind"` // API version of the resource, e.g. "apps/v1" // +optional APIVersion string `json:"apiVersion,omitempty"` // Name of the resource. // +optional Name string `json:"name,omitempty"` // +optional LabelSelector metav1.LabelSelector `json:"labelSelector,omitempty"` } namespace ? ``` Recommendation is a content holder for recommendation result. We hope that the recommendation data can be applied directly to kubernetes cluster(Recommendation as a code) and Different type recommendation have different recommendation yaml, so the content is stored in recommendation as `Data`. ```go type Recommendation struct { metav1.TypeMeta `json:",inline"` metav1.ObjectMeta `json:"metadata,omitempty"` // +kubebuilder:pruning:PreserveUnknownFields Data runtime.RawExtension `json:"data"` } ``` Recommendation Configuration is centralized configuration that contains every rule for universal resource optimization. It not only includes RecommendationRules that use defines but also contains RecommendationPlugins.
Project: Vector (Observability and Analysis / Observability)
File: 2021-06-02-fix-vector-metric-naming.md

date: "2021-06-02" title: "Telemetry units for duration metrics fixed" description: "A few telemetry metric names incorrectly had `nanoseconds_total` in their name when they are actually `seconds`" authors: ["jszwedko"] pr_numbers: [7373] release: "0.14.0" hideonrelease_notes: false badges: type: breaking change domains: ["metrics"] The following internal histogram metrics, accessible via the `internal_metrics` source were incorrectly suffixed with `nanoseconds_total` to indicate their unit as `nanoseconds` when they were in-fact representing `seconds`: `requestdurationnanoseconds` `collectdurationnanoseconds` These have been renamed to: `requestdurationseconds` `collectdurationseconds` If you were consuming these metrics, you will need to update any dashboards or queries to use their new name.
Project: Graphite (Observability and Analysis / Observability)
File: CONTRIBUTING.md

First of all, Welcome, and Thank You! Graphite has been a community project for years, and it only gets better by the efforts of people who volunteer. We sincerely appreciate that you care enough to see a problem and take the time to make this project better. Whether it's in the form of a bug report, code fix, or documentation improvement, we - the Graphite team - appreciate your help. This is a collection of practices that will make it easier for us to accept your contributions. While not mandatory, opening an Issue against the appropriate repo is seldom a bad thing. However, we would love if you would take a moment to search through the existing issues first. It's entirely possible that the issue has already been reported, or even resolved. When opening a new issue, please write a descriptive report. Terse but complete is best. You should describe: What you attempted Expected Result Witnessed Result System Details OS / Version Python Version Django Version (a frequent cause of issues) Graphite Component Versions (or commit hash if running directly from the repo) If the graphite components were installed via pip, `pip list` will show the versions. Graphite-Web has a `/version/` endpoint that returns the version. For example `curl http://mygraphite/version/` We are always looking to improve our test coverage. New tests will be appreciated and quickly reviewed for inclusion. If you see a mistake, have a feature, or a performance gain, we'd love to see it. It's strongly encouraged for contributions that aren't already covered by tests to come with them. We're not trying to foist work on to you, but it makes it much easier for us to accept your contributions. To set up your development environment, see the instructions in requirements.txt Graphite has historically not had great docs. It still doesn't. The good news is that docs are easy to contribute. Even if you don't know the intricacies of ReStructured Text (ReST), bare unformatted paragraphs are better than nothing! English not your primary language? We'll work with you.
Project: Netdata (Observability and Analysis / Observability)
File: kernel_same-page_merging.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/integrations/kernelsame-pagemerging.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/metadata.yaml" sidebar_label: "Kernel Same-Page Merging" 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: /sys/kernel/mm/ksm <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Kernel Samepage Merging (KSM) is a memory-saving feature in Linux that enables the kernel to examine the memory of different processes and identify identical pages. It then merges these identical pages into a single page that the processes share. This is particularly useful for virtualization, where multiple virtual machines might be running the same operating system or applications and have many identical pages. The collector provides information about the operation and effectiveness of KSM on your system. 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.ksm | shared, unshared, sharing, volatile | MiB | | mem.ksm_savings | savings, offered | MiB | | mem.ksm_ratios | savings | percentage | 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: Cortex (Observability and Analysis / Observability)
File: tls.md

title: "Securing communication between Cortex components with TLS" linkTitle: "Securing communication between Cortex components with TLS" weight: 10 slug: tls Cortex is a distributed system with significant traffic between its services. To allow for secure communication, Cortex supports TLS between all its components. This guide describes the process of setting up TLS. The first step to securing inter-service communication in Cortex with TLS is generating certificates. A Certifying Authority (CA) will be used for this purpose which should be private to the organization, as any certificates signed by this CA will have permissions to communicate with the cluster. We will use the following script to generate self signed certs for the cluster: ``` openssl genrsa -out root.key openssl genrsa -out client.key openssl genrsa -out server.key openssl req -x509 -new -nodes -key root.key -subj "/C=US/ST=KY/O=Org/CN=root" -sha256 -days 100000 -out root.crt openssl req -new -sha256 -key client.key -subj "/C=US/ST=KY/O=Org/CN=client" -out client.csr openssl req -new -sha256 -key server.key -subj "/C=US/ST=KY/O=Org/CN=localhost" -out server.csr openssl x509 -req -in client.csr -CA root.crt -CAkey root.key -CAcreateserial -out client.crt -days 100000 -sha256 openssl x509 -req -in server.csr -CA root.crt -CAkey root.key -CAcreateserial -out server.crt -days 100000 -sha256 ``` Note that the above script generates certificates that are valid for 100000 days. This can be changed by adjusting the `-days` option in the above commands. It is recommended that the certs be replaced at least once every 2 years. The above script generates keys `client.key, server.key` and certs `client.crt, server.crt` for both the client and server. The CA cert is generated as `root.crt`. Every HTTP/GRPC link between Cortex components supports TLS configuration through the following config parameters: ``` -server.http-tls-cert-path=/path/to/server.crt -server.http-tls-key-path=/path/to/server.key -server.http-tls-client-auth="RequireAndVerifyClientCert" -server.http-tls-ca-path="/path/to/root.crt" -server.grpc-tls-cert-path=/path/to/server.crt -server.grpc-tls-key-path=/path/to/server.key -server.grpc-tls-client-auth="RequireAndVerifyClientCert" -server.grpc-tls-ca-path=/path/to/root.crt ``` Client flags are component specific. For an HTTP client in the Alertmanager: ``` -alertmanager.configs.tls-cert-path=/path/to/client.crt -alertmanager.configs.tls-key-path=/path/to/client.key -alertmanager.configs.tls-ca-path=/path/to/root.crt ``` For a GRPC client in the Querier: ``` -querier.frontend-client.tls-cert-path=/path/to/client.crt -querier.frontend-client.tls-key-path=/path/to/client.key -querier.frontend-client.tls-ca-path=/path/to/root.crt ``` Similarly, for the GRPC Ingester Client: ``` -ingester.client.tls-cert-path=/path/to/client.crt -ingester.client.tls-key-path=/path/to/client.key -ingester.client.tls-ca-path=/path/to/root.crt ``` TLS can be configured in a similar fashion for other HTTP/GRPC clients in Cortex.
Project: Vector (Observability and Analysis / Observability)
File: PULL_REQUEST_TEMPLATE.md

<!-- Your PR title must conform to the conventional commit spec! <type>(<scope>)!: <description> `type` = chore, enhancement, feat, fix, docs `!` = OPTIONAL: signals a breaking change `scope` = Optional when `type` is "chore" or "docs", available scopes https://github.com/vectordotdev/vector/blob/master/.github/semantic.yml#L20 `description` = short description of the change Examples: enhancement(file source): Add `sort` option to sort discovered files feat(new source): Initial `statsd` source fix(file source): Fix a bug discovering new files chore(external docs): Clarify `batch_size` option -->