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

This alert indicates a high ratio of waited table locks in your MySQL database over the last 10 seconds. If you receive this alert, it means that there might be performance issues due to contention for table locks. Table locks are a method used by MySQL to ensure data consistency and prevent multiple clients from modifying the same data at the same time. When a client attempts to modify data, it must first acquire a lock on the table. If the lock is not available, the client must wait until the lock is released by another client. Identify problematic queries: Use the following command to display the queries that are causing table locks in your MySQL database: ``` SHOW FULL PROCESSLIST; ``` Look for queries with a state of `'Locked'` or `'Waiting for table lock'` and note down their details. Optimize your queries: Analyze the problematic queries identified in the previous step and try to optimize them. You can use `EXPLAIN` or other similar tools to get insights into the performance of the queries. Consider splitting your table(s): If the problem persists after optimizing the queries, consider splitting the large tables into smaller ones. This can help to reduce contention for table locks and improve performance. Use replication: Another solution to this issue is the implementation of MySQL replication, which can reduce contention for table locks by allowing read queries to be executed on replica servers rather than the primary server.
Project: Keep (Observability and Analysis / Observability)
File: README.md

Instructions for Jira On Prem Start Jira On Prem with docker - https://hub.docker.com/r/atlassian/jira-software/ Create Personal Access Token (PAT) - https://confluence.atlassian.com/enterprise/using-personal-access-tokens-1026032365.html Create some project/board Profit :) 1234","name": "Kafka Alert","status": "firing", "lastReceived": "2023-10-23T09:56:44.950Z","environment": "production","isDuplicate": false, "duplicateReason": null, "service": "backend","message": "Alert from Kafka", "description": "Alert kafka description", "severity": "critical", "pushed": true, "eventid": "1234", "url": "https://www.google.com/search?q=open+source+alert+management"}' | kafkacat -v -b kafka:9092 -t alert -P -X security.protocol=SASLPLAINTEXT -X sasl.mechanisms=PLAIN -X sasl.username=admin -X sasl.password=admin-secret ``` ```bash echo '{"id": "1234","name": "Kafka Alert","status": "firing", "lastReceived": "2023-10-23T09:56:44.950Z","environment": "production","isDuplicate": false, "duplicateReason": null, "service": "backend","message": "Alert from Kafka", "description": "Alert kafka description", "severity": "critical", "pushed": true, "event_id": "1234", "url": "https://www.google.com/search?q=open+source+alert+management"}' | kafkacat -v -b kafka:9092 -t alert -P ``` ```bash kafkacat -v -b kafka:9092 -t alert -C -X security.protocol=SASL_PLAINTEXT -X sasl.mechanisms=PLAIN -X sasl.username=admin -X sasl.password=admin-secret ```
Project: Thanos (Observability and Analysis / Observability)
File: bug-report.md

name: "\U0001F41B Bug Report" about: Something isn't working as expected title: '' assignees: '' <!-- Template relevant to bug reports only! Keep issue title verbose enough and add prefix telling about what components it touches e.g "query:" or ".*:" --> <!-- In case of issues related to exact bucket implementation, please ping corresponded maintainer from list here: https://github.com/thanos-io/thanos/blob/main/docs/storage.md --> Thanos, Prometheus and Golang version used: <!-- Output of "thanos --version" or docker image:tag used. (Double-check if all deployed components/services have expected versions) If you are using custom build from main branch, have you checked out the tip of the main? --> Object Storage Provider: What happened: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Full logs to relevant components: <!-- Uncomment if you would like to post collapsible logs: <details>Logs <p> ``` ``` </p> </details> --> Anything else we need to know: <!-- Uncomment and fill if you use not casual environment or if it might be relevant. Environment: OS (e.g. from /etc/os-release): Kernel (e.g. `uname -a`): Others: -->
Project: Grafana (Observability and Analysis / Observability)
File: e2e-plugins.md

When end-to-end testing Grafana plugins, it's recommended to use the testing tool. `@grafana/plugin-e2e` extends capabilities with relevant fixtures, models, and expect matchers; enabling comprehensive end-to-end testing of Grafana plugins across multiple versions of Grafana. For information on how to get started with Plugin end-to-end testing and Playwright, checkout the guide. Playwright end-to-end tests for plugins should be added to the directory. Add a new directory that has the name as your plugin . This is where your plugin tests will be kept. Playwright uses to logically group tests together. All tests in a project share the same configuration. In the , add a new project item. Make sure the `name` and the `testDir` sub directory matches the name of the directory that contains your plugin tests. Adding `'authenticate'` to the list of dependencies and specifying `'playwright/.auth/admin.json'` as storage state will ensure all tests in your project will start already authenticated as an admin user. If you wish to use a different role for and perhaps test RBAC for some of your tests, please refer to the plugin-e2e . ```ts { name: 'mysql', testDir: path.join(testDirRoot, '/mysql'), use: { ...devices['Desktop Chrome'], storageState: 'playwright/.auth/admin.json', }, dependencies: ['authenticate'], }, ``` Update the file so that your team is owner of the tests in the directory you added in step 1. `yarn e2e:playwright` will run all Playwright tests. Optionally, you can provide the `--project mysql` argument to run tests in a certain project. The script above assumes you have Grafana running on `localhost:3000`. You may change this by providing environment variables. `HOST=127.0.0.1 PORT=3001 yarn e2e:playwright`
Project: Grafana Mimir (Observability and Analysis / Observability)
File: v4.0.md

title: "Grafana Mimir Helm chart version 4.0 release notes" menuTitle: "V4.0 release notes" description: "Release notes for Grafana Mimir Helm chart version 4.0" weight: 300 Grafana Labs is excited to announce version 4.0 of the Grafana Mimir Helm chart, which is compatible with Grafana Mimir v2.5 and Grafana Enterprise Metrics v2.5. The `mimir-distributed` Helm chart is the best way to install Mimir on Kubernetes. To learn about new features and enhancements in Grafana Mimir or GEM, see the release notes for or . The highlights that follow include the top features, enhancements, and bugfixes in this release. For a comprehensive list of changes, see the . Note: If you are upgrading from Grafana Mimir Helm chart 3.3, review the that follow. Notable enhancements are as follows: Zone aware replication Helm now supports deploying the ingesters and store-gateways as different availability zones. The replication is also zone-aware, therefore multiple instances of one zone can fail without any service interruption and rollouts can be performed faster because many instances of each zone can be restarted together, as opposed to them all restarting in sequence. Running without root privileges All Mimir, GEM, and Agent processes no longer require root privileges to run. Unified reverse proxy (`gateway`) configuration for Mimir and GEM This change allows you to more easily upgrade from Mimir to GEM, without any downtime. The unified configuration also makes it possible to autoscale the GEM gateway pods and it supports OpenShift Route. The change also deprecates the `nginx` section in the configuration. The section will be removed in release `7.0.0`. Various quality of life improvements Rollout strategies with zero downtime Read-path and compactor configuration provide better default settings OTLP ingestion support in the Nginx configuration A default configuration for Alertmanager: its user interface, as well as the sending of alerts from the ruler, work out of the box In Grafana Mimir Helm chart v4.0, the following changes were made: Breaking change, zone aware replication is enabled by default, which can cause data loss if upgrade procedure is not followed, . We updated our sizing plans to make them better reflect how we recommend running Mimir and GEM in production. Breaking change, due to the sizing plans updates, users of the small plan must consult the . Updated MinIO The MinIO sub-chart was updated from `4.x` to `5.0.0`. This update inherits a breaking change because the MinIO gateway mode was removed. : Fix an issue that caused metamonitoring secrets to be created incorrectly. : Nginx: fixed imagePullSecret value reference inconsistency. : Move the activity tracker log from /data to /active-query-tracker to remove ignore log messages. : Fix Invalid ingress nginx config due to newline in prometheusHttpPrefix Helm named templates. : Added missing endpoint for OTLP in NGINX.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: querying.md

title: Use Tempo with Grafana menuTitle: Use Tempo with Grafana description: Learn how to configure and query Tempo with Grafana. weight: 900 <!-- Page is being deprecated because it describes versions of Grafana that are no longer supported. --> You can use Tempo as a data source in Grafana to Tempo can query Grafana directly. Grafana Cloud comes pre-configured with a Tempo data source. If you are using Grafana on-prem, you need to . {{< admonition type="tip" >}} If you want to see what you can do with tracing data in Grafana, try the . {{% /admonition %}} This video explains how to add data sources, including Loki, Tempo, and Mimir, to Grafana and Grafana Cloud. Tempo data source set up starts at 4:58 in the video. {{< youtube id="cqHO0oYW6Ic" >}} For detailed instructions on the Tempo dta source in Grafana, refer to . To configure Tempo with Grafana: Point the Grafana data source at your Tempo query frontend (or monolithic mode Tempo). Enter the URL: `http://<tempo hostname>:<http port number>`. For most of the following works. The port of 3200 is a common port used in our examples. Tempo default HTTP port is 80. Refer to for an overview about how tracing data can be viewed and used in Grafana. For information on querying the Tempo data source, refer to .
Project: Netdata (Observability and Analysis / Observability)
File: systemd_path_unit_failed_state.md

This alert is triggered when a `systemd path unit` enters a `failed state`. Service units in a failed state indicate an issue with the service's startup, runtime, or shutdown, which can result in the service being marked as failed. `systemd` is an init system and system manager that manages services and their dependencies on Linux systems. A `path unit` is a type of unit configuration file that runs a service in response to the existence or modification of files and directories. These units are used to monitor files and directories and trigger actions based on changes to them. Identify the failed systemd path unit First, you need to identify which path unit is experiencing issues. To list all failed units: ``` systemctl --state=failed ``` Take note of the units indicated as 'path' in the output. Inspect the path unit status To get more details about the specific failed path unit, run: ``` systemctl status <failed-path-unit> ``` Replace `<failed-path-unit>` with the name of the failed path unit you identified previously. Review logs for the failed path unit To view the logs for the failed path unit, use the `journalctl` command: ``` journalctl -u <failed-path-unit> ``` Again, replace `<failed-path-unit>` with the name of the failed path unit. Review the logs to identify possible reasons for the failure. Reload the unit configuration (if necessary) If you discovered an issue in the unit configuration file and resolved it, reload the configuration by running: ``` sudo systemctl daemon-reload ``` Restart the failed path unit Once you have identified and resolved the issue causing the failed state, try to restart the path unit: ``` sudo systemctl restart <failed-path-unit> ``` Replace `<failed-path-unit>` with the name of the failed path unit. Then, monitor the path unit status to ensure it is running without issues.
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_registry.HeadlampEvent.md

title: "Interface: HeadlampEvent<EventType>" linkTitle: "HeadlampEvent" slug: "plugin_registry.HeadlampEvent" .HeadlampEvent Represents a Headlamp event. It can be one of the default events or a custom event. | Name | Type | | : | : | | `EventType` | `HeadlampEventType` \| `string` | `HeadlampEvent` `Optional` data: `unknown` _ type: `EventType`
Project: Vector (Observability and Analysis / Observability)
File: 2020-01-03-move-existing-tcp-sink-into-socket-sink.md

date: "2020-07-13" title: "Rename existing `tcp` sink to `socket` sink" description: "This renames the existing `tcp` sink to `socket`" authors: ["binarylogic"] pr_numbers: [1404] release: "0.7.0" hideonrelease_notes: false badges: type: "breaking change" domains: ["sinks"] sinks: ["tcp"] The `tcp` sink has been renamed to `socket`. This is part of an overall effort to simplify our sinks in a manner where they can easily be "wrapped" as the foundation for upcoming sinks. ```diff title="vector.toml" [sources.mytcpsink] type = "tcp" type = "socket" address = "92.12.333.224:5000" mode = "tcp" ```
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-7-3-3.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 7.3.3 <!-- Auto generated by update changelog github action --> Cloud monitoring: Fix for multi-value template variable for project selector. , LogsPanel: Fixes problem dragging scrollbar inside logs panel. , Provisioning: Fixes application not pinned to the sidebar when it's enabled. , StatPanel: Fixes hanging issue when all values are zero. , Thresholds: Fixes color assigned to null values. ,
Project: Vector (Observability and Analysis / Observability)
File: aws_ec2_metadata.md

title: AWS EC2 metadata description: Parse metadata emitted by instances component_kind: transform layout: component tags: ["aws", "ec2", "metadata", "component", "transform"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Netdata (Observability and Analysis / Observability)
File: boinc_total_tasks.md

This alert monitors the average number of total tasks for the BOINC system over the last 10 minutes. If you receive this alert, it means that there is a deviation in the number of total tasks for your BOINC system, which may indicate an issue with the projects, the client, or even the tasks themselves. Verify that the projects you contribute to are not suspended. You can check if the project has queued tasks to be done on the . Access your BOINC Manager, go to the Projects tab, and check if the projects you contribute to are in the correct state (Active or Running). If a project is suspended, you can select it and click Resume to reactivate it. Access your BOINC Manager and go to the Tasks tab to check the status of the current tasks. Look for any Failed, Error, or Postponed tasks. If there are failed tasks, try to reset them by selecting the task, right-clicking on it, and choosing Update or Reset. Be aware that resetting a task will discard any progress made on it. For most Linux distributions: ``` sudo /etc/init.d/boinc-client restart ``` BOINC tasks may fail or slow down if there is not enough system resources (CPU, RAM, or Disk Space) available. Monitor your system performance using tools like `top`, `free`, and `df`, and make adjustments if necessary to ensure that BOINC has enough resources to complete tasks.
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: kafka.md

sidebar_position: 6 The Kafka exporter produces messages to a Kafka topic for each event generated. ```go ffclient.Config{ // ... DataExporter: ffclient.DataExporter{ // ... Exporter: &kafkaexporter.Exporter{ Settings: kafkaexporter.Settings{ Topic: "go-feature-flag-events", Addresses: []string{"cluster1", "cluster2"}, }, }, }, // ... } ``` | Field | Description | |--|-| | `Topic ` | Name of the topic to publish messages | | `Addresses ` | The list of addresses for the Kafka boostrap servers | | `Config ` | (Optional) An instance of `*sarama.Config` that holds additional settings for the producer, such as timeouts, TLS settings, etc. If not populated, a default will be used by calling `sarama.NewConfig()` | | | Check the .
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_apiProxy.StreamArgs.md

title: "Interface: StreamArgs" linkTitle: "StreamArgs" slug: "libk8sapiProxy.StreamArgs" .StreamArgs Configure a stream with... StreamArgs. `StreamArgs` `Optional` additionalProtocols: `string`[] Additional WebSocket protocols to use when connecting. _ `Optional` cluster: `string` _ `Optional` isJson: `boolean` Whether the stream is expected to receive JSON data. _ `Optional` reconnectOnFailure: `boolean` Whether to attempt to reconnect the WebSocket connection if it fails. _ `Optional` stderr: `boolean` _ `Optional` stdin: `boolean` _ `Optional` stdout: `boolean` _ `Optional` tty: `boolean` `Optional` connectCb(): `void` A callback function to execute when the WebSocket connection is established. `void` _ `Optional` failCb(): `void` A callback function to execute when the WebSocket connection fails. `void`
Project: Grafana Loki (Observability and Analysis / Observability)
File: CONTRIBUTION.md

Ensure the bug was not already reported* by searching on GitHub under . If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a title and clear description. Be sure to include the actual behavior vs the expected. As much relevant information as possible, a code sample or an executable test case demonstrating the expected vs actual behavior. Ensure that all bugs are first reported as an issue. This will help others in finding fixes through issues first. Open a PR referencing the issue for the bug. We are open to all Pull Requests, its best to accompany the requests with an issue. The PR requires the github actions to pass. Requires at least one maintainer to approve the PR to merge to master. While the above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted. Since this library is a core client for interacting with Zookeeper, we do releases to ensure predictable changes for users. Zookeeper itself maintains a compatibility check on the main codebase as well as maintaining backwards compatibility through all Major releases, this core library will try to uphold similar standards of releases. Code that is merged into master should be ready for release at any given time. This is to say, that code should not be merged into master if it is not complete and ready for production use. If a fix needs to be released ahead of normal operations, file an issue explaining the urgency and impact of the bug. Some good external resources for style: All code should be error-free when run through `golint` and `go vet`. We recommend setting up your editor to: Run `goimports` on save Run `golint` and `go vet` to check for errors You can find information in editor support for Go tools here: <https://github.com/golang/go/wiki/IDEsAndTextEditorPlugins> We have zero external dependencies, and would like to maintain this. Use of any external go library should be limited to tests.
Project: Thanos (Observability and Analysis / Observability)
File: how-to-contribute-to-docs.md

`./docs` directory is used as markdown source files using to render Thanos website resources. However the aim for those is to also have those `*.md` files renderable and usable (including links) via GitHub. To make that happen we use following rules and helpers that are listed here. is essential on top of every markdown file if you want to link this file into any menu/submenu option. We use YAML formatting. This will render in GitHub as markdown just fine: ```md title: <title> type: ... weight: <weight> menu: <where to link files in> # This also is referred in permalinks. ``` Aim is to match linking behavior in website being THE SAME as Github. This means: For files in Hugo <content> dir (so `./docs`). Put `slug: /<filename with extension>` For any sub dir add to `website/hugo.yaml` new dir as key `permalinks:` with `<dir>: /<dir>/:filename.md` Then everywhere use native markdown absolute path to the project repository if you want to link to exact commit e.g: ``` ``` Small adjusts link for Hugo rendering. NOTE: Spaces matters so: `[xxx]( link` and `[xxx] (link` will not work. Why? Links works on GitHub Links works on website Markdown plugins works as expected (e.g IDE integrations) We use markdown-link-check to test links New menus `.Site.Menus` are added as soon as some file has Front Matter with certain `menu`. Keep `menu` the same as sub-directory the file is in. This will help to manage all docs. Show new menu section in main page by changing `website/layouts/_default/baseof.html` file. We'd love to showcase your company's logo on our main page and README! Requirements for the company: it is using Thanos on production it is a legal registered company it is happy to announce that you use Thanos publicly If all those are met, add yourself in like so: ```yml name: My Awesome Company url: https://wwww.company.com logo: company.png ``` Copy your company's logo in , make sure it follows these rules: Rectangle shape Greyscale is preferred but color is fine Keep it under 50KB and create PR against Thanos `main` branch. We want all docs to not have any white noise. To achieve it, we provide under `scripts` to check. You can call it before a pull request, also PR test would call it too. On every PR we build the website and on success display the link to the preview under the checks at the bottom of the github PR. To test the changes to the docs locally just start serving the website by running the following command and you will be able to access the website on `localhost:1313` by default: ```bash make web-serve ``` We use for hosting. We are using Open Source license (PRO). Thanks Netlify for this! On every commit to `main` netlify runs CI that invokes `make web` (defined in ) NOTE: Check for status badge in README for build status on the page. If main build for netlify succeed, the new content is published automatically.
Project: Vector (Observability and Analysis / Observability)
File: databend.md

title: Databend description: Deliver log data to the database component_kind: sink layout: component tags: ["datafuselabs", "databend", "component", "sink", "storage", "logs"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-1-0-beta3.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 8.1.0-beta3 <!-- Auto generated by update changelog github action --> Alerting: Support label matcher syntax in alert rule list filter. , IconButton: Put tooltip text as aria-label. , Live: Experimental HA with Redis. , UI: FileDropzone component. , , Docker: Fix builds by delaying go mod verify until all required files are copied over. , Exemplars: Fix disable exemplars only on the query that failed. , SQL: Fix SQL dataframe resampling (fill mode + time intervals). ,