cwielenb/CNCF-Dataset huggingface dataset:
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: gitlab.md

sidebar_position: 6 The will perform an HTTP Request to the GitLab API to get your flags. :::tip GitLab has rate limits, be sure to correctly set your `PollingInterval` to avoid reaching the limit. ::: ```go showLineNumbers err := ffclient.Init(ffclient.Config{ PollingInterval: 3 * time.Second, Retriever: &gitlab.Retriever{ RepositorySlug: "thomaspoignant/go-feature-flag", Branch: "main", FilePath: "testdata/flag-config.goff.yaml", GitlabToken: "XXXX", Timeout: 2 * time.Second, BaseURL: "https://gitlab.com", }, }) defer ffclient.Close() ``` To configure the access to your GitLab file: | Field | Description | |-|-| | `BaseURL` | (optional)<br/>The domain name of your Gitlab instance <br/>Default: https://gitlab.com | | `RepositorySlug` | Your Gitlab slug `org/repo-name`. | | `FilePath` | The path of your file. | | `Branch` | (optional)<br/>The branch where your file is.<br/>Default: `main` | | `GitlabToken` | (optional)<br/>GitLab token is used to access a private repository | | `Timeout` | (optional)<br/>Timeout for the HTTP call <br/>Default: 10 seconds |
Project: Grafana Tempo (Observability and Analysis / Observability)
File: v1-2.md

title: Version 1.2 release notes menuTitle: V1.2 description: Release notes for Grafana Tempo 1.2 weight: 100 The Tempo team is excited to announce the release of Tempo 1.2. This release introduces Tempo search. Recent traces search* The headline feature of Tempo 1.2 is the ability to search for data that is still in the ingester component. This experimental feature must be enabled using feature flags in both Grafana and Tempo. Refer to for details. Scalable monolithic deployment mode (formerly scalable single binary deployment mode)* The new deployment mode is operationally simpler, although less robust than a fully distributed deployment. We consider it a balanced operational mode that some may find attractive. Massive performance improvements* were achieved by more efficiently batching trace data being ingested. In terms of CPU needed, Tempo v1.2 is twice as efficient as Tempo v1.1. Refer to for details. API improvements* Some informational endpoints were consolidated within the . New endpoints were also added. When upgrading to Tempo v1.2, be aware of these changes: Support for v0 and v1 blocks were dropped as announced with Tempo v1.1. Refer to the for details. altered the Querier API. When upgrading components within a deployment, there will be a read outage until all queriers and query frontends have rolled to the upgraded version. API improvements consolidated informational endpoints within the . Metric `ingesterbytesmetrictotal` is renamed `ingesterbytesreceivedtotal` by . Metric `cortexruntimeconfiglastreloadsuccessful` is renamed `temporuntimeconfiglastreloadsuccessful` by . The `tempo-cli` flag `--storage.trace.maintenance-cycle` is renamed `-storage.trace.blocklist_poll` by . Honor the default values of configuration parameters `maxbytespertrace` and `maxsearchbytesper_trace`. (@BitProcessor) Reclassify the writing of empty traces to be a warning instead of an error. (@mdisibio) Fixed errors with magic numbers and other block mishandling when an ingester forcefully shuts down. (@mdisibio) Fixed a memory leak in the compactor component. (@mdisibio) Set a span's tag `span.kind` to `client` in query-frontend to allow query frontend spans to be paired with querier server spans. (@mapno) Metric `tempodbbackendhedgedroundtripstotal` now correctly counts hedged roundtrips. (@joe-elliott) Updated the `go-kit` logger package to remove spurious debug logs. (@bboreham)
Project: Netdata (Observability and Analysis / Observability)
File: 1m_bad_requests.md

This alert is triggered when the ratio of client error HTTP requests (4xx class status codes, excluding 401) within the last minute is higher than normal. Client errors indicate that the issue is on the client's side, such as incorrect requests or invalid URLs. Analyze response codes: Identify the specific HTTP response codes your web server is sending to clients. Use the Netdata dashboard and inspect the `detailedresponsecodes` chart for your web server to track the error codes being sent. Check server logs: Review the web server logs (e.g., access.log and error.log) to identify any issues, patterns, or errors causing the increase in client errors. These logs can typically be found under `/var/log/{nginx, apache2}/{access.log, error.log}`. Verify application behavior: Check the behavior of applications running on your web server to ensure they are not generating incorrect URLs or causing issues with client requests. Identify broken links: If there is a high number of 404 errors, use a broken link checker tool to identify and fix any dead links on your website or other websites that redirect to your website. Monitor server performance: Keep an eye on the web server's performance metrics to ensure that changes in client errors do not negatively impact server performance or resource usage.
Project: Loggie (Observability and Analysis / Observability)
File: UPGRADING.md

v4 is a complete rewrite with a focus on performance. Additionally, [doublestar] has been updated to use the new [io/fs] package for filesystem access. As a result, it is only supported by [golang] v1.16+. `Match()` and `PathMatch()` mostly did not change, besides big performance improvements. Their API is the same. However, note the following corner cases: In previous versions of [doublestar], `PathMatch()` could accept patterns that used either platform-specific path separators, or `/`. This was undocumented and didn't match `filepath.Match()`. In v4, both `pattern` and `name` must be using appropriate path separators for the platform. You can use `filepath.FromSlash()` to change `/` to platform-specific separators if you aren't sure. In previous versions of [doublestar], a pattern such as `path/to/a/*` would not match `path/to/a`. In v4, this pattern will match because if `a` was a directory, `Glob()` would return it. In other words, the following returns true: `Match("path/to/a/", "path/to/a")` `Glob()` changed from using a [doublestar]-specific filesystem abstraction (the `OS` interface) to the [io/fs] package. As a result, it now takes a `fs.FS` as its first argument. This change has a couple ramifications: Like `io/fs.Glob`, `pattern` must use a `/` as path separator, even on platforms that use something else. You can use `filepath.ToSlash()` on your patterns if you aren't sure. Patterns that contain `/./` or `/../` are invalid. The [io/fs] package rejects them, returning an IO error. Since `Glob()` ignores IO errors, it'll end up being silently rejected. You can run `path.Clean()` to ensure they are removed from the pattern. v4 also added a `GlobWalk()` function that is slightly more performant than `Glob()` if you just need to iterate over the results and don't need a string slice. You also get `fs.DirEntry` objects for each result, and can quit early if your callback returns an error. v3 introduced using `!` to negate character classes, in addition to `^`. If any of your patterns include a character class that starts with an exclamation mark (ie, `[!...]`), you'll need to update the pattern to escape or move the exclamation mark. Note that, like the caret (`^`), it only negates the character class if it is the first character in the character class. The change from v1 to v2 was fairly minor: the return type of the `Open` method on the `OS` interface was changed from `*os.File` to `File`, a new interface exported by doublestar. The new `File` interface only defines the functionality doublestar actually needs (`io.Closer` and `Readdir`), making it easier to use doublestar with [go-billy], [afero], or something similar. If you were using this functionality, updating should be as easy as updating `Open's` return type, since `os.File` already implements `doublestar.File`. If you weren't using this functionality, updating should be as easy as changing your dependencies to point to v2.
Project: Checkmk (Observability and Analysis / Observability)
File: 16501.md

key | value | date | 2024-02-29T13:06:16+00:00 version | 2.4.0b1 class | feature edition | cre component | rest-api level | 1 compatible | yes Werk 15724 introduces a mechanism for regenerating the API specification, which, in certain instances, is executed as a background job due to the potential time required for completion. This update introduces a command to trigger the background job for the regeneration of the API specification. Users should be aware that triggering the job does not result in immediate availability of the updated documentation; there may be a delay before the documentation is updated. This saves the user from having to trigger and wait for the specification regeneration manually.
Project: Krkn (Observability and Analysis / Chaos Engineering)
File: cluster_shut_down_scenarios.md

Scenario to shut down all the nodes including the masters and restart them after specified duration. Cluster shut down scenario can be injected by placing the shutdown config file under clustershutdownscenario option in the kraken config. Refer to config file. Refer to to configure your cli properly for the cloud provider of the cluster you want to shut down. Current accepted cloud types: ``` clustershutdown_scenario: # Scenario to stop all the nodes for specified duration and restart the nodes. runs: 1 # Number of times to execute the clustershutdown scenario. shutdownduration: 120 # Duration in seconds to shut down the cluster. cloud_type: aws # Cloud type on which Kubernetes/OpenShift runs. ```
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: probe-chaining.md

Probe chaining enables reuse of probe a result (represented by the template function `{{ .<probeName>.probeArtifact.Register}})` in subsequent "downstream" probes defined in the ChaosEngine. `Note`: The order of execution of probes in the experiment depends purely on the order in which they are defined in the ChaosEngine. Use the following example to tune this: ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: "active" appinfo: appns: "default" applabel: "app=nginx" appkind: "deployment" chaosServiceAccount: pod-delete-sa experiments: name: pod-delete spec: probe: name: "probe1" type: "cmdProbe" cmdProbe/inputs: command: "<command>" comparator: type: "string" criteria: "equals" value: "<value-for-criteria-match>" source: "inline" mode: "SOT" runProperties: probeTimeout: 5 interval: 5 retry: 1 name: "probe2" type: "cmdProbe" cmdProbe/inputs: command: "<commmand> {{ .probe1.ProbeArtifacts.Register }} <arg2>" comparator: type: "string" criteria: "equals" value: "<value-for-criteria-match>" source: "inline" mode: "SOT" runProperties: probeTimeout: 5 interval: 5 retry: 1 ```
Project: Grafana Mimir (Observability and Analysis / Observability)
File: trafficdump.md

Trafficdump is a tool that can read packets from captured `tcpdump` output, reassemble them into TCP streams and parse HTTP requests and responses. It then prints requests and responses as JSON (one request/response per line) for further processing. Trafficdump can only parse "raw" HTTP requests and responses, and not HTTP requests and responses wrapped in gRPC, as used by Grafana Mimir between some components. The best place to capture such traffic is on the entrypoint to Grafana Mimir (e.g. authentication gateway/proxy). It has some Grafana Mimir-specific and generic HTTP features: filter requests based on Tenant (in Basic or X-Scope-OrgId header) filter requests based on URL path filter requests based on status code of the response decode Grafana Mimir push requests filter requests based on matching series in push requests Trafficdump can be used to inspect both remote-write requests and queries. Trafficdump requires that the pcap library be installed prior to tool compilation. The following are examples for installing the prerequisite pcap library: `sudo apt install libpcap-dev` : Ubuntu and its derivatives `dnf install libpcap-devel` : Fedora, CentOS, Red Hat Once libpcap is installed, build the `trafficdump` binary in the `tools/trafficdump` directory: ```shell cd mimir/tools/trafficdump make ``` If the build is successful the `trafficdump` binary will be in the same directory. You can list the tool's options with `./trafficdump -h`. Note that Trafficdump currently cannot decode `LINUX_SSL2` link type, which is used when doing `tcpdump -i any` on Linux. Capturing traffic with `tcpdump -i eth0` (and link type ETHERNET / EN10MB) works fine.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: infracloud.md

InfraCloud Technologies is a Kubernetes focused B2B Open Source Cloud Native Computing company which has been building products, services, and solutions to modernize applications and infrastructure. InfraCloud was one of the first Kubernetes partners and have been contributing to the open source community around cloud-native technologies. It has been growing almost 100% for last few years consistently. Company website: https://www.infracloud.io/ Company GitHub: https://github.com/infracloudio At InfraCloud, we are using Litmus to develop Resiliency Frameworks. To simulate various Chaos scenarios using fault injection templates provided by Litmus. Litmus also helps to incorporate custom fault templates developed using AWS SSM documents. Currently, we have tested with different kind of scenarios including faults like pod deletion, network latency, resource stressing, network partitioning in databases, and many more. Easy deployment. Easy Fault injection. Custom Grading for experiments SSM integration helps to inject fault in both EKS and external AWS components.
Project: Checkmk (Observability and Analysis / Observability)
File: 16550.md

key | value | date | 2024-03-12T09:14:38+00:00 version | 2.4.0b1 class | fix edition | cee component | agents level | 1 compatible | yes In the ruleset Remote alert handlers (Linux), you have to specify a user under that the remote alert handler will be executed on agent side. This user is set to root by default, but it's possible to choose an arbitrary user. But, when choosing a non-root user, the alert handlers previously failed to execute, because the handler files got deployed with root-ownership and were not readable by others. To fix the problem, the ownership of the files now get changed to the specified user. Security note: In general, it's important that all internal files of the Checkmk agent have root ownership, as they might be read/executed by the Checkmk agent under root. However, this is not the case for remote alert handlers, as they always get executed under the specified user. As an additional security measure, the dispatcher on agent side checks the ownership of installed remote alert handlers, and refuses to execute non-root owned handlers when called via SSH with root rights.
Project: Checkmk (Observability and Analysis / Observability)
File: 16410.md

key | value | date | 2024-03-12T15:30:46+00:00 version | 2.4.0b1 class | fix edition | cre component | omd level | 1 compatible | yes This bug affects users of the 2.3.0 beta. In Werk #16408 a mechanism was introduced to restore a site after an aborted update. If this mechanism triggered inside a docker container, then the site may be in an inconsistent state. Any further update will show the following error. ``` FileNotFoundError: [Errno 2] No such file or directory: '/omd/versions/2.3.0b1.cee/share/omd/skel.permissions' ``` You can check whether you are affected by this issue by comparing the output of `omd update` and `cat "${OMDROOT}"/.versionmeta/version`. If the versions do not match, then you are affected by this issue. This Werk fixes the update procedure. In case you are affected, you can delete `.version_meta` and upgrade to the version which is shown by `omd update`.
Project: VictoriaMetrics (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. We have full documentation on how to get started contributing here: 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 - We have a diverse set of mentorship programs available that are always looking for volunteers!
Project: SkyWalking (Observability and Analysis / Observability)
File: dynamic-config-apollo.md

is also supported as a Dynamic Configuration Center (DCC). To use it, please configure it as follows: ```yaml configuration: selector: ${SW_CONFIGURATION:apollo} apollo: apolloMeta: ${SWCONFIGAPOLLO:http://localhost:8080} apolloCluster: ${SWCONFIGAPOLLO_CLUSTER:default} apolloEnv: ${SWCONFIGAPOLLO_ENV:""} appId: ${SWCONFIGAPOLLOAPPID:skywalking} ``` Single configs in Apollo are key/value pairs: | Key | Value | |--|--| | configKey | configValue | e.g. The config is: ``` {agent-analyzer.default.slowDBAccessThreshold}:{default:200,mongodb:50} ``` The config in Apollo is: | Key | Value | |--|--| | agent-analyzer.default.slowDBAccessThreshold | default:200,mongodb:50 | | ... | ... | Group config in Apollo are key/value pairs as well, and the key is composited by configKey and subItemKey with `.`. | Key | Value | |--|--| | configKey.subItemkey1 | subItemValue1 | | configKey.subItemkey2 | subItemValue2 | | ... | ... | e.g. The config is: ``` {core.default.endpoint-name-grouping-openapi}:|{customerAPI-v1}:{value of customerAPI-v1} |{productAPI-v1}:{value of productAPI-v1} |{productAPI-v2}:{value of productAPI-v2} ``` The config in Apollo is: | Key | Value | |--|--| | core.default.endpoint-name-grouping-openapi.customerAPI-v1 | value of customerAPI-v1 | | core.default.endpoint-name-grouping-openapi.productAPI-v1 | value of productAPI-v1 | | core.default.endpoint-name-grouping-openapi.productAPI-v2 | value of productAPI-v2 |
Project: Checkmk (Observability and Analysis / Observability)
File: 16486.md

key | value | date | 2024-03-13T14:44:24+00:00 version | 2.4.0b1 class | feature edition | cre component | multisite level | 1 compatible | yes The default setting for "Enable community translated languages" was previously disabled. It is now enabled by default. The names of the community translated languages have also been changed.
Project: Checkmk (Observability and Analysis / Observability)
File: 16657.md

key | value | date | 2024-03-26T15:44:17+00:00 version | 2.4.0b1 class | feature edition | cre component | rest-api level | 1 compatible | yes This werk adds the columns parameter to the single serivce status endpoint. This parameter already exists for the other service status endpoints, with the same behaviour. By default, the same columns as before are returned.
Project: SkyWalking (Observability and Analysis / Observability)
File: browser-protocol.md

Browser protocol describes the data format between and the backend. Browser protocol is defined and provided in , and also implemented in You can send performance data and error logs using the following services: `BrowserPerfService#collectPerfData` for performance data format. `BrowserPerfService#collectErrorLogs` for error log format. For error log format, note that: `BrowserErrorLog#uniqueId` should be unique in all distributed environments.
Project: Sensu (Observability and Analysis / Observability)
File: bug_template.md

name: 'Bug report' about: 'Create bug report' <! Provide a general summary of the issue in the Title above --> <! If you're looking for help, please see https://sensu.io/support/ for resources > <! Tell us what should happen --> <! Tell us what happens instead of the expected behavior --> <! Not obligatory, but suggest a fix/reason for the bug, --> <! or ideas as to the implementation of the addition or change --> <! Provide a link to a live example, or an unambiguous set of steps to --> <! reproduce this bug. Include code or configuration to reproduce, if relevant --> <! How has this issue affected you? What are you trying to accomplish? --> <! Providing context (e.g. links to configuration settings, stack strace or log data) helps us come up with a solution that is most useful in the real world --> <! Include as many relevant details about the environment you experienced the bug in --> Sensu version used (sensuctl, sensu-backend, and/or sensu-agent): Installation method (packages, binaries, docker etc.): Operating System and version (e.g. Ubuntu 14.04):
Project: Netdata (Observability and Analysis / Observability)
File: synproxy.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/integrations/synproxy.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/metadata.yaml" sidebar_label: "Synproxy" learn_status: "Published" learnrelpath: "Collecting Metrics/Linux Systems/Firewall" 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/firewall.svg" width="150"/> Plugin: proc.plugin Module: /proc/net/stat/synproxy <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> This integration provides statistics about the Synproxy netfilter module. This collector is supported on all platforms. This collector supports collecting metrics from multiple instances of this integration, including remote instances. 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 | |:|:-|:-| | netfilter.synproxysynreceived | received | packets/s | | netfilter.synproxyconnreopened | reopened | connections/s | | netfilter.synproxy_cookies | valid, invalid, retransmits | cookies/s | 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.