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

Welcome to Kubernetes. We are excited about the prospect of you joining our ! The Kubernetes community abides by the CNCF . Here is an excerpt: As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. This library adapts the stdlib `encoding/json` decoder to be compatible with Kubernetes JSON decoding, and is not expected to actively add new features. It may be updated with changes from the stdlib `encoding/json` decoder. Any code that is added must: Have full unit test and benchmark coverage Be backward compatible with the existing exposed go API Have zero external dependencies Preserve existing benchmark performance Preserve compatibility with existing decoding behavior of `UnmarshalCaseSensitivePreserveInts()` or `UnmarshalStrict()` Avoid use of `unsafe` We have full documentation on how to get started contributing here: <! If your repo has certain guidelines for contribution, put them here ahead of the general k8s resources --> Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests - Main contributor documentation, or you can just jump directly to the - Common resources for existing developers You can reach the maintainers of this project via the . - We have a diverse set of mentorship programs available that are always looking for volunteers!
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: TESTCASES.md

Name: Force execution of a queries Steps: click to button `Execute query` click to icon `Refresh dashboard` press `enter` on the query field Expected Result: For each step sends a request and render new data Name: Time Range with auto refresh Steps: Set absolute time range Enable auto refresh Change delay auto refresh Disable auto refresh Expected Result: Time range has not changed Name: Query history Steps: Run query one by one: `1`, `2`, `3` Press `Ctrl + ArrowUp`/`Ctrl + ArrowDown` when the query field focus Expected Result: Query value changes according to execution order (Preserve execution order). <br/> `Ctrl + ArrowUp` - set prev value, `Ctrl + ArrowDown` - set next value Name: Absolute time range fields Steps: Open `Time range controls` Change `From` or `Until` time value Click to `Apply` Expected Result: When you change one of the fields, the second does not change Name: Auto update after query delete Steps: Add multiple query Execute queries Delete one of the queries Expected Result: Graph is automatically updated after the query delete Name: Query URL params Steps: with params: ?g0.rangeinput=1d&g0.endinput=2022-10-26T14%3A00%3A00&g0.stepinput=180&g0.relativetime=none&g0.tab=chart&g0.expr=1&g1.rangeinput=1d&g1.endinput=2022-10-26T14%3A00%3A00&g1.stepinput=180&g1.relativetime=none&g1.tab=chart&g1.expr=2#/ Expected Result: Executed two query with params: ``` query: 1 and 2 start: 1666706400 end: 1666792800 step: from "Step value" field (depends on screen width) ``` Display two queries: `1` and `2` Time range from `2022-10-25 16:00:00` to `2022-10-26 16:00:00` (:warning: by UTC +2) Display tab `Table` Name: Prometheus query URL params Steps: with params: ?g0.expr=nodearpentries&g0.tab=1&g0.stacked=0&g0.rangeinput=30m&g0.endinput=2021-09-11%2000%3A00%3A00&g0.momentinput=2021-09-11%2000%3A00%3A00&g0.stepinput=6&g1.expr=nodecpuguestsecondstotal&g1.tab=1&g1.stacked=0&g1.rangeinput=30m&g1.endinput=2022-12-01%2014%3A00%3A00&g1.momentinput=2022-12-01%2014%3A00%3A00&g1.stepinput=6 Expected Result: Display two queries: `nodearpentries` and `nodecpuguestsecondstotal` Time range from `2021-09-11 01:30:00` to `2021-09-11 02:00:00` (:warning: by UTC +2) Display tab `Table`
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-9-1-2.md

aliases: [] hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 9.1.2 <!-- Auto generated by update changelog github action --> AdHoc variable: Correctly preselect datasource when provisioning. , AzureMonitor: Added ARG query function for template variables. , Dashboard save: Persist details message when navigating through dashboard save drawer's tabs. , Dashboards: Correctly migrate mixed data source targets. , Elasticsearch: Use millisecond intervals for alerting. , Elasticsearch: Use millisecond intervals in frontend. , Geomap: Local color range. , Plugins Catalog: Use appSubUrl to generate plugins catalog urls. , Rendering: Add support for renderer token. , Alerting: Fix saving of screenshots uploaded with a signed url. , AngularPanels: Fixing changing angular panel options not taking having affect when coming back from panel edit. , Explore: Improve a11y of query row collapse button. , Geomap: Fix tooltip display. , QueryEditorRow: Filter data on mount. , Search: Show all dashboards in the folder view. , Tracing: Fix the event attributes in opentelemetry tracing. , GrafanaUI: Fix styles for invalid selects & DataSourcePicker. ,
Project: SkyWalking (Observability and Analysis / Observability)
File: es-version-conflict.md

Since 8.7.0, we did the following optimization to reduce Elasticsearch load. ```markdown Performance: remove the synchronous persistence mechanism from batch ElasticSearch DAO. Because the current enhanced persistent session mechanism, don't require the data queryable immediately after the insert and update anymore. ``` Due to this, we flush the metrics into Elasticsearch without using `WriteRequest.RefreshPolicy.WAIT_UNTIL`. This reduces the load of persistent works in OAP server and load of Elasticsearch CPU dramatically. Meanwhile, there is little chance you could see following warns in your logs. ``` { "timeMillis": 1626247722647, "thread": "I/O dispatcher 4", "level": "WARN", "loggerName": "org.apache.skywalking.oap.server.library.client.elasticsearch.ElasticSearchClient", "message": "Bulk [0]] ElasticsearchException[Elasticsearch exception [type=versionconflictengineexception, reason=[20210714b3BlcmF0aW9uLXJ1bGUtc2VydmVyQDExNDgx.1-bWFya2V0LXJlZmVycmFsLXNlcnZlckAxMDI1MQ==.1]: version conflict, required seqNo [14012594], primary term [1]. current document has seqNo [14207928] and primary term [1]]]]]", "endOfBatch": false, "loggerFqcn": "org.apache.logging.slf4j.Log4jLogger", "threadId": 44, "threadPriority": 5, "timestamp": "2021-07-14 15:28:42.647" } ``` This would not affect the system much, just a possibility of inaccurate of metrics. If this wouldn't show up in high frequency, you could ignore this directly. In case you could see many logs like this. Then it is a signal, that the flush period of your ElasticSearch template can't catch up your setting. Or you set the `persistentPeriod` less than the flush period.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: Grafana (Observability and Analysis / Observability)
File: grafana-managed-alerts.md

labels: products: enterprise oss title: Grafana managed alerts The current alerting system doesn't support high availability. Alert notifications are not deduplicated and load balancing is not supported between instances; for example, silences from one instance will not appear in the other. Grafana managed alerts are evaluated by the Grafana backend. Rule evaluations are scheduled, according to the alert rule configuration, and queries are evaluated by an engine that is part of core Grafana. Alerting rules can only query backend data sources with alerting enabled: builtin or developed and maintained by grafana: `Graphite`, `Prometheus`, `Loki`, `InfluxDB`, `Elasticsearch`, `Google Cloud Monitoring`, `Cloudwatch`, `Azure Monitor`, `MySQL`, `PostgreSQL`, `MSSQL`, `OpenTSDB`, `Oracle`, and `Azure Data Explorer` any community backend data sources with alerting enabled (`backend` and `alerting` properties are set in the The alerting engine publishes some internal metrics about itself. You can read more about how Grafana publishes . See also, . | Metric Name | Type | Description | | | | - | | `alerting.alerts` | gauge | How many alerts by state | | `alerting.requestdurationseconds` | histogram | Histogram of requests to the Alerting API | | `alerting.active_configurations` | gauge | The number of active, non default alertmanager configurations for grafana managed alerts | | `alerting.ruleevaluationstotal` | counter | The total number of rule evaluations | | `alerting.ruleevaluationfailures_total` | counter | The total number of rule evaluation failures | | `alerting.ruleevaluationduration_seconds` | histogram | The time to evaluate a rule | | `alerting.ruleprocessevaluationdurationseconds` | histogram | The time to process the evaluation results for a rule | | `alerting.rulesendalertsdurationseconds` | histogram | The time to send the alerts to Alertmanager | | `alerting.rulegrouprules` | gauge | The number of rules | | `alerting.statecalculationduration_seconds` | histogram | The duration of calculation of a single state |
Project: Trickster (Observability and Analysis / Observability)
File: roadmap.md

The roadmap for Trickster in 2021 focuses on delivering Trickster versions 2.0 and 2.1, as well as new supporting applications and cloud native integrations. Additional details for Q3 and Q4 will be provided as the year progresses. [ ] Trickster v2.0 Beta Release [x] Common Time Series Format used internally for all TSDBs [x] Universal HTTP Health Checker Package [x] ALB with features for high availability and scatter/gather timeseries merge [x] YAML config support [x] Extended support for ClickHouse [ ] Support for InfluxDB 2.0, Flux syntax and querying via Chronograf [ ] Purge object from cache by path or key [ ] Short-term caching of non-timeseries read-only queries (e.g., generic SELECT statements) [x] Support Brotli encoding over the wire and as a cache compression format [x] Submit Trickster for CNCF Sandbox Consideration [ ] Trickster v2.0 GA Release [ ] Documentation overhaul using MkDocs with Release deployment automation [ ] Migrate integration tests infrastructure as needed to easily integrate with related CNCF projects. [ ] Trickster v2.1 Beta Release [ ] Support for ElasticSearch [ ] Support operating as an adaptive, front-side cache for Grafana, including its UI, API's, and accelerating any supported timeseries datasources. [ ] Better support for operating in front of Thanos [ ] Ability to parallelize large timerange queries by scatter/gathering smaller sections of the main timerange. [ ] Additional Rules Engine capabilities for more complex request routing [ ] Grafana-style environment variable support [ ] Subdirectory (e.g., `/etc/trickster.conf.d/`) support for chained config files [ ] Register Official Docker Hub Repositories [ ] Trickster v2.1 GA Release [ ] Trickster v2.2 Beta Release You can help by contributing to Trickster, or trying it out in your environment. By giving Trickster a spin, you can help us identify and fix defects more quickly. Be sure to file issues if you find something wrong. If you can reliably reproduce the issue, provide detailed steps so that developers can more easily root-cause the issue. If you want to contribute to Trickster, we'd love the help. Please take any issue that is not already assigned as per the contributing guidelines, or check with the maintainers to find out how best to get involved. We are so excited to share the Trickster with the community. This is only possible through our great community of contributors, users and supporters. Thank you for all you in making this project a success!
Project: SkyWalking (Observability and Analysis / Observability)
File: backend-start-up-mode.md

You may need different startup modes in different deployment tools, such as k8s. We provide two additional optional startup modes. The default mode carries out tasks to initialize as necessary, starts to listen, and provides services. Run `/bin/oapService.sh`(.bat) to start in this mode. This is also applicable when you're using `startup.sh`(.bat) to start. In this mode, the OAP server starts up to carry out initialization and then exits. You could use this mode to initialize your storage (such as ElasticSearch indexes, MySQL, and TiDB tables) as well as your data. Run `/bin/oapServiceInit.sh`(.bat) to start in this mode. In this mode, the OAP server starts up without carrying out initialization. Rather, it watches out for the ElasticSearch indexes, MySQL, TiDB and other storage tables, starts listening and provides services. In other words, the OAP server would anticipate having another OAP server carrying out the initialization. Run `/bin/oapServiceNoInit.sh`(.bat) to start in this mode.
Project: Checkmk (Observability and Analysis / Observability)
File: 15324.md

key | value | date | 2024-02-01T06:19:27+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes made the Inputs of "Instance settings" of the Agent rule "PostgreSQL database and sessions (Linux, Windows)" optional by accident. If you did not specify all keys, baking agents failed with a `KeyError` on the automation call.
Project: Netdata (Observability and Analysis / Observability)
File: btrfs_device_flush_errors.md

This alert indicates that `BTRFS` flush errors have been detected on your file system. If you receive this alert, it means that your system has encountered problems while flushing data from memory to disk, which may result in data corruption or data loss. `BTRFS` (B-Tree File System) is a modern, copy-on-write (CoW) file system for Linux designed to address various weaknesses in traditional file systems. It provides advanced features like data pooling, snapshots, and checksums that enhance fault tolerance. Verify the alert Check the `Netdata` dashboard or query the monitoring API to confirm that the alert is genuine and not a false positive. Review and analyze syslog Check your system's `/var/log/syslog` or `/var/log/messages`, looking for `BTRFS`-related errors. These messages will provide essential information about the cause of the flush errors. Confirm BTRFS status Run the following command to display the state of the BTRFS file system and ensure it is mounted and healthy: ``` sudo btrfs filesystem show ``` Check disk space Ensure your system has sufficient disk space allocated to the BTRFS file system. A full or nearly full disk might cause flush errors. You can use the `df -h` command to examine the available disk space. Check system I/O usage Use the `iotop` command to inspect disk I/O usage for any abnormally high activity, which could be related to the flush errors. ``` sudo iotop ``` Upgrade or rollback BTRFS version Verify that you are using a stable version of the BTRFS utilities and kernel module. If not, consider upgrading or rolling back to a more stable version. Inspect hardware health Inspect your disks and RAM for possible hardware problems, as these can cause flush errors. SMART data can help assess disk health (`smartctl -a /dev/sdX`), and `memtest86+` can be used to scrutinize RAM. Create backups Take backups of your critical BTRFS data immediately to avoid potential data loss due to flush errors.
Project: Vector (Observability and Analysis / Observability)
File: http_server.md

title: HTTP Server description: Receive observability data from an component_kind: source layout: component tags: ["http", "server", "component", "source", "logs", "metrics", "traces"] aliases: ["/docs/reference/configuration/sources/http"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Vector (Observability and Analysis / Observability)
File: 2023-08-15-0-32-0-upgrade-guide.md

date: "2023-08-15" title: "0.32 Upgrade Guide" description: "An upgrade guide that addresses breaking changes in 0.32.0" authors: ["jszwedko"] release: "0.32.0" hideonrelease_notes: false badges: type: breaking change Vector's 0.32.0 release includes deprecations: and potentially impactful changes: We cover them below to help you upgrade quickly: The `to_timestamp` function in VRL was deprecated. Instead, the following functions should be used: `parse_timestamp` to parse string timestamps `fromunixtimestamp` to parse integer timestamps This removes some confusion that existed around "magic formats" that the `to_timestamp` had by requiring string timestamp formats to be specified explicitly. With the upgrade to OpenSSL 3.1.2, the [legacy algorithm provider](https://github.com/openssl/openssl/blob/openssl-3.1.2/README-PROVIDERS.md#the-legacy-provider) was deprecated. The default will be switched in a future version to [default provider](https://github.com/openssl/openssl/blob/openssl-3.1.2/README-PROVIDERS.md#the-default-provider). You can opt into this behavior now by setting the environment variable `VECTOROPENSSLLEGACY_PROVIDER=false`. As part of moving off of OpenSSL 1.1.1 before it becomes [end-of-life in September](https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/), Vector has upgraded the version that it statically compiles in to 3.1.2. We don't anticipate any end-user impact from this change to users of Vector, but if you see any breakages resulting from this upgrade.
Project: Checkmk (Observability and Analysis / Observability)
File: 16603.md

key | value | date | 2024-03-27T08:43:36+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Postgres.cfg was always read as unicode decoded. This ensures that the read text is correctly converted to byte string format.
Project: PowerfulSeal (Observability and Analysis / Chaos Engineering)
File: 4_policies.md

layout: default title: Writing policies nav_order: 4 description: "" permalink: /policies has_children: true {: .no_toc } {: .no_toc .text-delta } TOC {:toc} Policies describe the chaos experiments for powerfulseal to execute in autonomous mode. The syntax is formally defined . If you want to browse the available options, see below: {: .btn .btn-secondary .fs-5 .mb-4 .mb-md-0 .mr-2 } A policy file is a yaml file. The most basic policy you can write is the following: ```yaml scenarios: [] ``` It will validate, but will not do anything interesting. If you'd like to see all possible options in an example config, you . We use it to test that it validates to detect any regressions when new features are added. Every scenario has a name and an array of steps to do. For example: ```yaml scenarios: name: Example scenario description: > A longer description of the scenario. Can have multiple lines etc. steps: [] ``` The steps will be executed in the order specified. You can also tweak certain parameters directly from the policy file. For example, by default the seal will continuosly run your scenario and only stop on errors. If you'd like to run an experiment as part of your CI pipeline, you might want to run it a single time and then exit. The return code will tell you whether the experiment succeeded or not. ```yaml config: runStrategy: runs: 1 scenarios: [] ``` By default, the seal runs the scenarios in the order specified (`round-robin`). You can change that to run them in a random order: ```yaml config: runStrategy: strategy: random scenarios: [] ``` By default, if a scenario fails, the seal will report the error so that you can alert on it, and keep going. If you'd like it to exit (for example if you're running it as a job), you can use the `fail-fast` exit strategy: ```yaml config: exitStrategy: strategy: fail-fast scenarios: [] ``` To see examples of policies, use the menu on the left. With great power comes great responsibility, and sometimes it's easy to take down the wrong pod or node and kill the Seal by accident. That's not ideal, because it might result in nodes staying down, or incomplete experiments. To avoid that, PowerfulSeal honors two variables, that it will filter out from killing: ```yaml env: name: POD_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.name name: HOST_IP valueFrom: fieldRef: apiVersion: v1 fieldPath: status.hostIP ``` Any pods with this name, and any hosts with that IP will be spared.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: datadog.md

title: Datadog weight: 200 generated_file: true It mainly contains a proper JSON formatter and a socket handler that streams logs directly to Datadog - so no need to use a log shipper if you don't want to. For details, see . ```yaml spec: datadog: api_key: value: '<YOURAPIKEY>' # For referencing a secret, see https://kube-logging.dev/docs/configuration/plugins/outputs/secret/ ddsource: '<INTEGRATIONNAME>' dd_tags: '<KEY1:VALUE1>,<KEY2:VALUE2>' ddsourcecategory: '<YOURSOURCE_CATEGORY>' ``` This parameter is required in order to authenticate your fluent agent. +docLink:"Secret,../secret/" Default: nil Set the log compression level for HTTP (1 to 9, 9 being the best ratio) Default: "6" Used by Datadog to identify the host submitting the logs. Default: "hostname -f" This tells Datadog what integration it is Default: nil Multiple value attribute. Can be used to refine the source attribute Default: nil Custom tags with the following format "key1:value1, key2:value2" Default: nil Proxy endpoint when logs are not directly forwarded to Datadog Default: "http-intake.logs.datadoghq.com" Automatically include the Fluentd tag in the record. Default: false The maximum time waited between each retry in seconds Default: "30" The number of retries before the output plugin stops. Set to -1 for unlimited retries Default: "-1" Disable SSL validation (useful for proxy forwarding) Default: false Proxy port when logs are not directly forwarded to Datadog and ssl is not used Default: "80" Used by Datadog to correlate between logs, traces and metrics. Default: nil The threshold for chunk flush performance check. Parameter type is float, not time, default: 20.0 (seconds) If chunk flush takes longer time than this threshold, fluentd logs warning message and increases metric fluentdoutputstatusslowflush_count. Port used to send logs over a SSL encrypted connection to Datadog. If use_http is disabled, use 10516 for the US region and 443 for the EU region. Default: "443" Where to store the Fluentd tag. Default: "tag" Name of the attribute which will contain timestamp of the log event. If nil, timestamp attribute is not added. Default: "@timestamp" Enable log compression for HTTP Default: true Enable HTTP forwarding. If you disable it, make sure to change the port to 10514 or ssl_port to 10516 Default: true Event format, if true, the event is sent in json format. Othwerwise, in plain text. Default: true If true, the agent initializes a secure connection to Datadog. In clear TCP otherwise. Default: true