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

title: eventlogmessage menuTitle: description: The 'eventlogmessage' Promtail pipeline stage. aliases: ../../../clients/promtail/stages/eventlogmessage/ weight: The `eventlogmessage` stage is a parsing stage that extracts data from the Message string that appears in the Windows Event Log. ```yaml eventlogmessage: [source: <string> | default = message] [overwrite_existing: <bool> | default = false] [dropinvalidlabels: <bool> | default = false] ``` The extracted data can hold non-string values and this stage does not do any type conversions; downstream stages will need to perform correct type conversion of these values as necessary. Please refer to the for how to do this. For the given pipeline: ```yaml json: expressions: message: Overwritten: eventlogmessage: source: message overwrite_existing: true ``` Given the following log line: ``` {"event_id": 1, "Overwritten": "old", "message": "Message type:\r\nOverwritten: new\r\nImage: C:\\Users\\User\\promtail.exe"} ``` The first stage would create the following key-value pairs in the set of extracted data: `message`: `Message type:\r\nOverwritten: new\r\nImage: C:\Users\User\promtail.exe` `Overwritten`: `old` The second stage will parse the value of `message` from the extracted data and append/overwrite the following key-value pairs to the set of extracted data: `Image`: `C:\\Users\\User\\promtail.exe` `Message_type`: (empty string) `Overwritten`: `new`
Project: EaseAgent (Observability and Analysis / Observability)
File: add-plugin-demo.md

You need Java 1.8+ and easeagent: If you don't already have easeagent, get it and set $EASEAGENTPATH: There is a which is spring web and client ``` $ git clone https://github.com/megaease/easeagent-test-demo.git $ cd spring-web $ mvn clean package ``` There is a which only for demonstrating the use of the plugin. The compiled simple plugin JAR package should be copy to the `plugins` directory located in `EASEAGENTPATH`, and if the directory is not exsist, it need to be created. ``` $ cd simple-plugin $ mvn clean package $ cp target/simple-plugin-1.0.jar $EASEAGENTPATH/plugins/ ``` ``` $ export EASEAGENTPATH=[Replace with agent path] $ java "-javaagent:${EASEAGENTPATH}/easeagent-dep.jar" -Deaseagent.config.path=${EASEAGENTPATH}/agent.properties -Deaseagent.server.port=9900 -jar target/spring-web-1.0.jar ``` Open another console, run curl to access the test url for several times. ``` $ for i in {1..1000}; do curl -v http://127.0.0.1:18888/web_client;sleep 0.1; done ``` If the tracing data is send to console, there would be some tracing log in console like this: ``` [{"traceId":"5a8800b902703307","parentId":"84c4cba42fb92788","id":"fd00a1705c88cbb2","kind":"SERVER","name":"get","timestamp":1639493283759877,"duration":217545,"shared":true,"localEndpoint":{"serviceName":"demo-service","ipv4":"192.168.0.102"},"remoteEndpoint":{"ipv4":"127.0.0.1","port":55809},"tags":{"http.method":"GET","http.path":"/hello","http.route":"/hello","i":"ServerName.local"},"type":"log-tracing","service":"demo-service","system":"demo-system"},{"traceId":"5a8800b902703307","id":"5a8800b902703307","kind":"SERVER","name":"get","timestamp":1639493283753466,"duration":228827,"localEndpoint":{"serviceName":"demo-service","ipv4":"192.168.0.102"},"remoteEndpoint":{"ipv4":"127.0.0.1","port":55851},"tags":{"http.method":"GET","http.path":"/web_client","i":"ServerName.local"},"type":"log-tracing","service":"demo-service","system":"demo-system"}] ... ``` Adding the following configuration in `prometheus.yml` ```yaml job_name: 'spring-web-service' static_configs: targets: ['localhost:9900'] metrics_path: "/prometheus/metrics" ``` Start Prometheus ```bash $ ./prometheus --config.file=prometheus.yml ``` Open Browser to visit . Prometheus Metric Schedule: search `applicationhttprequestm1{url="GET /webclient"}`. You will see as following. Modify service name, default configuration is `demo-service`. ``` name=[app-name] ``` Modify kafka server config, default configuration is `127.0.0.1:9092`. Both `tracing` data and `metric` data will be send to kafka server by default configuration. ``` ``` Modify output configuration, if you want to watch log information in console. ``` plugin.observability.global.metric.appendType=console reporter.tracing.sender.appendType=console ``` Sending tracing data to zipkin server ``` reporter.tracing.sender.appendType=http reporter.tracing.sender.url=http://localhost:9411/api/v2/spans ```
Project: Promscale (Observability and Analysis / Observability)
File: PromscaleIngestHighErrorRate.md

Promscale is experiencing high number of errors while ingesting metric samples or traces For metric data, high error rates will affect Prometheus remote-storage component, leading to frequent retrying of samples batch and buffering of samples in the WAL, increasing Prometheus disk usage. If left untreated, this will lead to upsharding, increasing Prometheus memory usage. Longer retry durations may result dropping of samples as well. For tracing data this may result in spans being dropped. High error rates may also indicate an unhealthy database or a lack of any disk space. Check the Promscale logs for errors. If they exists, go to for mitigation Check the logs for Prometheus and (if used) OpenTelemetry Collector to see if there are any error messages. If any error exists, go to for mitigation Check if your database is reachable Check if the database has sufficient disk space. If the database runs out of space it can change the connection to read-only mode, leading to ingestion errors. Check the Postgres logs for any errors. If found, check for mitigation Reconfigure your data source (Prometheus, Opentelemetry Collector, etc.) to ensure that all applied configurations are as specified in the documentation Ensure proper connection to the database Go through Postgres logs for detailed information Add more disk space to your Postgres cluster Fix errors to make sure database that is able to accept connections
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: mayadata.md

is a tool to manage and visualize the cluster more efficiently and even data migration across cloud. To manage your cluster you can connect it to the saas platform or you can have your own on-prem installation using DOP. Director reduces the risk and increases the agility of running stateful applications on Kubernetes. Your workloads can have storage provisioned, backed-up, monitored, logged, managed, tested, and even migrated across clusters and clouds We realised that functional testing alone is not sufficient to ensure the resiliency of the system. So, We planned to practice chaos engineering in our E2E test suite in order to validate the system's resiliency. We wanted to induce chaos not only specific to OpenEBS components but also on the underlying Kubernetes components which forms the skeleton for Containers infrastructure. Litmus eases our vision by providing chaos charts for the above said components. Litmus has a separate chaos category for OpenEBS charts which is evolving continuously. For and DOP we have commit based E2E pipeline to help developers to test their commits and integration of the different components of the director and deliver the application quickly to the user. We have incorporated various test scenarios using chaos charts provided by litmuschaos which helped in developing our E2E test quickly and efficiently. We have covered various platforms to test and make our product more reliable and litmus has helped us in achieving that. Moreover, the learning curve to adopt litmus was also very less which motivated us to use it in our pipeline. We are using litmus to introduce live chaos on our clusters as well to see how our application behaves in real-time and test the resiliency to make our infrastructure more efficient and reliable (Gamedays). We have different stateful applications in our production mysql, cassandra, postgres to name some we are using to litmus to introduce chaos to these applications and to observe the impact on our components that are using these sts. Litmus has provided a very easy way to provide scriptable, reproducible tests easy to implement and make our application more reliable and fault-tolerant.
Project: EaseAgent (Observability and Analysis / Observability)
File: README.md

``` keytool -importcert -v -trustcacerts -alias some.host.name -file /path/to/cert/file -keystore /path/to/store/file ``` ``` java -Djavax.net.ssl.trustStore=/path/to/store/file -Djavax.net.ssl.trustStorePassword= ... ``` If `/path/to/store/file` is the JRE default store file, you can ignore properties above.
Project: SkyWalking (Observability and Analysis / Observability)
File: apdex-threshold.md

Apdex is a measure of response time based against a set threshold. It measures the ratio of satisfactory response times to unsatisfactory response times. The response time is measured from an asset request to completed delivery back to the requestor. A user defines a response time threshold T. All responses handled in T or less time satisfy the user. For example, if T is 1.2 seconds and a response completes in 0.5 seconds, then the user is satisfied. All responses greater than 1.2 seconds dissatisfy the user. Responses greater than 4.8 seconds frustrate the user. The apdex threshold T can be configured in `service-apdex-threshold.yml` file or via . The `default` item will apply to a service that isn't defined in this configuration as the default threshold. The configuration content includes the names and thresholds of the services: ```yml default: 500 ```
Project: Vector (Observability and Analysis / Observability)
File: 2020-04-05-default-compression-to-none.md

date: "2020-07-13" title: "The `elasticsearch` sink `compression` option now defaults to `none`" description: "Compression is not supported by all Elasticsearch service providers" authors: ["binarylogic"] hideonrelease_notes: false pr_numbers: [2219] release: "0.9.0" badges: type: "breaking change" domains: ["sinks"] sinks: ["elasticsearch"] To optimize throughput we originally defaulted the `elasticsearch` sink `compression` option to `gzip`. It is our philosophy that Vector's defaults should optimize performance and throughput, but not at the expense of causing errors. Unfortunately, AWS-hosted Elasticsearch does not support compression, and therefore we've made this feature opt-in. Upgrading is easy. Add the following if you want to enabled Gzip compression: ```diff title="vector.toml" [sinks.es] type = "elasticsearch" compression = "gzip" ```
Project: Trickster (Observability and Analysis / Observability)
File: influxdb.md

Trickster provides support for accelerating InfluxDB queries that return time series data normally visualized on a dashboard. Acceleration works by using the Time Series Delta Proxy Cache to minimize the number and time range of queries to the upstream InfluxDB server. Trickster is tested with the built-in v5.0.0. Trickster uses InfluxDB-provided packages to parse and normalize queries for caching and acceleration. If you find query or response structures that are not yet supported, or providing inconsistent or unexpected results, we'd love for you to report those so we can further improve our InfluxDB support. Trickster supports integrations with InfluxDB 1.x and 2.0, however, the Flux language is not currently supported.
Project: Checkmk (Observability and Analysis / Observability)
File: 16607.md

key | value | date | 2024-04-12T09:35:03+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes As of version 2.3, the uptime monitoring service for Docker containers could crash if the container's start time was later than the current CheckMk site's current time. This resulted in a negative uptime calculation error (ValueError: "Cannot render negative timespan"). This could occur in situations where the host system and the container had different configured timezones. We now correctly handle all timestamps, ensuring accurate uptime calculations regardless of timezone configurations.
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: aws.md

title: Deploying Flagsmith on AWS description: Getting Started with Flagsmith on AWS sidebar_label: AWS sidebar_position: 70 We recommend running Flagsmith on AWS using the following AWS services: ECS/Fargate for running the Docker image RDS/Aurora/Postgres for the database Application Load Balancer to distribute traffic We have scripts available for AWS deployments. Please get in touch if these are of interest. Unless you have specific requirements, we recommend running the . It's best to study our in order to set up the base environment variables. Further environment variables are . Run a single ECS service with at least two Fargate instances running for failover. For more info on Fargate sizes, see our . If you are using health-checks, make sure to use `/health` as the health-check endpoint. We run in production on PostgreSQL version `11`; Aurora release `3.x`. When starting for the first time, the application will create that database schema automatically. Schema upgrades will also happen seamlessly during application server upgrades. We direct all traffic through an AWS ALB to the relevant ECS service.
Project: Headlamp (Observability and Analysis / Observability)
File: frontend.md

title: Frontend weight: 5 The frontend is written in Typescript and React, as well as a few other important modules like: Material UI React Router Redux Redux Sagas The frontend can be quickly built using: ```bash make frontend ``` Once built, it can be run in development mode (auto-refresh) using: ```bash make run-frontend ``` This command leverages the `create-react-app`'s start script that launches a development server for the frontend (by default at `localhost:3000`). API documentation for TypeScript is done with and , and is configured in tsconfig.json ```bash make docs ``` The API output markdown is generated in docs/development/api and is not committed to git, but is shown on the website at Components can be discovered, developed, and tested inside the 'storybook'. From within the repo run: ```bash make storybook ``` If you are adding new stories, please wrap your story components with the `TestContext` helper component as it sets up the store, memory router, and other utilities that may be needed for current or future stories: ```jsx <TestContext> <YourComponentTheStoryIsAbout /> </TestContext> ``` axe-core is used to detect some a11y issues at runtime when running Headlamp in developer mode. This detects more issues than testing components via eslint or via unit tests. Any issues found are reported in the developer console. To enable the alert message during development, use the following: ```bash REACTAPPSKIP_A11Y=false make run-frontend ``` This shows an alert when an a11y issue is detected.
Project: Botkube (Observability and Analysis / Observability)
File: 2019-03-14-mattermost-support.md

| Status | || | `IMPLEMENTED` | Mattermost is already installed. Mattermost server IP is reachable from the cluster. `Mattermost` is an open source, self-hosted Slack-alternative and we want to add support for the same in Botkube. Currently Botkube is supporting Slack, and as a feature addition we want to include `Mattermost` support. Botkube will run on the clusters and send notifications and alerts to the configured Mattermost team. It will also be able to execute `@botkube` commands from `Mattermost`. Steps for adding Mattermost support: Add package for Mattermost referring to `mattermost-server` repository. Add Mattermost configurations in helm chart or config.yaml. While starting controller, check in config if Mattermost support is enabled. If support enabled, initialize Mattermost with values from config. Start a goroutine for Mattermost. In controller, add notifier for `SendEvent` and `SendMessage` for Mattermost. The repository contains a client package to perform operations on `Mattermost` server. We will perform below operations using the package. Connecting to Mattermost server. Create `Botkube` user in Mattermost. Finding team in Mattermost and adding `Botkube` user to the Team. Finding channel or create channel if needed and adding `Botkube` user to the Channel. Send and Receive messages from Mattermost server. We need to add below values for Mattermost in Helm Chart or config.yaml. Mattermost Support enabled/disabled flag Mattermost Server IP Team Name User-Email User-Name Password Channel Name(Same as Slack) In `main.go`, check in config if Mattermost support is enabled. If yes, then get config and add a goroutine for Mattermost. In `controller.go`, for event notifications and sending start/stop messages, add notifier for Mattermost. https://github.com/mattermost/mattermost-bot-sample-golang https://github.com/mattermost/mattermost-server/blob/master/model/client4.go https://docs.mattermost.com/install/install-ubuntu-1804.html
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: LTS-releases.md

sort: 300 weight: 300 title: Long-term support releases menu: docs: parent: 'victoriametrics' weight: 300 aliases: /LTS-releases.html provides long-term support lines of releases (aka LTS releases). Every LTS line receives bugfixes and for 12 months after the initial release. New LTS lines are published every 6 months, so the latest two LTS lines are supported at any given moment. This gives up to 6 months for the migration to new LTS lines for users. All the bugfixes and security fixes, which are included in LTS releases, are also available in , so non-enterprise users are advised to regularly VictoriaMetrics products to . 1.97.x - the latest one is 1.93.x - the latest one is
Project: Checkmk (Observability and Analysis / Observability)
File: 16425.md

key | value | date | 2024-04-22T11:05:16+00:00 version | 2.4.0b1 class | fix edition | cre component | omd level | 1 compatible | yes Previously, using the command `omd config set APACHETCPADDR` with a IPv6 address would fail. For example, the command ``` $ omd config set APACHETCPADDR "[::]" ``` resulted in `Invalid value for '[::]'. Does not match allowed pattern.` With this Werk, it `omd` only checks that a `Listen` directive for Apache can be constructed from the `APACHETCPADDR`. In particular, this a IPv6 address can be configured. Such an address must be surrounded by square brackets.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: content.md

<table> <tr> <th>Category</th> <th>Description</th> <th>References</th> </tr> <tr> <td>Install</td> <td>Questions related to litmus installation</td> <td><a href="/litmus/experiments/faq/install/">Install</a></td> </tr> <tr> <td>Experiments</td> <td>Questions related to litmus experiments</td> <td><a href="/litmus/experiments/faq/experiments/">Experiments</a></td> </tr> <tr> <td>Portal</td> <td>Questions related to litmus portal</td> <td><a href="/litmus/experiments/faq/portal/">Portal</a></td> </tr> <tr> <td>Scheduler</td> <td>Questions related to litmus scheduler</td> <td><a href="/litmus/experiments/faq/scheduler/">Scheduler</a></td> </tr> <tr> <td>Security</td> <td>Questions related to litmus security</td> <td><a href="/litmus/experiments/faq/security/">Security</a></td> </tr> <tr> <td>CI/CD</td> <td>Questions related to litmus CI/CD integration</td> <td><a href="/litmus/experiments/faq/ci-cd/">CI/CD</a></td> </tr> </table> <table> <tr> <th>Category</th> <th>Description</th> <th>References</th> </tr> <tr> <td>Install</td> <td>Troubleshooting related to litmus installation</td> <td><a href="/litmus/experiments/troubleshooting/install/">Install</a></td> </tr> <tr> <td>Experiments</td> <td>Troubleshooting related to litmus experiments</td> <td><a href="/litmus/experiments/troubleshooting/experiments/">Experiments</a></td> </tr> <tr> <td>Portal</td> <td>Troubleshooting related to litmus portal</td> <td><a href="/litmus/experiments/troubleshooting/portal/">Portal</a></td> </tr> <tr> <td>Scheduler</td> <td>Troubleshooting related to litmus scheduler</td> <td><a href="/litmus/experiments/troubleshooting/scheduler/">Scheduler</a></td> </tr> </table>
Project: SkyWalking (Observability and Analysis / Observability)
File: backend-oal-scripts.md

First, read the to learn the OAL script grammar and the source concept. From 8.0.0, you may find the OAL script at `/config/oal/*.oal` of the SkyWalking dist. You could change it, such as by adding filter conditions or new metrics. Then, reboot the OAP server, and it will come into effect. All metrics named in this script could be used in alarm and UI query. In default, SkyWalking only treats the operation name of entry span as the endpoint, which are used in the OAL engine. Users could declare their custom endpoint names by adding the `logic endpoint` tag manually through agent's plugins or manual APIs. The logic endpoint is a concept that doesn't represent a real RPC call, but requires the statistic. The value of `x-le` should be in JSON format. There are two options: Define a new logic endpoint in the entry span as a separate new endpoint. Provide its own endpoint name, latency and status. Suitable for entry and local span. ```json { "name": "GraphQL-service", "latency": 100, "status": true } ``` Declare the current local span representing a logic endpoint. ```json { "logic-span": true } ``` guides users to write plugins with logic endpoint. Java agent's plugins include native included logic endpoints, also it provides ways to set the tag of logic span. The document could be found .
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_subscribe_auth_error.md

This alert indicates that there have been unauthorized MQTT (Message Queuing Telemetry Transport) v3/v5 SUBSCRIBE attempts in the last minute. This could mean that there are clients trying to subscribe to topics without proper authentication or authorization in your VerneMQ broker. In the MQTT protocol, clients can subscribe to topics to receive messages published by other clients to the broker. An unauthorized subscribe occurs when a client tries to subscribe to a topic but does not have the required permissions or has not provided valid credentials. Check the VerneMQ logs for unauthorized subscribe attempts: The first step in troubleshooting this issue is to check the VerneMQ logs to identify the source of the unauthorized attempts. Look for log messages related to authentication or authorization errors in the log files (`/var/log/vernemq/console.log` or `/var/log/vernemq/error.log`). Example log message: ``` date time [warning] <clientid>@<clientIP> MQTT SUBSCRIBE authorization failure for user "<username>", topic "<topic_name>" ``` Verify client authentication and authorization configuration: Check the client configurations to ensure they have the correct credentials (username and password) and are authorized to subscribe to the intended topics. Remember that topic permissions are case-sensitive and might have wildcards. Update the client configurations if necessary and restart the MQTT clients. Review the VerneMQ broker configurations: Verify the authentication and authorization plugins or settings in the VerneMQ broker (`/etc/vernemq/vernemq.conf` or `/etc/vernemq/vmq.acl` for access control). Make sure the settings are correctly configured to allow the clients to subscribe to the intended topics. Update the configurations if necessary and restart the VerneMQ broker. Monitor the unauthorized subscribe attempts using the Netdata dashboard or configuration file: Continue monitoring the unauthorized subscribe attempts using the Netdata dashboard or by configuring the alert thresholds in the Netdata configuration file. This will help you track the issue and ensure that the problem has been resolved.