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

key | value | date | 2024-01-22T08:18:31+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes Previous to this werk, when creating a notification rule with a custom plugin via the rest-api, the parameters were not being shown in the UI as expected. The reason being, an incorrect format being saved to file. This werk addresses this issue by correcting the format being saved to file.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: encrypting-data-at-rest.md

aliases: ../../operators-guide/securing/encrypting-data-at-rest/ ../../operators-guide/secure/encrypting-data-at-rest/ description: Learn how to configure object storage encryption. menuTitle: Encrypting data at rest title: Encrypting Grafana Mimir data at rest weight: 30 Grafana Mimir supports encrypting data at rest in object storage using server-side encryption (SSE). Configuration of SSE depends on your storage backend. Google Cloud Storage (GCS) encrypts data before writing it to disk. SSE is enabled by default and you cannot turn it off. For more information about GCS encryption at rest, refer to . Grafana Mimir requires no additional configuration to use GCS with SSE. Configuring SSE with AWS S3 requires configuration in the Grafana Mimir S3 client. The S3 client is only used when the storage backend is `s3`. Grafana Mimir supports the following AWS S3 SSE modes: You can configure AWS S3 SSE globally or for specific tenants. Configuring AWS S3 SSE globally requires setting SSE for each of the following storage backends: For more information about AWS S3 SSE configuration parameters, refer to . The following code sample shows a snippet of a Grafana Mimir configuration file with every backend storage configured to use AWS S3 SSE with and Amazon S3-managed key. ```yaml alertmanager_storage: backend: "s3" s3: sse: type: "SSE-S3" blocks_storage: backend: "s3" s3: sse: type: "SSE-S3" ruler_storage: backend: "s3" s3: sse: type: "SSE-S3" ``` You can use the following settings to override AWS S3 SSE for each tenant: `s3_sse_type`<br /> S3 server-side encryption type. This setting must be applied to enable the SSE configuration override for a given tenant. `s3_sse_kms_key_id`<br /> S3 server-side encryption KMS Key ID. This setting is ignored if the SSE type override is not set or the type is not `SSE-KMS`. `s3_sse_kms_encryption_context`<br /> S3 server-side encryption KMS encryption context. If this setting is not applied, and the key ID override is set, the encryption context is not be provided to S3. This setting is ignored if the SSE type override is not set or the type is not `SSE-KMS`. To configure AWS S3 SSE for a specific tenant: Ensure Grafana Mimir uses a runtime configuration file by verifying that the flag `-runtime-config.file` is set to a non-null value. For more information about supported runtime configuration parameters, refer to . In the runtime configuration file, apply the `overrides.<TENANT>` SSE settings. A partial runtime configuration file that has AWS S3 SSE with Amazon S3-managed keys set for a tenant called "tenant-a" appears as follows: ```yaml overrides: "tenant-a": s3ssetype: "SSE-S3" ``` Save and deploy the runtime configuration file. After the `-runtime-config.reload-period` has elapsed, components reload the runtime configuration file and use the updated configuration. Other storage backends might support encryption at rest if it is configured at the storage level.
Project: Grafana Loki (Observability and Analysis / Observability)
File: release.md

The `yaml` Project is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
Project: Sensu (Observability and Analysis / Observability)
File: README.md

`sensuctl` is the command line interface for managing your Sensu cluster. Make sure bash completion is installed. If you use a current Linux in a non-minimal installation, bash completion should be available. On a Mac, install with: ```sh brew install bash-completion ``` Then add the following to your `~/.bash_profile`: ```bash if [ -f $(brew --prefix)/etc/bash_completion ]; then . $(brew --prefix)/etc/bash_completion fi ``` On Ubuntu, install with: ```sh apt update && apt install bash-completion ``` Then add the following to your `~/.bash_profile`: ```bash if [ -f /usr/share/bash-completion/bash_completion ]; then . /usr/share/bash-completion/bash_completion elif [ -f /etc/bash_completion ]; then . /etc/bash_completion fi ``` When bash-completion is available we can add the following to your `~/.bash_profile`: ```bash source <(sensuctl completion bash) ``` You can now source your `~/.bash_profile` or launch a new terminal to utilize completion. ```sh source ~/.bash_profile ``` Add the following to your `~/.zshrc`: ```bash source <(sensuctl completion zsh) ``` You can now source your `~/.zshrc` or launch a new terminal to utilize completion. ```sh source ~/.zshrc ``` sensuctl: $ sensuctl <kbd>Tab</kbd> ``` check configure event user asset completion entity handler ``` sensuctl: $ sensuctl check <kbd>Tab</kbd> ``` create delete import list ```
Project: Vector (Observability and Analysis / Observability)
File: 2022-12-22-enhanced-metric-tags.md

date: "2022-12-22" title: "Enhanced Metric Tags" description: "The metric data model now supports an enhanced representation of tag values" authors: ["bruceg"] pr_numbers: [14742] release: "0.27.0" hideonrelease_notes: false badges: type: enhancement The existing set of tags that have been available on metrics was a simple mapping of string values to single string keys. Some sources, however, may produce metrics that contain tags that don't fit into this model, such as tags that are bare strings (rather than a key/value pair) or have multiple values for a given key. With this release, tag values for a given key may now contain a set of values, each of which may be a string value or `null`, which represents a "bare" tag (i.e. a tag with no value, as distinct from an empty string value). This new tag set only stores unique values, as duplicated tags are not useful for any component, and so each tag name/value pair will appear only once across all tags. For compatibility with previous releases, this value set also tracks the last seen or assigned value for each tag. Since most components, in particular sinks, can only make use of a single value for each tag, this last value is used by those components. The scripting components of `lua` and `remap` have been extended with a configuration option of `metrictagvalues`. This controls how these tag values are exposed to scripts. In the default setting of `single`, tag values will be exposed as the single value described above. This behavior matches the existing behavior of scripts so that no script changes will be needed. When set to `full`, however, all tag values are exposed as an array for each element. In either case, scripts may assign either a single value or an array of values to a tag. For example: ```coffee .tags.host = "localhost" # Assign a single string value .tags.bare = null # Create a single-valued bare tag .tags.complex = ["remotehost", null, "otherhost"] # Creates three tag values ``` This `metrictagvalues` setting also shows up in the `codec` configuration of sinks and controls how metric tags are exposed in codecs that can encode metrics. As above, when set to `full`, these codecs will expose all values of tags either as arrays (for the `json` codec) or as repeated instances of each tag (for the `text` codec). This setting does not apply to the `native` and `nativejson` codecs which always_ expose all tag values in order to seamlessly transport the values to other Vector instances.
Project: Beats (Observability and Analysis / Observability)
File: CONTRIBUTING.md

Please see the main file, and consider the following notes: If you are planning to add a new protocol, please read our [developer guide for adding new protocols](https://www.elastic.co/guide/en/beats/devguide/current/new-protocol.html) Packetbeat uses Cgo, so in addition to having Go installed you need a C compiler Packetbeat depends on libpcap. You need to install libpcap-dev on Debian based systems or libpcap-devel on RedHat based systems. On Windows, you need winpcap.
Project: Krkn (Observability and Analysis / Chaos Engineering)
File: test_your_changes.md

Scenario Types: pod-scenarios node-scenarios zone-outages time-scenarios cluster-shutdown container-scenarios node-cpu-hog node-io-hog node-memory-hog application-outages Create folder under with name pertinent to your scenario name. Create a python file that will have a generic run function to be the base of your scenario. a. See for example. Add in a scenario yaml file to run your specific scenario under . a. Try to add as many parameters as possible and be sure to give them default values in your run function. Add all functionality and helper functions in file you made above (Step 2). Add in caller to new scenario type in (around line 154). a. This will also require you to add the new scenario python script to your imports. Add scenario type and scenario yaml to the scenario list in and . Update this doc and main README with new scenario type. Add CI test for new scenario. a. Refer to test for more details. Once all you are happy with your changes, follow the guide on how to create your own branch and squash your commits.
Project: Checkmk (Observability and Analysis / Observability)
File: 16047.md

key | value | date | 2024-01-26T12:20:23+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | no This werk affects users who use the tags of Azure Resource Groups or Virtual Machines (if monitored as hosts) as host labels in Checkmk. The host labels are renamed from the original Azure format "{key}":"{value}" to "cmk/azure/tag/{key}":"{value}" in order to stay consistent with other host labels and to avoid overwriting existing Checkmk labels. Additionally, label keys and values are now validated to 1) not hold empty values - empty values are replaced by "true" and 2) not contain colons (":") - colons are replaced by underscores (""). So a former label "label:key":"" will now be shown as "labelkey":"true". The old labels will be removed in version 2.4.0.
Project: Kubecost (Observability and Analysis / Continuous Optimization)
File: opencost-bug-report.md

name: OpenCost Bug report about: Create a report to help us improve title: '' labels: '' assignees: '' Describe the bug A clear and concise description of what the OpenCost bug is. Please ensure this is an issue related to the OpenCost cost model, API or specification. UI issues may be opened in the . To Reproduce Steps to reproduce the behavior: Go to '...' Click on '....' Scroll down to '....' See error Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Which version of OpenCost are you using? You can find the version from the container's startup logging or from the bottom of the page in the UI. Additional context Add any other context about the problem here. Kubernetes versions and which public clouds you are working with are especially important.
Project: Netdata (Observability and Analysis / Observability)
File: netfilter_conntrack_full.md

This alert presents the percentage of used netfilter tracked connections. If you receive this alert, there is high utilization of the netfilter "connection tracking state" table size. Network delays and packet drops are expected when you are getting closer to 100%. This alert gets raised to warning when the percentage exceeds 90%. If the metric exceeds 95%, then the alert gets raised to a critical state. Netfilter is a framework provided by the Linux kernel that allows various networking-related operations to be implemented in the form of customized handlers. Netfilter offers various functions and operations for packet filtering, network address translation, and port translation, which provide the functionality required for directing packets through a network and prohibiting packets from reaching sensitive locations within a network. Table Size Limits You can see the table size by running: ``` cat /proc/sys/net/netfilter/nfconntrackcount ``` You can see the table size limit by running: ``` cat /proc/sys/net/netfilter/nfconntrackmax ``` Recommended Size: CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (ARCH / 32). Eg, If we have 8GB RAM in a x86_64 OS, we would use 8*1024^3/16384/2=262144. You can modify the table size limit by running: ``` sysctl -w net.netfilter.nfconntrackmax=<YOUR DESIRED LIMIT HERE> echo "net.netfilter.nfconntrackmax=<YOUR DESIRED LIMIT HERE>" >> /etc/sysctl.conf ```
Project: Grafana (Observability and Analysis / Observability)
File: support-bundles.md

Support bundles are a way to collect all the information needed to debug a problem. They are generated from the support bundle menu in the UI under the Help section. The support bundle is an archive that contains one file per collector selected by the user. Collectors are functions in the backend that collect information about the service they are running in. Services can register collectors during their initialization. To add a new support bundle collector, you need to follow these steps, we'll use the usage stats service as an example: Import the support bundles registry in the service's `ProvideService` function: ```go type UsageStats struct { ... } func ProvideService( ... bundleRegistry supportbundles.Service, // Bundle registry ) (*UsageStats, error) ``` `make gen-go` will then be able to wire the registry to the service. Implement the collector ```go func (uss *UsageStats) supportBundleCollector() supportbundles.Collector { return supportbundles.Collector{ UID: "usage-stats", // unique ID for the collector DisplayName: "Usage statistics", // display name for the collector in the UI Description: "Usage statistics of the Grafana instance", // description for the collector in the UI IncludedByDefault: false, // whether the collector is included by default in the support bundle and can't be deselected. Most times you want this to be false. Default: false, // whether the collector is selected by default in the support bundle. User can still deselect it. // Function that will actually collect the file during the support bundle generation. Fn: func(ctx context.Context) (*supportbundles.SupportItem, error) { // Add your service's logic to collect the information you need // In this example we are collecting the usage stats and marshalling them to JSON // This helps us get information about the usage of the Grafana instance report, err := uss.GetUsageReport(context.Background()) if err != nil { return nil, err } data, err := json.Marshal(report) if err != nil { return nil, err } return &supportbundles.SupportItem{ // filename of the file in the archive // can be any extension. (most common is .json and .md) Filename: "usage-stats.json", FileBytes: data, // []byte of the file }, nil }, } } ``` Register the collector in the service's `ProvideService` function: ```go func ProvideService( ... ) (*UsageStats, error) { s := &UsageStats{ // ... } bundleRegistry.RegisterSupportItemCollector(s.supportBundleCollector()) return s, nil } ```
Project: Micrometer (Observability and Analysis / Observability)
File: NOTES.md

Support triggering on one query, sending alert notifications on another. One is to discover a problem exists, the other to provide actionable insight quickly. Alert queries are often instance bound, e.g. `:group-by` instance to generate a signal per instance. Healthy instances will tend to cluster together in a mass of color, and the bad instance(s) will be visibly divergent. Look at `:rolling-count`. Most canaries run 1-4 hours. Extreme cases run 96 hours. Shorter windows are recommended, as bad canaries are receiving production traffic -- should be failed as soon as possible. ACA at Netflix is approaching limits on how many queries it is allowed to perform against Atlas in a given window. To improve, could combine queries to baseline and canary in one and split the results in ACA. Also, may be able to use LWC streaming? Good canary metrics include box level metrics, error counting metrics with sufficient volume to present a statistically viable comparison. Because a normal distribution cannot be assumed, uses Mann-Whitney U Test. Use canary analysis to inform alerts -- if a canary is critically failing, even if it only lasts 4 hours, shouldn't somebody have been alerted on failures before? Good ACA criteria = U.S.E. = Utilization, Saturation, Error (Brendan Gregg) Some teams basing ACAs off of high-dimension data stored in Druid. Look at `:dist-max` when concerned about the absolute max in a given window. The `max` statistic shown on a graph is the maximum value that the plot yields, but this may be the max average value if the plot is `:avg`, for example. `:dist-max` plots the maximum sample at each step. So, `max` of `:dist-max` is the maximum sample seen along the plot's x-axis. Constant-time lookup function on buckets is important. Bucket functions lead to a mergeable quantile approximation. There may be a static 276 bucket histogram that leads to good error bounds on quantile approximation for majority of use cases. Standard deviation calculation often exhibits high error bounds because of cliffs: Left-side cliff on payload size that represents minimum header size Right-side cliff on latency that represents HTTP timeout For a latency timer across all endpoints in an app, distribution can be wildly non-normal because of different levels of computation and I/O across those endpoints. Say no to t-digests. Counters not decrementable Look at `:cq`, `:list`, `:each` for an easy way to tack on additional criteria from a dashboard-building app without understanding the existing structure of the query. `:dist-avg` does the `totalTime/count` division math for you. r3.2xlg with 60GB RAM capable of managing 2M time series over 6 hours.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: automatic-logging.md

title: 'Automatic logging: Trace discovery through logs' description: Automatic logging provides an easy and fast way of getting trace discovery through logs. menuTitle: Automatic logging weight: 200 aliases: /docs/tempo/grafana-agent/automatic-logging Running instrumented distributed systems is a very powerful way to gain understanding over a system, but it brings its own challenges. One of them is discovering which traces exist. In the beginning of Tempo, querying for a trace was only possible if you knew the ID of the trace you were looking for. One solution was automatic logging. Automatic logging provides an easy and fast way of discovering trace IDs through log messages. Well-formatted log lines are written to a Loki instance or to `stdout` for each span, root, or process that passes through the tracing pipeline. This allows for automatically building a mechanism for trace discovery. On top of that, we also get metrics from traces using Loki, and allow quickly jumping from a log message to the trace view in Grafana. While this approach is useful, it isn't as powerful as [TraceQL]({{< relref "../../traceql" >}}). If you are here because you know you want to log the trace ID, to enable jumping from logs to traces, then read on! If you want to query the system directly, read the [TraceQL documentation]({{< relref "../../traceql" >}}). For high throughput systems, logging for every span may generate too much volume. In such cases, logging per root span or process is recommended. <p align="center"><img src="../automatic-logging.png" alt="Automatic logging overview"></p> Automatic logging searches for a given set of attributes in the spans and logs them as key-value pairs. This allows searching by those key-value pairs in Loki. To configure automatic logging, you need to select your preferred backend and the trace data to log. To see all the available config options, refer to the . This simple example logs trace roots to stdout and is a good way to get started using automatic logging: ```yaml traces: configs: name: default ... automatic_logging: backend: stdout roots: true ``` This example pushes logs directly to a Loki instance also configured in the same Grafana Agent. ```yaml traces: configs: name: default ... automatic_logging: backend: logs_instance logsinstancename: default roots: true ``` <p align="center"><img src="../automatic-logging-example-query.png" alt="Automatic logging overview"></p> <p align="center"><img src="../automatic-logging-example-results.png" alt="Automatic logging overview"></p>
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: DOCKERHUB_thomaspoignant.md

<span style="color: red"> Attention: The GO Feature Flag has now transitioned to its own organization. We recommend updating your configurations to use . We will continue to provide support for the original organization for a certain period of time.</span> The migration command line purpose is to migrate your configuration file from the flag format in version `v0.x.x` to the format `v1.x.x`. We changed the format to extend the capabilities of GO Feature Flag, despite that the old format will still be supported, it is better to update your configuration file. ```shell docker run \ -v $(pwd)/your/configuration_folder:/config \ gofeatureflag/go-feature-flag-migration-cli:latest \ --input-format=yaml \ --input-file=/config/my-go-feature-flag-config-v0.x.x.yaml \ --output-format=yaml \ --output-file=/config/my-go-feature-flag-config-v1.x.x.yaml ``` The command line has 4 parameters: | param | description | |-|| | `--input-file` | (mandatory) The location of your configuration file in version `v0.x.x`. | | `--input-format` | (mandatory) The format of your current configuration file.<br/>Available formats are `yaml`, `json`, `toml`. | | `--output-file` | (optional) The location where the new configuration file will be stored in version `v1.x.x`.<br/>If omitted the configuration will be output in the console. | | `--output-format` | (optional) The target format of the configuration.<br/>Available formats are `yaml`, `json`, `toml`. <br/>If omitted `yaml` will be used. | /go-feature-flag/issues/new?assignees=&labels=bug%2C+relay-proxy%2C+docker%2C+needs-triage&template=bug.md&title=(bug%20docker)). Source are available in . All versions are available in the . Release notes are available . `go-feature-flag` requires a configuration file to be used. By default, we expect to have this configuration file in the `/goff` directory of the container and the file should be named `goff-proxy.yaml`. The default port used for the service is `1031`. ```shell docker run \ -v $(pwd)/goff-proxy.yaml:/goff/goff-proxy.yaml \ thomaspoignant/go-feature-flag:latest ``` This is a small example on how to run `go-feature-flag` locally. ```shell curl https://raw.githubusercontent.com/thomaspoignant/go-feature-flag/main/cmd/relayproxy/testdata/config/valid-file.yaml -o goff-proxy.yaml docker run \ -p 1031:1031 \ -v $(pwd)/goff-proxy.yaml:/goff/goff-proxy.yaml \ thomaspoignant/go-feature-flag:latest curl -X 'POST' \ 'http://localhost:1031/v1/feature/flag-only-for-admin/eval' -H 'accept: application/json' -H 'Content-Type: application/json' \ -d '{ "user": { "key": "contact@gofeatureflag.org", "anonymous": true, "custom": { "admin": true, "email": "contact@gofeatureflag.org" }}, "defaultValue": "false"}' ``` View information for the software contained in this image. This project is open for contribution, see the for some helpful tips.