cwielenb/CNCF-Dataset huggingface dataset:
Project: SkyWalking (Observability and Analysis / Observability)
File: project-goals.md

This document outlines the core design goals for the SkyWalking project. Maintaining Observability. Regardless of the deployment method of the target system, SkyWalking provides an integration solution for it to maintain observability. Based on this, SkyWalking provides multiple runtime forms and probes. Topology, Metrics and Trace Together. The first step to understanding a distributed system is the topology map. It visualizes the entire complex system in an easy-to-read layout. Under the topology, the OSS personnel have higher requirements in terms of the metrics for service, instance, endpoint and calls. Traces are in the form of detailed logs to make sense of those metrics. For example, when the endpoint latency becomes long, you want to see the slowest the trace to find out why. So you can see, they are from big picture to details, they are all needed. SkyWalking integrates and provides a lot of features to make this possible and easy understand. Light Weight. There two parts of light weight are needed. (1) In probe, we just depend on network communication framework, prefer gRPC. By that, the probe should be as small as possible, to avoid the library conflicts and the payload of VM, such as permsize requirement in JVM. (2) As an observability platform, it is secondary and third level system in your project environment. So we are using our own light weight framework to build the backend core. Then you don't need to deploy big data tech platform and maintain them. SkyWalking should be simple in tech stack. Pluggable. SkyWalking core team provides many default implementations, but definitely it is not enough, and also don't fit every scenario. So, we provide a lot of features for being pluggable. Portability. SkyWalking can run in multiple environments, including: (1) Use traditional register center like eureka. (2) Use RPC framework including service discovery, like Spring Cloud, Apache Dubbo. (3) Use Service Mesh in modern infrastructure. (4) Use cloud services. (5) Across cloud deployment. SkyWalking should run well in all of these cases. Interoperability. The observability landscape is so vast that it is virtually impossible for SkyWalking to support all systems, even with the support of its community. Currently, it supports interoperability with other OSS systems, especially probes, such as Zipkin, Jaeger, and OpenTelemetry. It is very important to end users that SkyWalking has the ability to accept and read these data formats, since the users are not required to switch their libraries. See to learn about SkyWalking's probe groups. From , you can understand what the backend does after it receives probe data.
Project: Tracetest (Observability and Analysis / Observability)
File: tracetest_start.md

Start Tracetest Start using Tracetest ``` tracetest start [flags] ``` ``` --api-key string agent api key --collector-endpoint string address of the OTel Collector endpoint --environment string environment id -h, --help help for start -l, --log-level string set the agent log level (default "debug") -m, --mode string set how the agent will start (default "desktop") --organization string organization id --token string token authentication key ``` ``` -c, --config string config file will be used by the CLI (default "config.yml") -o, --output string output format [pretty|json|yaml] -s, --server-url string server url -v, --verbose display debug information ``` - CLI to configure, install and execute tests on a Tracetest server
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: tls.md

title: TLS config for syslog-ng outputs weight: 200 generated_file: true More info at https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.37/administration-guide/32#kanchor2338 The name of a directory that contains a set of trusted CA certificates in PEM format. Default: - The name of a file that contains a set of trusted CA certificates in PEM format. (Optional) Default: - The name of a file that contains an unencrypted private key in PEM format, suitable as a TLS key. Default: - Name of a file, that contains an X.509 certificate (or a certificate chain) in PEM format, suitable as a TLS certificate, matching the private key set in the key-file() option. Default: - Verification method of the peer. Default: - Use the certificate store of the system for verifying HTTPS certificates. Default: -
Project: Prometheus (Observability and Analysis / Observability)
File: prettier_rules.md

This files contains rules for prettifying PromQL expressions. Note: The current version of prettier does not preserve comments. `maxcharactersper_line`: Maximum number of characters that will be allowed on a single line in a prettified PromQL expression. A node exceeding the `maxcharactersper_line` will qualify for split unless It is a `MatrixSelector` It is a `VectorSelector`. Label sets in a `VectorSelector` will be in the same line as metric_name, separated by commas and a space Note: Label groupings like `by`, `without`, `on`, `ignoring` will remain on the same line as their parent node Nodes that are nested within another node will be prettified only if they exceed the `maxcharactersper_line` Expressions like `sum(expression) without (labelmatchers)` will be modified to `sum without(labelmatchers) (expression)` Functional call args will be split to different lines if they exceed the `maxcharactersper_line`
Project: Checkmk (Observability and Analysis / Observability)
File: 16756.md

key | value | date | 2024-04-23T06:37:18+00:00 version | 2.4.0b1 class | feature edition | cre component | rest-api level | 1 compatible | no This werk introduces the flag 'include_links' for the 'Show all hosts' host config endpoint. It toggles whether the links field should be populated of the individual hosts. This serves as a mechanism to reduce the payload generated. This field defaults to False and existing scripts therefore have to be adjusted accordingly.
Project: Prometheus (Observability and Analysis / Observability)
File: installation.md

title: Installation sort_rank: 2 We provide precompiled binaries for most official Prometheus components. Check out the for a list of all available versions. For building Prometheus components from source, see the `Makefile` targets in the respective repository. All Prometheus services are available as Docker images on or . Running Prometheus on Docker is as simple as `docker run -p 9090:9090 prom/prometheus`. This starts Prometheus with a sample configuration and exposes it on port 9090. The Prometheus image uses a volume to store the actual metrics. For production deployments it is highly recommended to use a to ease managing the data on Prometheus upgrades. To provide your own configuration, there are several options. Here are two examples. Bind-mount your `prometheus.yml` from the host by running: ```bash docker run \ -p 9090:9090 \ -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml \ prom/prometheus ``` Or bind-mount the directory containing `prometheus.yml` onto `/etc/prometheus` by running: ```bash docker run \ -p 9090:9090 \ -v /path/to/config:/etc/prometheus \ prom/prometheus ``` Prometheus data is stored in `/prometheus` dir inside the container, so the data is cleared every time the container gets restarted. To save your data, you need to set up persistent storage (or bind mounts) for your container. Run Prometheus container with persistent storage: ```bash docker volume create prometheus-data docker run \ -p 9090:9090 \ -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml \ -v prometheus-data:/prometheus \ prom/prometheus ``` To avoid managing a file on the host and bind-mount it, the configuration can be baked into the image. This works well if the configuration itself is rather static and the same across all environments. For this, create a new directory with a Prometheus configuration and a `Dockerfile` like this: ```Dockerfile FROM prom/prometheus ADD prometheus.yml /etc/prometheus/ ``` Now build and run it: ```bash docker build -t my-prometheus . docker run -p 9090:9090 my-prometheus ``` A more advanced option is to render the configuration dynamically on start with some tooling or even have a daemon update it periodically. If you prefer using configuration management systems you might be interested in the following third-party contributions:
Project: Checkmk (Observability and Analysis / Observability)
File: 16647.md

key | value | date | 2024-03-22T09:19:58+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes This only affects some beta users that tested the new ruleset API for plugin development. When migrating and scaling fixed levels to the new `Levels` form spec, values have been scaled over and over again.
Project: Icinga (Observability and Analysis / Observability)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: '' assignees: '' A clear and concise description of what the bug is. Please ensure to read https://github.com/Icinga/icinga2/blob/master/doc/15-troubleshooting.md first. Formatting tips: GitHub supports Markdown: https://guides.github.com/features/mastering-markdown/ Provide a link to a live example, or an unambiguous set of steps to reproduce this bug. Include configuration, logs, etc. to reproduce, if relevant. A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Include as many relevant details about the environment you experienced the problem in Version used (`icinga2 --version`): Operating System and version: Enabled features (`icinga2 feature list`): Icinga Web 2 version and modules (System - About): Config validation (`icinga2 daemon -C`): If you run multiple Icinga 2 instances, the `zones.conf` file (or `icinga2 object list --type Endpoint` and `icinga2 object list --type Zone`) from all affected nodes. Add any other context about the problem here.
Project: Fluentd (Observability and Analysis / Observability)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thank you for contributing to Fluentd! Your commits need to follow DCO: https://probot.github.io/apps/dco/ And please provide the following information to help us make the most of your pull request: --> Which issue(s) this PR fixes: Fixes # What this PR does / why we need it: Docs Changes: Release Note:
Project: Kuberhealthy (Observability and Analysis / Observability)
File: JOBS.md

Jobs are configured using the `khjob` custom resources. These `khjobs` are just like `khchecks` but are configured without a runInterval as they run only once. They act like manually triggered k8s jobs, where as soon as your `khjob` resource is applied to the cluster, kuberhealthy runs it automatically. Any `khcheck` can be configured to be a `khjob` as long as you: 1) Change the resource to `kind: KuberhealthyJob` 2) Remove the `runInterval` in the `spec` 3) Verify that the khjob does not share the same name with a khcheck. If they are the same name, the job will report to the same khstate object, overwriting the khcheck's khstate. A list of pre-made checks that you can easily configure into `khjobs` are listed . Every `khjob` is unique, you cannot retrigger the same `khjob`. To rerun a `khjob` you must delete the `khjob` resource and re-apply the `khjob` OR rename your `khjob` in `metdata.name`. A `khjob` looks like this: ```yaml apiVersion: comcast.github.io/v1 kind: KuberhealthyJob metadata: name: kh-test-job # the name of this job and the job pod namespace: kuberhealthy # the namespace the job pod will run in spec: timeout: 2m # After this much time, Kuberhealthy will kill your job and consider it "failed" extraAnnotations: # Optional extra annotations your pod can have comcast.com/testAnnotation: test.annotation extraLabels: # Optional extra labels your pod can be configured with testLabel: testLabel podSpec: # The exact pod spec that will run. All normal pod spec is valid here. containers: env: # Environment variables are optional but a recommended way to configure job behavior name: REPORT_FAILURE value: "false" name: REPORT_DELAY value: 6s image: quay.io/comcast/test-check:latest # The image of the job you want to run. imagePullPolicy: Always # During job development, it helps to set this to 'Always' to prevent on-node image caching. name: main resources: requests: cpu: 10m memory: 50Mi ``` Daemonset Job: ```yaml apiVersion: comcast.github.io/v1 kind: KuberhealthyJob metadata: name: daemonset-job namespace: kuberhealthy spec: timeout: 3m podSpec: containers: env: name: POD_NAMESPACE value: "kuberhealthy" image: kuberhealthy/daemonset-check:v3.1.0 imagePullPolicy: IfNotPresent name: main resources: requests: cpu: 10m memory: 50Mi serviceAccountName: daemonset-khcheck ``` Deployment Job: ```yaml apiVersion: comcast.github.io/v1 kind: KuberhealthyJob metadata: name: deployment-job namespace: kuberhealthy spec: timeout: 3m podSpec: containers: name: deployment-job image: kuberhealthy/deployment-check:v1.5.1 imagePullPolicy: IfNotPresent env: name: CHECKDEPLOYMENTREPLICAS value: "4" name: CHECKDEPLOYMENTROLLING_UPDATE value: "true" name: CHECKDEPLOYMENTNAME value: "deployment-job-deployment" name: CHECKSERVICENAME value: "deployment-job-svc" resources: requests: cpu: 25m memory: 15Mi limits: cpu: 40m restartPolicy: Never serviceAccountName: deployment-sa terminationGracePeriodSeconds: 60 ```
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: syslogng_clusteroutput_types.md

title: SyslogNGClusterOutput weight: 200 generated_file: true SyslogNGClusterOutput is the Schema for the syslog-ng clusteroutputs API SyslogNGClusterOutputSpec contains Kubernetes spec for SyslogNGClusterOutput SyslogNGClusterOutputList contains a list of SyslogNGClusterOutput
Project: Checkmk (Observability and Analysis / Observability)
File: 16804.md

key | value | date | 2024-04-22T09:37:09+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes Some printers only report "some remaining" in case the exact percentage of the filing level is unknown. For these cases user could explicitly configure the monitoring state. This state can now be configured depending on whether the supply is a container or a receptacle.
Project: Checkmk (Observability and Analysis / Observability)
File: 16496.md

key | value | date | 2024-03-06T15:46:21+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes The agent would crash if information (backend pools or outbound rules) was missing for a load balancer. This werk ensures that the system handles scenarios where this data may not be present.
Project: Checkmk (Observability and Analysis / Observability)
File: 16400.md

key | value | date | 2024-01-26T13:27:19+00:00 version | 2.4.0b1 class | fix edition | cre component | omd level | 1 compatible | yes `omd restart` executes `omd start` and `omd stop`, both of which can terminate with exit code zero or two. Previously, the exit code of these commands would be ignored. `omd restart` now reports the worst exit code reported by the two commands.
Project: Trickster (Observability and Analysis / Observability)
File: supported-origin-types.md

Trickster currently supports the following Providers: Trickster operates as a fully-featured and highly-customizable reverse proxy cache, designed to accelerate and scale upstream endpoints like API services and other simple http services. Specify `'reverseproxycache'` or just `'rpc'` as the Provider when configuring Trickster. Trickster fully supports the . Specify `'prometheus'` as the Provider when configuring Trickster. Trickster supports for Prometheus. Trickster supports for InfluxDB. Specify `'influxdb'` as the Provider when configuring Trickster. See the for more information. Trickster supports accelerating ClickHouse time series. Specify `'clickhouse'` as the Provider when configuring Trickster. See the for more information. Support has been included for the Circonus IRONdb time-series database. If Grafana is used for visualizations, the Circonus IRONdb data source plug-in for Grafana can be configured to use Trickster as its data source. All IRONdb data retrieval operations, including CAQL queries, are supported. When configuring an IRONdb backend, specify `'irondb'` as the provider in the Trickster configuration. The `host` value can be set directly to the address and port of an IRONdb node, but it is recommended to use the Circonus API proxy service. When using the proxy service, set the `host` value to the address and port of the proxy service, and set the `api_path` value to `'irondb'`.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-4-0-beta1.md

hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 8.4.0-beta1 <!-- Auto generated by update changelog github action --> Alerting: Support WeCom as a contact point type. , Alerting: UI for mute timings. , Alerting: add settings for peer reconnection in HA mode. , Auth: implement autosignup for auth.jwt. , Dashboard: Add Show unknown variables toggle to dashboard settings. , Instrumentation: Logger migration from log15 to gokit/log. , MSSQL: Change regex to validate Provider connection string. , MSSQL: Configuration of certificate verification for TLS connection. , Middleware: Don't require HTTPS for HSTS headers to be emitted. , Navigation: Implement Keyboard Navigation. , News: Reload feed when changing the time range or refreshing. , UI/Plot: Implement keyboard controls for plot cursor. ,
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: logdna.md

title: LogDNA weight: 200 generated_file: true This plugin has been designed to output logs to LogDNA. Send your logs to LogDNA LogDNA Api key Application name Hostname Custom Ingester URL, Optional Default: `https://logs.logdna.com` Custom Ingester Endpoint, Optional Default: /logs/ingest HTTPS POST Request Timeout, Optional. Supports s and ms Suffices Default: 30 s 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 a warning message and increases the `fluentdoutputstatusslowflush_count` metric. Comma-Separated List of Tags, Optional {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: Output metadata: name: logdna-output-sample spec: logdna: api_key: xxxxxxxxxxxxxxxxxxxxxxxxxxx hostname: logging-operator app: my-app tags: web,dev ingester_domain https://logs.logdna.com ingester_endpoint /logs/ingest {{</ highlight >}} Fluentd config result: {{< highlight yaml >}} <match > @type logdna @id test_logdna api_key xxxxxxxxxxxxxxxxxxxxxxxxxxy app my-app hostname logging-operator </match> {{</ highlight >}}
Project: Krkn (Observability and Analysis / Chaos Engineering)
File: zone_outage.md

Scenario to create outage in a targeted zone in the public cloud to understand the impact on both Kubernetes/OpenShift control plane as well as applications running on the worker nodes in that zone. It tweaks the network acl of the zone to simulate the failure and that in turn will stop both ingress and egress traffic from all the nodes in a particular zone for the specified duration and reverts it back to the previous state. Zone outage can be injected by placing the zoneoutage config file under zoneoutages option in the . Refer to config file for the parameters that need to be defined. Refer to to configure your cli properly for the cloud provider of the cluster you want to shut down. ``` zone_outage: # Scenario to create an outage of a zone by tweaking network ACL. cloud_type: aws # Cloud type on which Kubernetes/OpenShift runs. aws is the only platform supported currently for this scenario. duration: 600 # Duration in seconds after which the zone will be back online. vpc_id: # Cluster virtual private network to target. subnet_id: [subnet1, subnet2] # List of subnet-id's to deny both ingress and egress traffic. ``` NOTE: vpcid and subnetid can be obtained from the cloud web console by selecting one of the instances in the targeted zone ( us-west-2a for example ). NOTE: Multiple zones will experience downtime in case of targeting multiple subnets which might have an impact on the cluster health especially if the zones have control plane components deployed. In case of failures during the steps which revert back the network acl to allow traffic and bring back the cluster nodes in the zone, the nodes in the particular zone will be in `NotReady` condition. Here is how to fix it: OpenShift by default deploys the nodes in different zones for fault tolerance, for example us-west-2a, us-west-2b, us-west-2c. The cluster is associated with a virtual private network and each zone has its own subnet with a network acl which defines the ingress and egress traffic rules at the zone level unlike security groups which are at an instance level. From the cloud web console, select one of the instances in the zone which is down and go to the subnet_id specified in the config. Look at the network acl associated with the subnet and you will see both ingress and egress traffic being denied which is expected as Kraken deliberately injects it. Kraken just switches the network acl while still keeping the original or default network acl around, switching to the default network acl from the drop-down menu will get back the nodes in the targeted zone into Ready state.
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: CHANGELOG.md

All notable changes to this project will be documented in this file. The format is based on and this project adheres to . Built-in ignores now match function names more accurately. They will no longer ignore stacks because of file names that look similar to function names. (#112) Add an `IgnoreAnyFunction` option to ignore stack traces that have the provided function anywhere in the stack. (#113) Ignore `testing.runFuzzing` and `testing.runFuzzTests` alongside other already-ignored test functions (`testing.RunTests`, etc). (#105) Miscellaneous CI-related fixes. (#103, #108, #114) Drop golang/x/lint dependency. Add Cleanup option that can be used for registering cleanup callbacks. (#78) Mark VerifyNone as a test helper. (#75) Thanks to @tallclair for their contribution to this release. Fixed logic for ignoring trace related goroutines on Go versions 1.16 and above. Documentation fix on how to test. Update dependency on stretchr/testify to v1.7.0. (#59) Update dependency on golang.org/x/tools to address CVE-2020-14040. (#62) [#49]: Add option to ignore current goroutines, which checks for any additional leaks and allows for incremental adoption of goleak in larger projects. Thanks to @denis-tingajkin for their contributions to this release. Migrate to Go modules. Ignore trace related goroutines that cause false positives with -trace. Initial release.
Project: Vector (Observability and Analysis / Observability)
File: 2020-04-07-lua-transform-version-2.md

date: "2020-03-31" title: "Lua Transform v2" description: "The next iteration of our Lua transform." authors: ["binarylogic"] pr_numbers: [2126] release: "0.9.0" hideonrelease_notes: false badges: type: enhancement domains: ["sources"] sources: ["vector"] v2 of our has been released! This is a complete overhaul that provides a new and improved API, better data processing ergonomics, and faster processing. Specific improvements include: Events are with proper type conversion. Introduction of to maintain global state. Introduction of to facilitate timed flushing. Useful for aggregations. The ability to accept and work with metric events in addition to log events. This raises the bar in terms of capabilities, which is important! Lua is often used as an escape hatch when Vector's native transforms are not expressive enough. {{< info >}} Did you know we're also {{< /info >}} {{< jump "/docs/reference/configuration/transforms/lua" >}} {{< jump "/guides/advanced/custom-aggregations-with-lua" >}} {{< jump "/guides/advanced/parsing-csv-logs-with-lua" >}} {{< jump "/guides/advanced/merge-multiline-logs-with-lua" >}} And for the curious, check out .