cwielenb/CNCF-Dataset huggingface dataset:
Project: Grafana Tempo (Observability and Analysis / Observability)
File: dedicated_columns.md

title: Dedicated attribute columns description: Learn how to use dedicated attribute columns to improve query performance. weight: 42 Dedicated attribute columns improve query performance by storing the most frequently used attributes in their own columns, rather than in the generic attribute key-value list. Introduced with `vParquet3`, dedicated attribute columns are only available when using this storage format. To read more about the design of `vParquet3`, see . Dedicated attribute columns can be configured in the storage block or via overrides. ```yaml storage: trace: block: version: vParquet3 parquetdedicatedcolumns: name: <string>, # name of the attribute type: <string>, # type of the attribute. options: string scope: <string> # scope of the attribute. options: resource, span overrides: parquetdedicatedcolumns: name: <string>, # name of the attribute type: <string>, # type of the attribute. options: string scope: <string> # scope of the attribute. options: resource, span pertenantoverride_config: /conf/overrides.yaml overrides: "<tenant id>": parquetdedicatedcolumns: name: <string>, # name of the attribute type: <string>, # type of the attribute. options: string scope: <string> # scope of the attribute. options: resource, span "*": parquetdedicatedcolumns: name: <string>, # name of the attribute type: <string>, # type of the attribute. options: string scope: <string> # scope of the attribute. options: resource, span ``` Priority is given to the most specific configuration, so tenant-specific overrides will take precedence over global overrides. Similarly, default overrides take precedence over storage block configuration. Dedicated attribute columns are limited to 10 span attributes and 10 resource attributes with string values. As a rule of thumb, good candidates for dedicated attribute columns are attributes that contribute the most to the block size, even if they are not frequently queried. Reducing the generic attribute key-value list size significantly improves query performance. You can use the `tempo-cli` tool to find good candidates for dedicated attribute columns. The `tempo-cli` provides the commands `analyse block <tenant-id> <block-id>` and `analyse blocks <tenant-id>` that will output the top N attributes by size for a given block or all blocks in a tenant. Example: ```bash tempo-cli analyse blocks --backend=local --bucket=./cmd/tempo-cli/test-data/ single-tenant ``` Refer to the for more information.
Project: M3 (Observability and Analysis / Observability)
File: quickstart-http-query-steps.md

To query metrics, use the {{% apiendpoint %}}queryrange_ endpoint with the following data in the request body, all fields are required: `query`: A PromQL query `start`: Timestamp in `RFC3339Nano` of start range for results `end`: Timestamp in `RFC3339Nano` of end range for results `step`: A duration or float of the query resolution, the interval between results in the timespan between `start` and `end`. Below are some examples using the metrics written above. {{< tabs name="examplepromqlregex" >}} {{% tab name="Linux" %}} <!-- TODO: Check this on Linux --> ```shell curl -X "POST" -G "{{% apiendpoint %}}query_range" \ -d "query=third_avenue" \ -d "start=$(date "+%s" -d "45 seconds ago")" \ -d "end=$( date +%s )" \ -d "step=5s" | jq . ``` {{% /tab %}} {{% tab name="macOS/BSD" %}} ```shell curl -X "POST" -G "{{% apiendpoint %}}query_range" \ -d "query=third_avenue" \ -d "start=$( date -v -45S +%s )" \ -d "end=$( date +%s )" \ -d "step=5s" | jq . ``` {{% /tab %}} {{% tab name="Output" %}} ```json { "status": "success", "data": { "resultType": "matrix", "result": [ { "metric": { "name": "third_avenue", "checkout": "1", "city": "new_york" }, "values": [ [ {{% now %}}, "3347.26" ], [ {{% now %}}, "5347.26" ], [ {{% now %}}, "7347.26" ] ] } ] } } ``` {{% /tab %}} {{< /tabs >}} {{< tabs name="examplepromqlrange" >}} {{% tab name="Linux" %}} <!-- TODO: Check Linux command --> ```shell curl -X "POST" -G "{{% apiendpoint %}}query_range" \ -d "query=third_avenue > 6000" \ -d "start=$(date "+%s" -d "45 seconds ago")" \ -d "end=$( date +%s )" \ -d "step=5s" | jq . ``` {{% /tab %}} {{% tab name="macOS/BSD" %}} ```shell curl -X "POST" -G "{{% apiendpoint %}}query_range" \ -d "query=third_avenue > 6000" \ -d "start=$(date -v -45S "+%s")" \ -d "end=$( date +%s )" \ -d "step=5s" | jq . ``` {{% /tab %}} {{% tab name="Output" %}} ```json { "status": "success", "data": { "resultType": "matrix", "result": [ { "metric": { "name": "third_avenue", "checkout": "1", "city": "new_york" }, "values": [ [ {{% now %}}, "7347.26" ] ] } ] } } ``` {{% /tab %}} {{< /tabs >}}
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: ci-cd.md

hide: toc We have integrated Litmus with a couple of CI tools, the major ones are: GitHub Actions using `litmuschaos` actions GitLab using remote templates Keptn Spinnaker templates By this, we induce chaos as part of the CI stage as Continuous Chaos allows us to automatically identify application failures over the development phase. Failure of an exp in CI should invariably fail the pipeline. The pass would be more subjective. Depends on what is the nature of the CI pipeline - what it is the tests being carried is like etc., If you are doing a simple pod-delete or cpu-hog on a microservice pod w/o traffic OR w/o running it in an env that doesn't need it to interact w/ other services then the insights are limited. Yes, with the help of GitHub-chaos-action we can automate the chaos execution on an application in the same place where the code is stored. We can write individual tasks along with chaos actions and combine them to create a custom GitHub workflow. GitHub Workflows are custom automated processes that we can set up in our repository to build, test, package, or deploy any code project on GitHub. Including the GitHub chaos actions in our workflow YAML, We can test the performance/resiliency of our application in a much simpler and better way. To know more visit our Github chaos action . GitOps feature in Litmus enables users to sync workflows from a configured git repo, any workflow inserts/updates made to the repo will be monitored and picked up by the Litmus portal and will be executed on the target cluster. Litmus portal GitOps also includes an event-driven chaos injection feature where users can annotate an application to be watched for changes and if and when the change happens chaos workflows can be triggered automatically. This integrates with other GitOps tools like Flux/Argo CD and enables users to automatically run chaos workflows whenever a new release happens or a particular change occurs in the application. To configure a git repo the user must provide the Git URL of the repository and the branch name and the authentication credentials which are of two types: Access Token SSH Key Once GitOps is enabled, any new workflows created will be stored in the configured repo in the path `litmus/<project-id>/<workflow-name>.yaml` You can add Litmus to the CI/CD pipelines as part of an end-to-end testing approach due to its minimal pre-requisites and simple result mechanisms. It also provides utilities for quick setup of Kubernetes clusters on different platforms as well as installation of storage provider control plane components (operators). is a reference implementation of how Litmus can be used in the DevOps pipeline.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: v2.8.md

description: Release notes for Grafana Mimir version 2.8 menuTitle: V2.8 release notes title: Grafana Mimir version 2.8 release notes weight: 300 Grafana Labs is excited to announce version 2.8 of Grafana Mimir. The highlights that follow include the top features, enhancements, and bugfixes in this release. For the complete list of changes, see the . Experimental support for using Redis as cache Mimir now can use Redis for caching results, chunks, index and metadata. Experimental support for fetching secret from Vault for TLS configuration. Experimental support for querying native histograms. This support is not finalized as the related Prometheus API is also experimental, thus the exact behavior might change in future releases. Query-frontend and ruler now use protobuf internal query result payload format by default This reduces the CPU and memory utilisation of the querier, query-frontend and ruler, as well as reducing network bandwidth consumed between these components. Query-frontend cached results now contain timestamp This allows Mimir to check if cached results are still valid based on current TTL configured for tenant. Results cached by previous Mimir version are used until they expire from cache, which can take up to 7 days. If you need to use per-tenant TTL sooner, please flush results cache manually. Optimized regular expression label matchers This reduces CPU utilisation in ingesters and store-gateways when running queries containing regular expression label matchers. Store-gateway now use streaming for LabelNames RPC This improves memory utilization in store-gateway when calling LabelNames RPC. The Grafana Mimir and Grafana Enterprise Metrics Helm chart is now released independently. See the . In Grafana Mimir 2.8 we have removed the following previously deprecated or experimental metrics: `cortexbucketstoreseriesgetallduration_seconds` `cortexbucketstoreseriesmergedurationseconds` `cortexingestertsdbwalreplaydurationseconds` The following configuration options are deprecated and will be removed in Grafana Mimir 2.10: The CLI flag `-blocks-storage.tsdb.max-tsdb-opening-concurrency-on-startup` and its respective YAML configuration option `tsdb.maxtsdbopeningconcurrencyon_startup`. The following configuration options that were deprecated in 2.6 are removed: The CLI flag `-store.max-query-length` and its respective YAML configuration option `limits.maxquerylength`. The following configuration options that were deprecated in 2.5 are removed: The CLI flag `-azure.msi-resource`. The following experimental options and features are now stable: The protobuf internal query result payload format, which is now enabled by default We changed default value of block storage retention period. The default value for `-blocks-storage.tsdb.retention-period` was `24h` and now is `13h` Querier: Streaming remote read will now continue to return multiple chunks per frame after the first frame. Query-frontend: don't retry queries which error inside PromQL. Store-gateway & query-frontend: report more consistent statistics for fetched index bytes.
Project: Checkmk (Observability and Analysis / Observability)
File: 16794.md

key | value | date | 2024-04-26T11:27:20+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | no This only affects you if you are configuring rules through the REST API. In order to make the "checkgroupparameters:if" ruleset compliant with the new Ruleset API, it has been renamed to "checkgroupparameters:interfaces". Any configuration inside Checkmk will be automatically updated, however any outside references to the old name will have to be adjusted manually.
Project: Chaosblade (Observability and Analysis / Chaos Engineering)
File: GOVERNANCE.md

The governance model adopted in ChaosBlade is influenced by many CNCF projects. Open: ChaosBlade is open source community. Welcoming and respectful: See . Transparent and accessible: Work and collaboration should be done in public. Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, scope and design principles. Maintainers are the first and foremost contributors that are committed to the success of ChaosBlade project. They normally take the following responsibilities: Classify GitHub issues and perform pull request reviews for other maintainers and the community. During GitHub issue classification, apply all applicable to each new issue. Labels are extremely useful for follow-up of future issues. Which labels to apply is somewhat subjective so just use your best judgment. Make sure that ongoing PRs are moving forward at the right pace or closing them if they are not moving in a productive direction. Participate when called upon in the security release process. Note that although this should be a rare occurrence, if a serious vulnerability is found, the process may take up to several full days of work to implement. Talk to one of the existing project that you are interested in becoming a maintainer and he will nominate you as a new maintainer. After nomination, you will need to create a PR to update the list in . We will expect you to start contributing increasingly complicated PRs, under the guidance of the existing maintainers. We may ask you to do some PRs from our backlog. As you gain experience with the code base and our standards, we will ask you to do code reviews for incoming PRs. Once the existing maintainers have made a consensus that the nominating maintainer has deep understanding about the project and is able to independently take the maintainer responsibilities, the PR will be approved and the new maintainer becomes active. If a maintainer is no longer interested or cannot perform the maintainer duties listed above, they should volunteer to be moved to emeritus status. In extreme cases this can also occur by a vote of the maintainers per the voting process. The voting process is a simple majority in which each maintainer receives one vote. Decisions are made based on consensus between maintainers. Proposals and ideas can either be submitted for agreement via a github issue or PR, or by sending an email to `chaosblade.io.01@gmail.com`. In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, get a third-party maintainer (e.g. a mutual contact with some background on the issue, but not involved in the conflict) to intercede and the final decision will be made. Decision making process should be transparent to adhere to the principles of ChaosBlade project. The ChaosBlade is aligned with the CNCF Code of Conduct. Some contents in this documents have been borrowed from and projects.
Project: Checkmk (Observability and Analysis / Observability)
File: 16405.md

key | value | date | 2024-02-14T14:29:36+00:00 version | 2.4.0b1 class | fix edition | cre component | omd level | 1 compatible | yes During `cmk-update-config` can prompt you with questions about how to continue the update. This is an example. ``` Exception while trying to load rulesets: You can abort the update process (A) and try to fix the incompatibilities or try to continue the update (c). Abort update? [A/c] ``` Previously, these prompts would read input, which was typed before the prompt was shown. Now, only the input is read after the prompt is shown.
Project: HertzBeat (Observability and Analysis / Observability)
File: extend-http-jsonpath.md

id: extend-http-jsonpath title: HTTP Protocol JsonPath Parsing Method sidebar_label: JsonPath Parsing Method After calling the HTTP api to obtain the response data, use JsonPath script parsing method to parse the response data. Note The response data is JSON format. Use the JsonPath script to parse the response data into data that conforms to the data structure rules specified by HertzBeat | JSONPATH | Help description | ||-| | $ | Root object or element | | @ | Current object or element | | . or [] | Child element operator | | .. | Recursively match all child elements | | * | Wildcard. Match all objects or elements | | [] | Subscript operator, jsonpath index starts from 0 | | [,] | Join operator, return multiple results as an array. Jsonpath allows the use of aliases | | [start:end:step] | Array slice operator | | ?() | Filter (script) expression | | () | Script Expression | Single layer format key-value ```json { "metricName1": "metricValue", "metricName2": "metricValue", "metricName3": "metricValue", "metricName4": "metricValue" } ``` Multilayer formatSet key value in the array ```json [ { "metricName1": "metricValue", "metricName2": "metricValue", "metricName3": "metricValue", "metricName4": "metricValue" }, { "metricName1": "metricValue", "metricName2": "metricValue", "metricName3": "metricValue", "metricName4": "metricValue" } ] ``` Query the value information of the custom system, and its exposed interface is `/metrics/person`. We need `type,num` Metric. The raw data returned by the interface is as follows ```json { "firstName": "John", "lastName" : "doe", "age" : 26, "address" : { "streetAddress": "naist street", "city" : "Nara", "postalCode" : "630-0192" }, "number": [ { "type": "core", "num": 3343 }, { "type": "home", "num": 4543 } ] } ``` We use the jsonpath script to parse, and the corresponding script is: `$.number[*]`The parsed data structure is as follows ```json [ { "type": "core", "num": 3343 }, { "type": "home", "num": 4543 } ] ``` This data structure conforms to the data format specification of HertzBeat, and the Metric `type,num` is successfully extracted. The corresponding monitoring template yml can be configured as follows ```yaml category: custom app: example name: zh-CN: en-US: EXAMPLE APP params: field: host name: zh-CN: Host en-US: Host type: host required: true field: port name: zh-CN: en-US: Port type: number range: '[0,65535]' required: true defaultValue: 80 placeholder: 'Please enter the port' metrics: name: cpu priority: 0 fields: field: type type: 1 label: true field: num type: 0 protocol: http http: host: ^^host^^ port: ^^port^^ url: /metrics/person method: GET ssl: false parseType: jsonPath parseScript: '$.number[*]' ```
Project: Hubble (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: Flagsmith (Observability and Analysis / Feature Flagging)
File: 02-Okta.md

title: Okta Flagsmith can integrate with your Okta single sign-on (SSO) by using . Get in touch with Flagsmith support to obtain the single sign-on URL and audience URI to use when creating your Okta SAML application. Create a SAML configuration by following the . Leave the identity provider metadata blank for now. from the Okta management to represent your Flagsmith organisation with the following settings: Single sign-on URL: Obtain this URL from Flagsmith support, or from your Audience URI (SP Entity ID): Obtain this from Flagsmith support, or use your if self-hosting Once your Okta application is created, you can and send it to Flagsmith support, or add it to your SAML configuration if self-hosting.
Project: SkyWalking (Observability and Analysis / Observability)
File: vnode.md

On the trace page, you may sometimes find nodes with their spans named VNode, and that there are no attributes for such spans. VNode is created by the UI itself, rather than being reported by the agent or tracing SDK. It indicates that some spans are missed in the trace data in this query. The UI checks the parent spans and reference segments of all spans in real time. If no parent id(segment id + span id) could be found, then it creates a VNode automatically. The VNode appears when the trace data is incomplete. The agent fail-safe mechanism has been activated. The SkyWalking agent could abandon the trace data if there are any network issues between the agent and the OAP (e.g. failure to connect, slow network speeds, etc.), or if the OAP cluster is not capable of processing all traces. Some plug-ins may have bugs, and some segments in the trace do not stop correctly and are held in the memory. In such case, the trace would not exist in the query, thus the VNode shows up.
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: example.md

<!-- generate-sample-config:server:md --> | Name | Default Value | Usage | | :- | :- | :- | | analytics-opt-out | false | "disables analytics" | | log-level | info | "log level: debug|info|warn|error" | | badger-log-level | error | "log level: debug|info|warn|error" | | storage-path | /var/lib/pyroscope | "directory where pyroscope stores profiling data" | | api-bind-addr | :4040 | "port for the HTTP server used for data ingestion and web UI" | | base-url | | "base URL for when the server is behind a reverse proxy with a different path" | | cache-dimension-size | 1000 | "max number of elements in LRU cache for dimensions" | | cache-dictionary-size | 1000 | "max number of elements in LRU cache for dictionaries" | | cache-segment-size | 1000 | "max number of elements in LRU cache for segments" | | cache-tree-size | 1000 | "max number of elements in LRU cache for trees" | | badger-no-truncate | false | "indicates whether value log files should be truncated to delete corrupt data, if any" | | max-nodes-serialization | 2048 | "max number of nodes used when saving profiles to disk" | | max-nodes-render | 8192 | "max number of nodes used to display data on the frontend" | | hide-applications | | "please don't use, this will soon be deprecated" | | out-of-space-threshold | 512.00 MB | "Threshold value to consider out of space in bytes" | | sample-rate | 100 | "sample rate for the profiler in Hz. 100 means reading 100 times per second" | <!-- /generate-sample-config --> <!-- generate-sample-config:server:yaml --> ```yaml analytics-opt-out: "false" log-level: "info" badger-log-level: "error" storage-path: "/var/lib/pyroscope" api-bind-addr: ":4040" base-url: "" cache-dimension-size: "1000" cache-dictionary-size: "1000" cache-segment-size: "1000" cache-tree-size: "1000" badger-no-truncate: "false" max-nodes-serialization: "2048" max-nodes-render: "8192" hide-applications: "" out-of-space-threshold: "512.00 MB" sample-rate: "100" ``` <!-- /generate-sample-config -->
Project: Checkmk (Observability and Analysis / Observability)
File: 16627.md

key | value | date | 2024-04-03T10:30:30+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Before this update, configuring 'Volume parameters' in the PVC check plugin led to a crash. This issue arose because the plugin was not designed to process trend size-related levels, which, however, were anticipated by the general filesystem function handler shared among filesystem-related check plugins. To resolve this, the general function has been modified to bypass trend computation when a trend rule is not set, a scenario always applicable to the PVC check plugin.