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

key | value | date | 2024-02-01T08:07:44+00:00 version | 2.4.0b1 class | fix edition | cre component | multisite level | 1 compatible | yes Private topics were showing up in dropdowns (e.g. when editing dashboards). Now they are hidden if the user does not have permissions for them.
Project: Vector (Observability and Analysis / Observability)
File: 2021-07-14-0-15-upgrade-guide.md

date: "2021-07-14" title: "0.15 Upgrade Guide" description: "An upgrade guide that addresses breaking changes in 0.15.0" authors: ["jszwedko"] pr_numbers: [] release: "0.15.0" hideonrelease_notes: false badges: type: breaking change Vector's 0.15.0 release includes a few minor breaking changes: We cover each below to help you upgrade quickly: We've dropped support for Kubernetes version 1.14 as it is no longer a supported Kubernetes version nor do major cloud providers support it. This version of Kubernetes is likely to still work with Vector, but we will no longer be testing against it and cannot guarantee future versions of Vector will be compatible. In general, we will aim to match and along with the versions supported by major cloud providers. In version 0.12.0 we switched to using [VRL] as the default condition type for our transforms that take conditions (like `filter` and `route`), but the `sample` transform was not updated even though its documentation was. This release brings the `sample` transform in line with the others by making [VRL] the default condition type. This means, if you are presently using the deprecated `check_fields` syntax, you will need to add `type = "check_fields"` to your condition. For example, if you previously had: ```toml [transforms.sample] type = "sample" inputs = ["in"] rate = 10 key_field = "message" exclude."message.contains" = "error" ``` You will need to add `exclude.type = "check_fields"` like: ```toml [transforms.sample] type = "sample" inputs = ["in"] rate = 10 key_field = "message" exclude."type" = "check_fields" exclude."message.contains" = "error" ``` To convert this to the new conditions, you would write: ```toml [transforms.sample] type = "sample" inputs = ["in"] rate = 10 key_field = "message" exclude = """ contains!(.message, "error") """ ``` We recommend upgrading to the conditions as these are much more powerful than the legacy `check_fields`-style conditions. The `remap` condition type has been renamed `vrl` in this release to better highlight that the syntax for it is a program. Most examples of using this condition type have the short-hand condition config of just specifying the program without specifying a `type`. For example: ```toml [transforms.filter_a] inputs = ["stdin"] type = "filter" condition = ''' message = if exists(.tags) { .tags.message } else { .message } message == "test filter 1" ''' ``` Which is automatically a condition. However, if you were specifying the `type` like: ```toml [transforms.filter_a] inputs = ["stdin"] type = "filter" condition.type = "remap" condition.source = ''' message = if exists(.tags) { .tags.message } else { .message } message == "test filter 1" ''' ``` Then you will need to update `type = "remap"` to `type = "vrl"` like: ```toml [transforms.filter_a] inputs = ["stdin"] type = "filter" condition.type = "vrl" condition.source = ''' message = if exists(.tags) { .tags.message } else { .message } message == "test filter 1" ''' ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16531.md

key | value | date | 2024-03-27T15:41:36+00:00 version | 2.4.0b1 class | fix edition | cee component | ec level | 1 compatible | yes Messages missing the end of line terminator were ignored by mkeventd in some cases. This has been fixed.
Project: M3 (Observability and Analysis / Observability)
File: motivation.md

title: "Motivation" weight: 2 chapter: true We decided to open source the M3 platform as a scalable remote storage backend for Prometheus and Graphite so that others may attempt to reuse our work and avoid building yet another scalable metrics platform. As documentation for Prometheus states, it is limited by single nodes in its scalability and durability. The M3 platform aims to provide a turnkey, scalable, and configurable multi-tenant store for Prometheus, Graphite and other standard metrics schemas.
Project: Netdata (Observability and Analysis / Observability)
File: haproxy_backend_server_status.md

The `haproxybackendserver_status` alert is triggered when one or more backend servers that are managed by HAProxy are inaccessible or offline. HAProxy is a reverse-proxy that provides high availability, load balancing, and proxying for TCP and HTTP-based applications. If you receive this alert, it means that there may be a problem with your backend server(s), and incoming requests could face delays or not be processed correctly. Check the HAProxy backend server status You can check the status of each individual backend server by accessing the HAProxy Statistics Report. By default, this report can be accessed on the HAProxy server using the URL: ``` http://<Your-HAProxy-Server-IP>:9000/haproxy_stats ``` Replace `<Your-HAProxy-Server-IP>` with the IP address of your HAProxy server. If you have configured a different port for the statistics report, use that instead of `9000`. In the report, look for any backend server(s) with a `DOWN` status. Investigate the problematic backend server(s) For each of the backend servers that are in a `DOWN` status, check the availability and health of the server. Make sure that the server is running, and check its resources (CPU, memory, disk space, network) to identify any potential issues. Validate the HAProxy configuration As mentioned in the provided guide, it is essential to validate the correctness of the HAProxy configuration file. If you haven't already, follow the steps in the guide to check for any configuration errors or warnings. Check for recent changes If the backend servers were previously working correctly, inquire about any recent changes to the infrastructure, such as software updates or configuration changes. Restart the HAProxy service If the backend server(s) seem to be healthy, but the alert still persists, try restarting the HAProxy service: ``` sudo systemctl restart haproxy ``` Monitor the alert and backend server status After applying any changes or restarting the HAProxy service, monitor the alert and the backend server status in the HAProxy Statistics Report to see if the issue has been resolved.
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: django-admin.md

sidebar_label: Django Admin title: Django Admin sidebar_position: 100 Since the application is built using Django, it benefits from the django admin pages. Flagsmith is built to utilise the Django admin site for certain aspects of the platform. If you are self hosting, you may find it useful to access these pages at certain times. The admin pages are only available to uses that are designated as 'super users'. This can only be done when first setting up the platform or via the database. If you're just starting out, you can follow the instructions , otherwise, you need to set the `isstaff` and `issuperuser` flags against any of the users in your database. Once you have a user, you can access the django admin pages at `/admin/`. You will be prompted to log in with the credentials of any of your super users. :::info If the login page is only showing the option to 'Log in using SSO' then you may need to set the `ENABLEADMINACCESSUSERPASS` environment variable. See for more information. ::: The key pages that one might want to access are the ones that configuration organisations on the platform. From the home page of the admin, you'll see an link to `Organisations` about halfway down the page. From here, you can manage the organisations on your platform as required. For example, SAML configuration data must be set via these pages.
Project: Checkmk (Observability and Analysis / Observability)
File: 16420.md

key | value | date | 2024-04-08T09:28:55+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes Jolokia 2.0 was released 2023-12-19. With the release some changes to the Jolokia Protocol have been introduced. If a user installed this version of Jolokia, the check plugin `jolokia_info` showed `unknown` instead of the product information. After updating the agent plugin `mk_jolokia.py`, the correct information will be shown again.
Project: Netdata (Observability and Analysis / Observability)
File: scaleio_storage_pool_capacity_utilization.md

The `scaleiostoragepoolcapacityutilization` alert is related to storage capacity in ScaleIO, a software-defined storage solution. If you receive this alert, it means that the storage pool capacity utilization is high, potentially leading to performance issues or running out of space. High storage pool capacity utilization means that the allocated storage space in the ScaleIO storage pool is being used at a high percentage. Warning and critical alerts are triggered at 80-90% and 90-98% utilization, respectively. When the storage pool capacity utilization is high, it may impact the performance of the system and may prevent new data from being stored, as available space is limited. Verify the storage pool capacity utilization Check the Netdata dashboard or use Netdata API to verify the storage pool capacity utilization. Take note of the storage pools with high utilization. Investigate storage usage Inspect the storage usage in your environment, and determine which data or applications are consuming the most space. You can use tools like `du`, `df`, and `ncdu` to analyze disk usage. Delete or move unnecessary files If you found any unnecessary files or backup copies occupying large amounts of space, consider deleting them or moving them to different storage devices to free up space in the storage pool. Optimize storage provisioning Evaluate the storage provisioning for your applications, and ensure that appropriate storage space is allocated based on the actual needs. Adjust storage allocations if needed. Consider expanding the storage pool If the high storage pool capacity utilization is expected based on your application and data storage needs, consider expanding the storage pool by adding new devices or increasing the allocated storage space on the existing devices in the pool. Monitor storage pool capacity utilization trends Keep track of the storage pool capacity utilization trends and be proactive in addressing potential storage capacity issues in the future.
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-1.3.13.md

Bump `netty` from 4.1.96.Final to 4.1.97.Final () Bump `org.xerial.snappy:snappy-java` from 1.1.8.2 to 1.1.10.3 () Bump `com.squareup.okhttp3:okhttp` from 4.9.3 to 4.11.0 () Bump `com.squareup.okio:okio` from 2.8.0 to 3.5.0 ()
Project: Netdata (Observability and Analysis / Observability)
File: ipv6_socket_statistics.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/integrations/ipv6socketstatistics.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/metadata.yaml" sidebar_label: "IPv6 Socket Statistics" learn_status: "Published" learnrelpath: "Collecting Metrics/Linux Systems/Network" most_popular: False message: "DO NOT EDIT THIS FILE DIRECTLY, IT IS GENERATED BY THE COLLECTOR'S metadata.yaml FILE" endmeta--> <img src="https://netdata.cloud/img/network-wired.svg" width="150"/> Plugin: proc.plugin Module: /proc/net/sockstat6 <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> This integration provides IPv6 socket statistics. This collector is supported on all platforms. This collector supports collecting metrics from multiple instances of this integration, including remote instances. This integration doesn't support auto-detection. The default configuration for this integration does not impose any limits on data collection. The default configuration for this integration is not expected to impose a significant performance impact on the system. Metrics grouped by scope. The scope defines the instance that the metric belongs to. An instance is uniquely identified by a set of labels. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | ipv6.sockstat6tcpsockets | inuse | sockets | | ipv6.sockstat6udpsockets | inuse | sockets | | ipv6.sockstat6udplitesockets | inuse | sockets | | ipv6.sockstat6rawsockets | inuse | sockets | | ipv6.sockstat6fragsockets | inuse | fragments | There are no alerts configured by default for this integration. No action required. There is no configuration file. There are no configuration options. There are no configuration examples.
Project: Vector (Observability and Analysis / Observability)
File: 2021-04-21-vector-tap.md

date: "2021-04-21" title: "Introducing `vector tap`" description: "Observing events flowing through your Vector topologies" authors: ["jszwedko"] pr_numbers: [6871] release: "0.13.0" hideonrelease_notes: false badges: type: new feature domains: ["graphql", "cli", "observability"] Vector 0.13 introduces a new subcommand that allows for tapping into the events flowing through Vector. This can be used to "live tail" events while troubleshooting incidents events or simply to debug your Vector config, replacing the current common approach of sending the events to a sink. To use you must first enable Vector's . Then, you can use `vector tap <component id>` to sample the events flowing out of this component. For example, given the configuration: ```toml [api] enabled = true [sources.in] type = "generator" format = "shuffle" interval = 1.0 lines = ["Hello World"] sequence = true [sinks.out] type = "blackhole" inputs = ["in"] ``` If you were to run `vector` and then, in another terminal, run `vector tap in`, you would see something like: ```json {"message":"13 Hello World","timestamp":"2021-04-20T19:40:32.359390Z"} {"message":"14 Hello World","timestamp":"2021-04-20T19:40:33.355298Z"} {"message":"15 Hello World","timestamp":"2021-04-20T19:40:34.353215Z"} {"message":"16 Hello World","timestamp":"2021-04-20T19:40:35.353493Z"} {"message":"17 Hello World","timestamp":"2021-04-20T19:40:36.352089Z"} {"message":"18 Hello World","timestamp":"2021-04-20T19:40:37.347406Z"} ``` With the events formatted as JSON. Like , this command is made possible by `vector` through its . You can interact directly with the API if you want to take advantage of tapping events programmatically. We intend to make the command even more powerful by: Allowing sampling of metrics events Allowing events to be formatted as logfmt rather than just JSON or YAML Allowing sampling of events going into a component rather than out of it Allowing tighter control over how events are sampled Have an idea of how to make even more useful? [Let us know][community].
Project: Graylog (Observability and Analysis / Observability)
File: Popover.md

```js <div style={{ height: 200, position: 'relative' }}> <Popover id="popover-basic" placement="right" positionLeft={200} positionTop={50} title="Popover right" > And here's some <strong>amazing</strong> content. It's very engaging. right? </Popover> </div> ``` ```js import { ButtonToolbar, Button, Popover } from 'components/bootstrap'; import { OverlayTrigger } from 'components/common'; const popoverLeft = ( <Popover id="popover-positioned-left" title="Popover left"> <strong>Holy guacamole!</strong> Check this info. </Popover> ); const popoverTop = ( <Popover id="popover-positioned-top" title="Popover top"> <strong>Holy guacamole!</strong> Check this info. </Popover> ); const popoverBottom = ( <Popover id="popover-positioned-bottom" title="Popover bottom"> <strong>Holy guacamole!</strong> Check this info. </Popover> ); const popoverRight = ( <Popover id="popover-positioned-right" title="Popover right"> <strong>Holy guacamole!</strong> Check this info. </Popover> ); <ButtonToolbar> <OverlayTrigger trigger="click" placement="left" overlay={popoverLeft}> <Button>Holy guacamole!</Button> </OverlayTrigger> <OverlayTrigger trigger="click" placement="top" overlay={popoverTop}> <Button>Holy guacamole!</Button> </OverlayTrigger> <OverlayTrigger trigger="click" placement="bottom" overlay={popoverBottom}> <Button>Holy guacamole!</Button> </OverlayTrigger> <OverlayTrigger trigger="click" placement="right" overlay={popoverRight}> <Button>Holy guacamole!</Button> </OverlayTrigger> </ButtonToolbar> ```
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: rewrite.md

title: Syslog-NG rewrite weight: 200 generated_file: true The syslog-ng rewrite filter can be used to replace message parts. Default: - Default: - Default: - Default: - Default: - https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.37/administration-guide/78#TOPIC-1829213 Default: - Default: - Default: - https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.37/administration-guide/77#TOPIC-1829207 Default: - Default: - Default: - https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.37/administration-guide/77#TOPIC-1829206 Default: - Default: - Default: - Default: - Default: - Default: - https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.37/administration-guide/78#TOPIC-1829212 Default: - Default: - https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.37/administration-guide/78#TOPIC-1829212 Default: - Default: -
Project: Teletrace (Observability and Analysis / Observability)
File: faq.md

Teletrace is an open-source, end-to-end distributed tracing system used for monitoring and troubleshooting complex distributed systems. It allows developers and operations teams to trace the flow of requests through their distributed systems, identify performance bottlenecks, and diagnose issues in near real-time. You can create traces and send them to Teletrace by using . OpenTelemetry is a popular open-source observability framework that provides APIs, libraries, and agents to instrument, generate, collect, and export telemetry data. To create traces using OpenTelemetry, you need to add the to your application and use it to instrument your code. The SDK provides a range of libraries and instrumentations for various programming languages and frameworks. Once you've instrumented your code, OpenTelemetry will automatically generate traces and send them to the configured backend. To send traces to Teletrace, you need to configure your OpenTelemetry exporter to use the otlp or otlphttp endpoint. This can be done by setting the exporter's configuration . Once configured, OpenTelemetry will send the generated traces to Teletrace's backend, where you can visualize and analyze them using the Teletrace UI. Overall, using OpenTelemetry with Teletrace can provide a powerful observability solution for distributed systems, allowing you to gain insights into the performance and behavior of your applications. The recommended way to deploy Teletrace is to deploy our to a Kubernetes cluster. Additionally Teletrace is packaged as a standard that can run locally or be deployed to any cloud service that can handle container images (e.g. AWS ECS). Check out our detailed . Teletrace is using plugins to store data in different storage backends, this allows the platform to be extended to the users' use-case with ease. currently supported plugins: ElasticSearch (version 8+) SQLite The choice of storage system depends on the specific use case and requirements.
Project: Thanos (Observability and Analysis / Observability)
File: 202106-proposals-process.md

type: proposal title: Proposal Process status: complete owner: bwplotka menu: proposals-done Owners:*: Other docs:* * TL;DR: We would like to propose an improved, official proposal process for Thanos that clearly states when, where and how to create proposal/enhancement/design documents. We propose to store done, accepted and rejected proposals in markdown in the main Thanos repo. More extensive architectural, process, or feature decisions are hard to explain, understand and discuss. It takes a lot of time to describe the idea, to motivate interested parties to review it, give feedback and approve. That's why it is essential to streamline the proposal process. Given that as open-source community we work in highly distributed teams and work with multiple communities, we need to allow asynchronous discussions. This means it's essential to structure the talks into shared documents. Persisting those decisions, once approved or rejected, is equally important, allowing us to understand previous motivations. There is a common saying . We want to ensure the team related knowledge is accessible to everyone, every day, no matter if the team member is new or part of the team for ten years. Thanos process was actually following proposed process. We were just missing written rationales and official template that will make Thanos community easier to propose new ideas and motivate them! Goals and use cases for the solution as proposed in : Allow easy collaboration and decision making on design ideas. Have a consistent design style that is readable and understandable. Ensure design docs are discoverable for better awareness and knowledge sharing about past decisions. Define a clear review and approval process. Define process for other type of documents. We want to propose an improved, official proposal process for Thanos Community that clearly states when, where and how to create proposal/enhancement/design documents. See
Project: Loggie (Observability and Analysis / Observability)
File: CHANGES.md

Migrated to godep, as depman is not longer supported Introduced golang vendoring feature Fixed issue related to reopen deleted file Fix inotify watcher leak; remove `Cleanup` (#51) Don't return partial lines (PR #40) Use stable version of fsnotify (#46) Fix tail for Windows (PR #36) Improved rate limiting using leaky bucket (PR #29) Fix odd line splitting (PR #30) LimitRate now discards read buffer (PR #28) allow reading of longer lines if MaxLineSize is unset (PR #24) updated deps.json to latest fsnotify (441bbc86b1) added `Config.Logger` to suppress library logging add Cleanup to remove leaky inotify watches (PR #20) redesigned Location field (PR #12) add tail.Tell (PR #14) Rate limiting (PR #10) Detect file deletions/renames in polling file watcher (PR #1) Detect file truncation Fix potential race condition when reopening the file (issue 5) Fix potential blocking of `tail.Stop` (issue 4) Fix uncleaned up ChangeEvents goroutines after calling tail.Stop Support Follow=false Initial open source release