cwielenb/CNCF-Dataset huggingface dataset:
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: ---bug-report.md

name: " Bug report" about: Create a report to help us improve title: '' labels: bug assignees: '' Bugs should be filed for issues encountered whilst operating logging-operator. You should first attempt to resolve your issues through the community support channels, e.g. Slack, in order to rule out individual configuration errors. Please provide as much detail as possible. Describe the bug: A clear and concise description of what the bug is. Expected behaviour: A concise description of what you expected to happen. Steps to reproduce the bug: Steps to reproduce the bug should be clear and easily reproducible to help people gain an understanding of the problem. Additional context: Add any other context about the problem here. Environment details: Kubernetes version (e.g. v1.15.2): Cloud-provider/provisioner (e.g. AKS, GKE, EKS, PKE etc): logging-operator version (e.g. 2.1.1): Install method (e.g. helm or static manifests): Logs from the misbehaving component (and any other relevant logs): Resource definition (possibly in YAML format) that caused the issue, without sensitive data: /kind bug
Project: Checkmk (Observability and Analysis / Observability)
File: 15845.md

key | value | date | 2024-04-22T15:31:08+00:00 version | 2.4.0b1 class | fix edition | cee component | checks level | 1 compatible | no Previously, some Windows network interface names with additional spaces particularly before the hash symbol were not recognized by the check engine. This led to the absence of some services, especially Windows teaming network interfaces. In this release, such interface names are handled correctly thus fixing the problem. Still, you may need to rediscover services again.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_ingressClass.KubeIngressClass.md

title: "Interface: KubeIngressClass" linkTitle: "KubeIngressClass" slug: "libk8singressClass.KubeIngressClass" .KubeIngressClass `KubeIngressClass` `Optional` apiVersion: `string` . _ kind: `string` Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. In CamelCase. Cannot be updated. `see` . _ metadata: . _ spec: `Object` | Name | Type | | : | : | | `controller` | `string` |
Project: Vector (Observability and Analysis / Observability)
File: RELEASES.md

This document covers Vector's releases and the relevant aspect for Vector users. <!-- MarkdownTOC autolink="true" style="ordered" indent=" " --> 1. 1. 1. 1. <!-- /MarkdownTOC --> The stable release channel includes official Vector releases with a semantic version. The nightly channel is released nightly, based off of the current state of the [`master` branch]. No guarantees are made with this branch. It may include experimental or breaking changes. Go to our [GitHub repository] and click the "watch" button in the top right. Click "Custom" and then "Releases" to only be notified for new releases. See the [GitHub subscription docs] for more info. Subscribe to the [Vector public calendar], release events are added. Follow [@vectordotdev] on Twitter. Head to our [chat], watch the `#announcements` channel, and configure notifications accordingly. If you are using a [package manager], you should be able to see the update available when updating your package lists. Releases will appear in our [nightly artifact list] every night. Please head over to Vector's [download page]. Every 6 weeks* Release patch fixes as needed to fix high-priority bugs and regressions from the last major or minor release Release daily builds representing the latest state of Vector for feedback Every night* Please see the [versioning policy]. We always appreciate early feedback on Vector as we are developing it to help ensure the highest quality releases. If you are able to, running a nightly release of Vector allows you to test out unreleased features and fixes and provide feedback to guide our development. We aim to keep nightly as stable as possible through integration testing, but there will occasionally be issues that slip through and are fixed for the next nightly release. For example, you could choose to run the nightly version in your development environments and save stable for production. Otherwise, the stable release is your best bet.
Project: OpenTelemetry (Observability and Analysis / Observability)
File: event-api.md

The Client / RUM Sig is looking to finalize, complete and resolve the outstanding issues / PR's that exist around the Event API / SDK and the Semantic Conventions that defines what an "event" is. Project Board: https://github.com/orgs/open-telemetry/projects/65 Resolve the outstanding Event Issues / PR's which will define Refine / stabilize event data model describing what an event is, the semantic meaning of event fields, and how they are sent over the network. Pave the way for defining event semantic conventions, allowing their schemas to be described in YAML and incorporated into build-tools. Define select event semantic conventions, establishing patterns for future event semantic conventions to follow. Refine / stabilize event API and any associated features in the SDK. Need: more domain experts willing to define the OTel Event standard Need: engineers willing to write prototypes in at least one more language other than JavaScript. Language should be fairly different from JavaScript. Need: maintainers or approvers from those languages committed to reviewing the prototypes. Project lead(s): @MSNev (JavaScript) Sponsors: @trask @tedsuo Contributing Engineers: @martinkuba (JavaScript) @scheler @patrickhousley @breedx-splk Implementation Engineers: @dennisme (Golang) Implementation Maintainers / Approvers: @MSNev @martinkuba @scheler SIG meeting times: Friday 10am - 11am PT Completed: Q2 2024 Define EventLogger SDK Deliver API & SDK prototype for Web JS Define how the contents of the log body field are described as semantic conventions Q3 2024 Define the relationship between OTel Events and CloudEvents Project completed, Event SIG disbanded See the project board for a collection of Issues related to the project. The `spec:events` label is used to describe all spec Issues and PRs related to events.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: MENTORING.md

This document serves as a comprehensive record of mentees, mentors, issues, and blogs associated with prominent open source programs such as LFX Mentorship, Google Summer of Code, Google Season of Docs, and Outreachy. Its primary objective is to provide an organized overview of mentoring activities and effectively track the progress made within the project. | Program | Timeline | Mentee | Mentor(s) | Github Issue | Blog(s) | |--|-|-|-||-| | Google Summer of Code (GSoC) | May 17th - August 31st, 2021 | | , | https://github.com/litmuschaos/litmus/issues/2483 | , | | LFX Mentorship | September 1st - November 31st, 2021 | | , | https://github.com/litmuschaos/litmus/issues/3114 | | | LFX Mentorship | September 1st - November 31st, 2021 | | , | https://github.com/litmuschaos/litmus/issues/3112 | , | | LFX Mentorship | March 1st - May 31st, 2022 | | , | https://github.com/litmuschaos/litmus/issues/3440 | -- | | LFX Mentorship | March 1st - May 31st, 2023 | | , | https://github.com/litmuschaos/litmus/issues/3892 | , | | LFX Mentorship | June 1st - August 31st, 2023 | | , | https://github.com/litmuschaos/litmus/issues/3970 | -- | | LFX Mentorship | June 1st - August 31st, 2023 | | , | https://github.com/litmuschaos/litmus/issues/3969 | | | LFX Mentorship | September 1st - November 30th, 2023 | | , | https://github.com/litmuschaos/litmus/issues/4102 | | | LFX Mentorship | September 1st - November 30th, 2023 | | , | https://github.com/litmuschaos/litmus/issues/4101 | -- Refer to the repository for more details. We sincerely thank all the mentors, mentees, organizations, and programs involved in this project for their invaluable support and contributions. Their dedication and commitment play a vital role in the success of our mentoring initiatives. --x--
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: s3.md

sidebar_position: 3 The will use the to access your flag in an S3 bucket. ```go linenums="1" err := ffclient.Init(ffclient.Config{ PollingInterval: 3 * time.Second, Retriever: &s3retriever.Retriever{ Bucket: "tpoi-test", Item: "flag-config.yaml", AwsConfig: aws.Config{ Region: aws.String("eu-west-1"), }, }, }) defer ffclient.Close() ``` To configure your S3 file location: | Field | Description | ||| |`Bucket`| The name of your bucket.| |`Item`| The location of your file in the bucket.| |`AwsConfig`| An instance of `aws.Config` that configure your access to AWS <br/>check .|
Project: Prometheus (Observability and Analysis / Observability)
File: PULL_REQUEST_TEMPLATE.md

<!-- Please give your PR a title in the form "area: short description". For example "tsdb: reduce disk usage by 95%" If your PR is to fix an issue, put "Fixes #issue-number" in the description. Don't forget! Please sign CNCF's Developer Certificate of Origin and sign-off your commits by adding the -s / --signoff flag to `git commit`. See https://github.com/apps/dco for more information. If the PR adds or changes a behaviour or fixes a bug of an exported API it would need a unit/e2e test. Where possible use only exported APIs for tests to simplify the review and make it as close as possible to an actual library usage. Performance improvements would need a benchmark test to prove it. All exposed objects should have a comment. All comments should start with a capital letter and end with a full stop. -->
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-hostgroup_template_bind.md

category: HostGroup apiurl: '/api/v1/hostgroup/template' title: "Bind A Template to HostGroup" type: 'POST' sample_doc: 'hostgroup.html' layout: default Required ```{ "tpl_id": 5, "grp_id": 3 }``` ```Status: 200``` ```{"grpid":3,"tplid":5,"bind_user":2}```
Project: HertzBeat (Observability and Analysis / Observability)
File: ftp.md

id: ftp title: Monitoring FTP sidebar_label: FTP Monitor keywords: [ open source monitoring tool, open source ftp server monitoring tool, monitoring ftp metrics ] Collect and monitor the general performance Metrics of FTP server. Protocol UseFTP | Parameter name | Parameter help description | ||--| | Target Host | Monitored IPV4, IPV6 or domain name. NoteWithout protocol header (eg: ftp://). | | Monitoring name | Identify the name of this monitoring, The name needs to be unique. | | Port | Port provided by FTP server ,default is 21. | | Direction | Directory on the FTP server. | | Timeout | Timeout for connecting to FTP server. | | Username | Username for connecting to the FTP server, optional. | | Password | Password for connecting to the FTP server, optional. | | Collection interval | Interval time of monitor periodic data collection, unit: second, and the minimum interval that can be set is 30 seconds. | | Bind Tags | Used to classify and manage monitoring resources. | | Description remarks | For more information about identifying and describing this monitoring, users can note information here. | | Metric name | Metric unit | Metric help description | ||-|-| | Is Active | none | Check if the directory exists and has access permission. | | Response Time | ms | Response Time |
Project: SkyWalking (Observability and Analysis / Observability)
File: v8-version-upgrade.md

Starting from SkyWalking v8, the has been used. This makes it incompatible with previous releases. Users who intend to upgrade in v8 series releases could follow the steps below. Registers in v6 and v7 have been removed in v8 for better scaling out performance. Please upgrade following the instructions below. Use a different storage or a new namespace. You may also consider erasing the whole storage indexes or tables related to SkyWalking. Deploy the whole SkyWalking cluster, and expose it in a new network address. If you are using language agents, upgrade the new agents too; meanwhile, make sure the agents are supported in a different language. Then, set up the backend address to the new SkyWalking OAP cluster.
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_registry.SidebarEntryProps.md

title: "Interface: SidebarEntryProps" linkTitle: "SidebarEntryProps" slug: "plugin_registry.SidebarEntryProps" .SidebarEntryProps Represents an entry in the sidebar menu. `Optional` icon: `string` \| `IconifyIcon` An iconify string or icon object that will be used for the sidebar's icon `see` https://icon-sets.iconify.design/mdi/ for icons. _ label: `string` Label to display. _ name: `string` Name of this SidebarItem. _ `Optional` parent: ``null`` \| `string` Name of the parent SidebarEntry. _ `Optional` sidebar: `string` The sidebar to display this item in. If not specified, it will be displayed in the default sidebar. _ `Optional` subtitle: `string` Text to display under the name. _ `Optional` url: `string` URL to go to when this item is followed. _ `Optional` useClusterURL: `boolean` Should URL have the cluster prefix? (default=true)
Project: SkyWalking (Observability and Analysis / Observability)
File: slow-db-statement.md

Slow Database statements are crucial for you to identify bottlenecks of a system which relies on databases. Slow DB statements are based on sampling. Right now, the core samples are the top 50 slowest every 10 minutes. Note that the duration of these statements must be slower than the threshold. Here's the format of the settings (in milliseconds): database-type:thresholdValue,database-type2:thresholdValue2 The default settings are `default:200,mongodb:100`. `Reserved DB type` is default, which is the default threshold for all database types, unless set explicitly. Note: The threshold should not be set too small, like `1ms`. Although it works in theory, OAP performance issues may arise if your system statement access time is usually more than 1ms. The OAP server would run statistic per service and only persistent the top 50 every 10(controlled by `topNReportPeriod: ${SWCORETOPNREPORTPERIOD:10}`) minutes by default.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: ingester_pvcs.md

title: Resize ingester persistent volume operations menuTitle: Resize ingester PVCs description: Learn how to resize ingester persistent volume operations. weight: 50 Tempo ingesters make heavy use of local disks to store write-ahead logs and blocks before being flushed to the backend (GCS, S3, etc.). It is important to monitor the free volume space as full disks can lead to data loss and other errors. The amount of disk space available affects how much volume a Tempo ingester can process and the length of time an outage to the backend can be tolerated. Therefore it may be necessary to increase the disk space for ingesters as usage increases. We recommend using SSDs for local storage. When deployed as a StatefulSet with Persistent Volume Claims (PVC), some manual steps are required. The following configuration has worked successfully on GKE with GCS: Edit the persistent volume claim (pvc) for each ingester to the new size. ```bash kubectl patch pvc -n <namespace> -p '{"spec": {"resources": {"requests": {"storage": "'15Gi'"}}}}' <pod-name> ``` Check all disks have been upgraded by running: `kubectl get pvc -n <namespace>` A restart is not necessary as the pods will automatically detect the increased disk space. Delete the StatefulSet but leave the pods running: `kubectl delete sts --cascade=false -n <namespace> ingester` Edit and recreate the Statefulset with the new size. This covers new pods. There are many ways to deploy Tempo to Kubernetes, these are examples for the popular ones: Raw YAML: `kubectl apply -f <something>.yaml` Helm: `helm upgrade ... tempo ...` Tanka: `tk apply ...`
Project: Grafana (Observability and Analysis / Observability)
File: feature-toggles.md

This guide helps you get started adding your feature behind a feature flag in Grafana. Define the feature toggle in . To see what each feature stage means, look at the comments . If you are a community member, use the file to determine which team owns the package you are updating. Run the go tests mentioned at the top of . This will generate all the additional files needed: `toggles_gen` for the backend, `grafana-data` for the frontend, and docs. You can run the test by running `make gen-feature-toggles`. Once your feature toggle is defined, you can then wrap your feature around a check if the feature flag is enabled on that Grafana instance. Here are examples of how to do that: : Use the `IsEnabled` function and pass in your feature toggle. : Check the config for your feature toggle.
Project: HertzBeat (Observability and Analysis / Observability)
File: fullsite.md

id: fullsite title: Monitoring Full site sidebar_label: Full site Monitor keywords: [open source monitoring tool, open source website monitoring tool, monitoring sitemap metrics] Available or not to monitor all pages of the website. A website often has multiple pages provided by different services. We monitor the full site by collecting the SiteMap exposed by the website. Note This monitoring requires your website to support SiteMap. We support SiteMap in XML and TXT formats. | Parameter name | Parameter help description | | -- | -- | | Monitoring Host | Monitored IPV4, IPV6 or domain name. NoteWithout protocol header (eg: https://, http://) | | Monitoring name | Identify the name of this monitoring. The name needs to be unique | | Port | Ports provided by website, http generally defaults to 80 and https generally defaults to 443 | | SiteMap | Relative path of website SiteMap address, eg/sitemap.xml | | Enable HTTPS | Whether to access the website through HTTPS. NoteWhen HTTPS is enabled, the default corresponding port needs to be changed to 443 | | Collection interval | Interval time of monitor periodic data collection, unit: second, and the minimum interval that can be set is 30 seconds | | Whether to detect | Whether to detect and check the availability of monitoring before adding monitoring. Adding and modifying operations will continue only after the detection is successful | | Description remarks | For more information about identifying and describing this monitoring, users can note information here | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | url | none | URL path of web page | | statusCode | none | Response HTTP status code for requesting the website | | responseTime | ms | Website response time | | errorMsg | none | Error message feedback after requesting the website |
Project: Headlamp (Observability and Analysis / Observability)
File: win-installation.md

title: Windows Installation linktitle: Windows weight: 20 Headlamp is available for Windows as a direct download from its on Github (.exe file) and from package registries like and . To install Headlamp from the Winget registry. Simply run the following command: ```powershell winget install headlamp ``` To upgrade Headlamp when its installed with Winget, run the command: ```powershell winget upgrade headlamp ``` To install Headlamp from the Chocolatey registry, first install the choco command by following its . After `choco` is available, by running the following command: ```powershell choco install headlamp ``` To upgrade Headlamp when its installed with Chocolatey, run the command: ```powershell choco upgrade headlamp ``` To install Headlamp from its official installer, first download the .exe file for the 's assets section (located at the bottom of the section). Then double click the file and follow the installer's instructions. Until we have an automatic update, to upgrade Headlamp when it's installed directly from its installer, you have to download the new version of the installer and re-install it.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_serviceAccount.KubeServiceAccount.md

title: "Interface: KubeServiceAccount" linkTitle: "KubeServiceAccount" slug: "libk8sserviceAccount.KubeServiceAccount" .KubeServiceAccount `KubeServiceAccount` `Optional` apiVersion: `string` . _ kind: `string` Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. In CamelCase. Cannot be updated. `see` . _ metadata: . _ secrets: { `apiVersion`: `string` ; `fieldPath`: `string` ; `kind`: `string` ; `name`: `string` ; `namespace`: `string` ; `uid`: `string` }[]
Project: SkyWalking (Observability and Analysis / Observability)
File: ui-setup.md

SkyWalking UI distribution is already included in our Apache official release. Startup script is also in `/bin/webappService.sh`(.bat). UI runs as a Java process, powered-by Armeria. The settings file of UI is `webapp/webapp.yml` in the distribution package. It has three parts. Listening port. Backend connect info. ```yaml serverPort: ${SWSERVERPORT:-8080} oapServices: ${SWOAPADDRESS:-http://localhost:12800} zipkinServices: ${SWZIPKINADDRESS:http://localhost:9412} ``` Start a container to connect OAP server whose address is `http://oap:12800`. ```shell export version=9.0.0 docker run --name oap --restart always -d -e SWOAPADDRESS=http://oap:12800 -e SWZIPKINADDRESS=http://oap:9412 apache/skywalking-ui:$version ``` We could set up environment variables to configure this image. The address of your OAP server. The default value is `http://127.0.0.1:12800`. The address of your Zipkin server. The default value is `http://127.0.0.1:9412`.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-7-5-4.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 7.5.4 <!-- Auto generated by update changelog github action --> Auditing: Use nanosecond resolution for audit log timestamps. (Enterprise) AzureMonitor: Add support for Microsoft.AppConfiguration/configurationStores namespace. , TablePanel: Make sorting case-insensitive. , AzureMonitor: Add support for Virtual WAN namespaces. , Bugfix: Add proper padding when scrolling is added to bar gauge. , Datasource: Prevent default data source named "default" from causing infinite loop. , Prometheus: Allow exemplars endpoint in data source proxy. , Table: Fix table data links so they refer to correct row after sorting. ,
Project: Netdata (Observability and Analysis / Observability)
File: memcached_out_of_cache_space_time.md

This alert indicates that the Memcached cache is running out of space and will likely become full soon, based on the data addition rate over the past hour. If the cache reaches 100% capacity, evictions may occur, resulting in a loss of cached data and decreased performance. Monitor cache usage: Use the `stats` command in Memcached to check the current cache usage and the number of evictions. This will help you understand the severity of the issue and whether evictions are already happening. Evaluate cache settings: Review your Memcached configuration file (`/etc/memcached.conf` or `/etc/sysconfig/memcached`) and check the cache size setting (`-m` parameter). Ensure that the cache size is set appropriately based on your system's available memory and workload requirements. Increase cache size: If the cache is consistently running out of space, consider increasing the cache size by adjusting the `-m` parameter in the Memcached configuration file. Be cautious not to allocate too much memory, as this can cause other system processes to suffer. Optimize cache usage: Analyze the cache usage patterns of your applications and optimize their caching strategies. This may involve adjusting the cache TTL (time-to-live) settings, using different cache eviction policies, or implementing a more efficient caching mechanism. Monitor application performance: Check the performance of your applications that use Memcached to identify any issues or bottlenecks. If performance is degrading due to cache evictions, consider optimizing the applications or increasing cache capacity.