cwielenb/CNCF-Dataset huggingface dataset:
Project: Vector (Observability and Analysis / Observability)
File: 2023-03-26-0-37-0-upgrade-guide.md

date: "2023-03-26" title: "0.37 Upgrade Guide" description: "An upgrade guide that addresses breaking changes in 0.37.0" authors: ["jszwedko"] release: "0.37.0" hideonrelease_notes: false badges: type: breaking change Vector's 0.37.0 release includes breaking changes: and potentially impactful changes: We cover them below to help you upgrade quickly: Vector has the ability to [interpolate environment variables into its configuration](/docs/reference/configuration/#environment-variables) as a means of templating configuration. Now, if an environment variable is undefined, unless the `-` interpolation syntax is used to provide a default, Vector will output an error and stop. This behavior can be opted out of by setting the `--strict-env-vars` flag (or `VECTORSTRICTENV_VARS` environment variable) to `false` when running Vector; however, this behavior is deprecated and this flag to opt out will be removed in a future release. If you want to have Vector start-up even if an environment variable is undefined you can provide a default like `${FOO-bar}` to default `FOO` to `bar` if it is unset. The reasoning for this change is that users often miss the undefined variable warning and are confused by Vector not behaving as the expected. In particular, this happens when using `$1` in regex capture groups in VRL without realizing they need to be escaped as `$$1` to avoid interpolation. The `dnstap` source now requires the `mode` parameter with the addition of support for reading events over a TCP socket. Set this to `unix` to continue reading from the Unix socket configured as `socket_path`. With the addition of the new `mmdb` enrichment table type, the existing `geoip2` enrichment table type no longer falls back assuming the database is a `GeoIP-City` database when the type is unknown. We don't expect this to affect anyone, but the fix is to ensure that the MMDB database type is correctly set to `GeoIP2-City` if the database is a GeoIP2-City database. For custom MMDBs, that are not GeoIP2 databases, the new `mmdb` enrichment table can be used instead to read the MMDB records exactly as they are.
Project: Cortex (Observability and Analysis / Observability)
File: tracing.md

title: "Tracing" linkTitle: "Tracing" weight: 10 slug: tracing Cortex uses or to implement distributed tracing. We have found tracing invaluable for troubleshooting the behavior of Cortex in production. In order to send traces you will need to set up a Jaeger deployment. A deployment includes either the jaeger all-in-one binary, or else a distributed system of agents, collectors, and queriers. If running on Kubernetes, [Jaeger Kubernetes](https://github.com/jaegertracing/jaeger-kubernetes) is an excellent resource. In order to configure Cortex to send traces you must do two things: Set the `JAEGERAGENTHOST` environment variable in all components to point to your Jaeger agent. This defaults to `localhost`. Enable sampling in the appropriate components: The Ingester and Ruler self-initiate traces and should have sampling explicitly enabled. Sampling for the Distributor and Query Frontend can be enabled in Cortex or in an upstream service such as your frontdoor. To enable sampling in Cortex components you can specify either `JAEGERSAMPLERMANAGERHOSTPORT` for remote sampling, or `JAEGERSAMPLERTYPE` and `JAEGERSAMPLERPARAM` to manually set sampling configuration. See the [Jaeger Client Go documentation](https://github.com/jaegertracing/jaeger-client-go#environment-variables) for the full list of environment variables you can configure. Note that you must specify one of `JAEGERAGENTHOST` or `JAEGERSAMPLERMANAGERHOSTPORT` in each component for Jaeger to be enabled, even if you plan to use the default values. In order to send traces you will need to set up an OpenTelemetry Collector. The collector will be able to send traces to multiple destinations such , , and . OpenTelemetry Collector provides a to set up the environment. See document on the tracing section in . Cortex is maintaining backward compatibility with Jaeger support, Cortex has not fully migrated from OpenTracing to OpenTelemetry and is currently using the .
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: mongodb.md

title: MongoDB weight: 200 generated_file: true Based on the . Available in Logging operator version 4.4 and later. {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: SyslogNGOutput metadata: name: mongodb namespace: default spec: mongodb: collection: syslog uri: "mongodb://mongodb-endpoint/syslog?wtimeoutMS=60000&socketTimeoutMS=60000&connectTimeoutMS=60000" value_pairs: scope("selected-macros" "nv-pairs") {{</ highlight >}} For more information, see the . Batching parameters Bulk operation related options The name of the MongoDB collection where the log messages are stored (collections are similar to SQL tables). Note that the name of the collection must not start with a dollar sign ($), and that it may contain dot (.) characters. Defines the folder where the disk-buffer files are stored. This option enables putting outgoing messages into the disk buffer of the destination to avoid message loss in case of a system failure on the destination side. For details, see the . Default: false The number of messages that the output queue can store. If you receive the following error message during syslog-ng startup, set the `persist-name()` option of the duplicate drivers: `Error checking the uniqueness of the persist names, please override it with persist-name option. Shutting down.` See the for more information. The number of times syslog-ng OSE attempts to send a message to this destination. If syslog-ng OSE could not send a message, it will try again until the number of attempts reaches retries, then drops the message. The time to wait in seconds before a dead connection is reestablished. Default: 60 Connection string used for authentication. See the Creates structured name-value pairs from the data and metadata of the log message. Default: `"scope("selected-macros" "nv-pairs")"` Description: Sets the write concern mode of the MongoDB operations, for both bulk and single mode. For details, see the . Bulk operation related options. For details, see the . Enables bulk insert mode. If disabled, each messages is inserted individually. Default: yes If set to yes, it disables MongoDB bulk operations validation mode. Default: no Description: Enables unordered bulk operations mode. Default: no TODO move this to a common module once it is used in more places
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: nodejs.md

title: "Node.js" menuTitle: "Node.js" description: "Instrumenting Node.js applications for continuous profiling." weight: 80 aliases: /docs/phlare/latest/configure-client/language-sdks/nodejs Enhance your Node.js application's performance with our Node.js Profiler. Seamlessly integrated with Pyroscope, it provides real-time insights into your applications operation, helping you identify and resolve performance bottlenecks. This integration is key for Node.js developers aiming to boost efficiency, reduce latency, and maintain optimal application performance. {{< admonition type="note" >}} Refer to for a list of profile types supported by each language. {{< /admonition >}} To capture and analyze profiling data, you need either a hosted Pyroscope OSS server or a hosted (requires a free Grafana Cloud account). The Pyroscope server can be a local server for development or a remote server for production use. To start profiling a Node.js application, you need to include the npm module in your app: ``` npm install @pyroscope/nodejs yarn add @pyroscope/nodejs ``` Add the following code to your application: ```javascript const Pyroscope = require('@pyroscope/nodejs'); Pyroscope.init({ serverAddress: 'http://pyroscope:4040', appName: 'myNodeService' }); Pyroscope.start() ``` Note: If you'd prefer to use Pull mode you can do so using the . It is possible to add tags (labels) to the profiling data. These tags can be used to filter the data in the UI. Dynamic tagging isn't supported yet. ```javascript Pyroscope.init({ serverAddress: 'http://pyroscope:4040', appName: 'myNodeService', tags: { region: ENV['region'] }, }); Pyroscope.start() ``` ```javascript Pyroscope.init({ serverAddress: 'http://pyroscope:4040', appName: 'myNodeService', tags: { region: ENV['region'] }, basicAuthUser: ENV['PYROSCOPEBASICAUTH_USER'], basicAuthPassword: ENV['PYROSCOPEBASICAUTH_PASSWORD'], // Optional Pyroscope tenant ID (only needed if using multi-tenancy). Not needed for Grafana Cloud. // tenantID: ENV['PYROSCOPETENANTID'], }); Pyroscope.start() ``` To configure the Node.js SDK to send data to Pyroscope, replace the `serverAddress` placeholder with the appropriate server URL. This could be the Grafana Cloud Pyroscope URL or your own custom Pyroscope server URL. If you need to send data to Grafana Cloud, youll have to configure HTTP Basic authentication. Replace `basicAuthUser` with your Grafana Cloud stack user ID and `basicAuthPassword` with your Grafana Cloud API key. If your Pyroscope server has multi-tenancy enabled, youll need to configure a tenant ID. Replace `tenantID` with your Pyroscope tenant ID. Setting `DEBUG` env to `pyroscope` provides additional debugging information. ```bash DEBUG=pyroscope node index.js ```
Project: Netdata (Observability and Analysis / Observability)
File: sample-apps-config.md

A custom format is used. Each configuration line has a form like: ``` group_name: app1 app2 app3 ``` Where `group_name` defines an application group, and `app1`, `app2`, and `app3` are process names to match for that application group. Each group can be given multiple times, to add more processes to it. The process names are the ones returned by: `ps -e` or `/proc/PID/stat` in case of substring mode (see below): `/proc/PID/cmdline` To add process names with spaces, enclose them in quotes (single or double): `'Plex Media Serv' "my other process"` Note that spaces are not supported for process groups. Use a dash "-" instead. You can add an asterisk (\*) at the beginning and/or the end of a process to do wildcard matching: `*name` suffix mode: will search for processes ending with 'name' (/proc/PID/stat) `name*` prefix mode: will search for processes beginning with 'name' (/proc/PID/stat) `name` substring mode: will search for 'name' in the whole command line (/proc/PID/cmdline) If you enter even just one `name` (substring), apps.plugin will process /proc/PID/cmdline for all processes, just once (when they are first seen). To add processes with single quotes, enclose them in double quotes: "process with this ' single quote" To add processes with double quotes, enclose them in single quotes: 'process with this " double quote' The order of the entries in this list is important, the first that matches a process is used, so put important ones at the top. Processes not matched by any row, will inherit it from their parents or children. The order also controls the order of the dimensions on the generated charts (although applications started after apps.plugin is started, will be appended to the existing list of dimensions the netdata daemon maintains).
Project: Checkmk (Observability and Analysis / Observability)
File: 16391.md

key | value | date | 2024-02-09T15:54:09+00:00 version | 2.4.0b1 class | fix edition | cre component | wato level | 1 compatible | yes Previously, when creating a new LDAP connection via the UI, you could provide an ID that was already in use by another user connection. This is no longer the case with this werk. Now, when you clone a connection, a new unique ID will be generated from the cloned connection. If you create a new connection, the ID must be unique or you will get an error.
Project: Netdata (Observability and Analysis / Observability)
File: riakkv_1h_kv_put_mean_latency.md

The `riakkv1hkvputmean_latency` alert calculates the average time (in milliseconds) between the reception of client `PUT` requests and the subsequent responses to the clients over the last hour in a Riak KV database. If you receive this alert, it means that your Riak KV database is experiencing higher than normal latency in processing `PUT` requests. Riak KV is a distributed NoSQL key-value data store designed to provide high availability, fault tolerance, operational simplicity, and scalability. The primary access method is through `PUT`, `GET`, `DELETE`, and `LIST` operations on keys. `PUT` latency refers to the time it takes for the system to process a `PUT` request - from the moment the server receives the request until it sends a response back to the client. High `PUT` latency can impact the performance and responsiveness of applications relying on the Riak KV database. Check the Riak KV cluster health Use the `riak-admin cluster status` command to get an overview of the Riak KV cluster's health. Make sure there are no unreachable or down nodes in the cluster. Verify the Riak KV node performance Use the `riak-admin status` command to display various statistics of the Riak KV nodes. Pay attention to the `nodeputfsmtimemean` and `nodeputfsmtime95` metrics, as they are related to `PUT` latency. Inspect network conditions Use networking tools (e.g., `ping`, `traceroute`, `mtr`, `iftop`) to check for potential network latency issues between clients and the Riak KV servers. Evaluate the workload If the client application is heavily write-intensive, consider optimizing it to reduce the number of write operations or increase the capacity of the Riak KV cluster to handle the load. Review Riak KV logs Examine the Riak KV logs (`/var/log/riak/riak_kv.log` by default) for any error messages or unusual patterns that might be related to the increased `PUT` latency.
Project: Checkmk (Observability and Analysis / Observability)
File: 15329.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-04-09T06:01:31+00:00 level | 1 class | fix component | checks edition | cre Due to fixes introduced with <a href="https://checkmk.com/werk/16232">Werk #16232</a> new error messages have been introduced to sections which previously had not to handle any errors. Now <tt>oracleprocesses</tt> and <tt>oraclerecovery_area</tt> services can handle the new error messages.
Project: Netdata (Observability and Analysis / Observability)
File: postgres_table_index_cache_io_ratio.md

This alert monitors the PostgreSQL table index cache hit ratio, specifically the average index cache hit ratio over the last minute, for a specific database and table. If you receive this alert, it means that your table index caching is not efficient and might result in slow database performance. Cache hit ratio is the percentage of cache accesses to an existing item in the cache, compared to cache accesses to a non-existing item. A higher cache hit ratio means that your database entries are found in the cache more often, reducing the need to access the disk and consequently speeding up the execution times for database operations. Check cache configuration settings `shared_buffers`: This parameter sets the amount of shared memory used for the buffer pool, which is the most common caching mechanism. You can check its current value by running the following query: ``` SHOW shared_buffers; ``` `effectivecachesize`: This parameter is used by the PostgreSQL query planner to estimate how much of the buffer pool data will be cached in the operating system's page cache. To check its current value, run: ``` SHOW effectivecachesize; ``` Analyze the query workload Queries using inefficient indexes or not using indexes properly might contribute to a higher cache miss ratio. To find the most expensive queries, you can run: ``` SELECT * FROM pgstatstatements ORDER BY total_time DESC LIMIT 10; ``` Check if your database is using proper indexes. You can create a missing index based on your query plan or modify existing indexes to cover more cases. Increase cache size If the cache settings are low and disk I/O is high, you might need to increase the cache size. Remember that increasing the cache size may also impact system memory usage, so monitor the changes and adjust the settings accordingly. Optimize storage performance Verify that the underlying storage system performs well by monitoring disk latency and throughput rates. If required, consider upgrading the disk subsystem or using faster disks.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: redhat_kraken.md

is an enterprise software company with an open source development model. is a family of containerization software products developed by Red Hat We wanted to test the maturity of Red Hat Openshift Container Platform and layers on top of it using chaos testing. Following that, we decided to use Litmus for these reasons: It's an Open Source project It has a wide selection of experiments available It has a vibrant community There are frequent releases and it is well maintained We consume a variety of Litmus experiments in a tool called , where we are able to test infrastructure components of OpenShift. Litmus experiments are deployed against a single Openshift cluster that runs on top of a variety of cloud providers and a baremetal server using libvirt/KVM. Each experiment consists of observing the behavior upon applying chaos to the underlying infrastucture of a running pod or node instance, and validating the results of the resiliency. The chaos we inject to the VMs that host the openshift nodes can vary from hogging up the CPU and memory to stressing the IO and network disruption at the node level, among others. Being a cloud native solution, Litmus allows us to define our experiment and expectations in the `chaosexperiment` manifest and retrieve the results in the `chaosresult` object generated at runtime. Its vast selection of experiments, periodic release cadence and a welcoming community were sufficient signals that ensured with Litmus we would achieve our goal.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: quickstart.md

title: 'Quickstart' description: Quickstart to deploy Tempo with the Tempo Operator menuTitle: Quickstart weight: 100 aliases: /docs/tempo/operator/quickstart One page summary on how to start with Tempo Operator and `TempoStack`. The easiest way to start with the Tempo Operator is to use Kubernetes . To install the operator in an existing cluster, make sure you have installed and run: ```shell kubectl apply -f https://github.com/grafana/tempo-operator/releases/latest/download/tempo-operator.yaml ``` Once you have the operator deployed you need to install a storage backend. For this quick start guide, we will install as follows: ```shell kubectl apply -f https://raw.githubusercontent.com/grafana/tempo-operator/main/minio.yaml ``` After minio was deployed, create a secret for MinIO in the namespace you are using: ```yaml kubectl apply -f - <<EOF apiVersion: v1 kind: Secret metadata: name: minio-test stringData: endpoint: http://minio.minio.svc:9000 bucket: tempo accesskeyid: tempo accesskeysecret: supersecret type: Opaque EOF ``` Then create Tempo CR: ```yaml kubectl apply -f - <<EOF apiVersion: tempo.grafana.com/v1alpha1 kind: TempoStack metadata: name: simplest spec: storage: secret: name: minio-test type: s3 storageSize: 1Gi resources: total: limits: memory: 2Gi cpu: 2000m template: queryFrontend: jaegerQuery: enabled: true EOF ``` After create the `TempoStack` CR, you should see a some pods on the namespace. Wait for the stack to stabilize. The stack deployed above is configured to receive Jaeger, Zipkin, and OpenTelemetry (OTLP) protocols. Because the Jaeger Query is enabled, you can also use the Jaeger UI to inspect the data. To do a quick test, deploy a Job that generates some traces. ```yaml kubectl apply -f - <<EOF apiVersion: batch/v1 kind: Job metadata: name: tracegen spec: template: spec: containers: name: tracegen image: ghcr.io/open-telemetry/opentelemetry-collector-contrib/tracegen:latest command: "./tracegen" args: -otlp-endpoint=tempo-simplest-distributor:4317 -otlp-insecure -duration=30s -workers=1 restartPolicy: Never backoffLimit: 4 EOF ``` Forward the Jaeger Query port to see the traces: ``` kubectl port-forward svc/tempo-simplest-query-frontend 16686:16686 ``` Visit http://localhost:16686 to view the results.
Project: SkyWalking (Observability and Analysis / Observability)
File: backend-health-check.md

Health check intends to provide a unique approach to checking the health status of the OAP server. It includes the health status of modules, GraphQL, and gRPC services readiness. 0 means healthy, and more than 0 means unhealthy. less than 0 means that the OAP doesn't start up. The Health Checker module helps observe the health status of modules. You may activate it as follows: ```yaml health-checker: selector: ${SWHEALTHCHECKER:default} default: checkIntervalSeconds: ${SWHEALTHCHECKERINTERVALSECONDS:5} ``` Note: The `telemetry` module should be enabled at the same time. This means that the provider should not be `-` and `none`. After that, we can check the OAP server health status by querying GraphQL: ``` query{ checkHealth{ score details } } ``` If the OAP server is healthy, the response should be ```json { "data": { "checkHealth": { "score": 0, "details": "" } } } ``` If some modules are unhealthy (e.g. storage H2 is down), then the result may look as follows: ```json { "data": { "checkHealth": { "score": 1, "details": "storage_h2," } } } ``` Refer to for more details. Use the query above to check the readiness of GraphQL. OAP has implemented the . You may use the or any other tools to check the health of OAP gRPC services. Please follow the to get the health status score directly through the `checkhealth` command.
Project: Cortex (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: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: hosttailer_types.md

title: HostTailer weight: 200 generated_file: true HostTailerSpec defines the desired state of HostTailer EnableRecreateWorkloadOnImmutableFieldChange enables the operator to recreate the daemonset (and possibly other resource in the future) in case there is a change in an immutable field that otherwise couldn't be managed with a simple update. List of . List of . Override podSpec fields for the given daemonset Override metadata of the created resources HostTailerStatus defines the observed state of . HostTailer is the Schema for the hosttailers API HostTailerList contains a list of . FileTailer configuration options Set the buffer chunk size per active filetailer Set the limit of the buffer size per active filetailer Override container fields for the given tailer Disable tailing the file Override image field for the given trailer Name for the tailer Path to the loggable file Start reading from the head of new log files Skip long line when exceeding BufferMaxSize SystemdTailer configuration options Override container fields for the given tailer Disable component Override image field for the given trailer Maximum entries to read when starting to tail logs to avoid high pressure Name for the tailer Override systemd log path Filter to select systemd unit example: kubelet.service