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

<!-- title: "Redistributed software" customediturl: https://github.com/netdata/netdata/edit/master/REDISTRIBUTED.md sidebar_label: "Redistributed Software" learn_status: "Published" learntopictype: "Concepts" learnrelpath: "Developers" --> Netdata copyright info:<br/> Copyright 2023, Netdata Inc.<br/> Released under . Netdata uses SPDX license tags to identify the license for its files. Individual licenses referenced in the tags are available on the . Netdata redistributes the Netdata Cloud UI, licensed under . Netdata Cloud UI includes . Netdata redistributes the following third-party software. We have decided to redistribute all these, instead of using them through a CDN, to allow Netdata to work in cases where Internet connectivity is not available. Copyright 2009, Dan Vanderkam Copyright 2013, Robert Fleischmann Copyright, Bernard Kobos Copyright (c) 2014-2015 Benjamin Keen Copyright 2009-2012, Splunk Inc. Copyright 2009-2015, Ben Pickles Copyright 2013, Olly Smith Copyright 2008, Dmitry Baranovskiy Copyright 2013, Masayuki Tanaka Copyright 2015, Mike Bostock Copyright 2015, jQuery Foundation Copyright 2015, Twitter Copyright (c) 2011-2014 Min Hur, The New York Times Company Copyright 2017 Kyle Kemp, Rohit Kalkur, and contributors Copyright (c) 2012-2016 Zhixin Wen Copyright (c) 2015,2016 hhurz Copyright 2016, Hyunje Alex Jun and other contributors Created by Dave Gandy Font license: Icon license Code license: Copyright 2014, Stefan Thomas Copyright 2013, Stephen Vickers Copyright 2017, Stephen Vickers Copyright 2011, Mark Cavage Copyright 2015, Joseph Huckaby Copyright 2014, Pavel Rojtberg Copyright 2006, Kirill Simonov Copyright 2008-2016 Andrey Petrov and Copyright 2013 Pieroxy Copyright 2014-2017 Vitaly Puzrin and Andrei Tuputcyn Copyright (c) 2014 Lucas Garron Copyright (c) 2010-2015 Benjamin Peterson Copyright (C) 2015 Barnaby Gale Copyright 2014, 2015, 2016 Ori Livneh Copyright 2015, Benedikt Schmitt Copyright March 2010 by Universit de Montral, Richard Simard and Pierre L'Ecuyer Copyright (c) 2012-2021 Yann Collet
Project: Netdata (Observability and Analysis / Observability)
File: btrfs_device_generation_errors.md

This alert is about `BTRFS generation errors`. When you receive this alert, it means that your BTRFS file system has encountered errors during its operation. BTRFS is a modern copy-on-write (CoW) filesystem, which is developed to address various weaknesses in traditional Linux file systems. It features snapshotting, checksumming, and performs background scrubbing to find and repair errors. A `BTRFS generation error` occurs when the file system encounters issues while updating the data and metadata associated with a snapshot or subvolume. This could be due to software bugs, hardware issues, or data corruption. Verify the issue: Check your system logs for any BTRFS-related errors to further understand the problem. This can be done using the `dmesg` command: ``` sudo dmesg | grep BTRFS ``` Check the BTRFS filesystem status: Use the `btrfs filesystem` command to get information about your BTRFS filesystem, including the UUID, total size, used size, and device information: ``` sudo btrfs filesystem show ``` Perform a BTRFS scrub: Scrubbing is a process that scans the entire filesystem, verifies the data and metadata, and attempts to repair any detected errors. Run the following command to start a scrub operation: ``` sudo btrfs scrub start -Bd /path/to/btrfs/mountpoint ``` The `-B` flag will run the scrub in the background, and the `-d` flag will provide detailed information about the operation. Monitor scrub progress: You can monitor the scrub progress using the `btrfs scrub status` command: ``` sudo btrfs scrub status /path/to/btrfs/mountpoint ``` Analyze scrub results: The scrub operation will provide information about the total data scrubbed, the number of errors found, and the number of errors fixed. This information can help you determine the extent of the issue and any further action required. Address BTRFS issues: Depending on the nature of the errors, you may need to take further action, such as updating the BTRFS tools, updating your Linux kernel, or even replacing faulty hardware to resolve the errors. Set up a regular scrub schedule: You can schedule regular scrubs to keep your BTRFS filesystem healthy. This can be done using `cron`. For example, you can add the following line to `/etc/crontab` to run a scrub on the 1st of each month: ``` 0 0 1 root btrfs scrub start -B /path/to/btrfs/mountpoint ```
Project: OpenTelemetry (Observability and Analysis / Observability)
File: social-media-guide.md

This document is a loose set of policies and guidelines for social media usage by the OpenTelemetry project. It is not intended to be an exhaustive list of what and how we should post or market the project, but more a set of principles and values that we should follow in order to maintain consistency and professionalism. OpenTelemetry's use of social media (Twitter, LinkedIn, YouTube, Mastodon, etc.) is intended to help us achieve the following goals: Increase awareness of the project. Highlight the work of contributors and maintainers. Help educate and inform users and potential users of the project. OpenTelemetry is a community-driven project, and as such, our social media usage should reflect our community standards. Please familiarize yourself with our as well as our [code of conduct](./code-of-conduct.md) as the primary reference for how we should represent ourselves and conduct ourselves on social media. When creating social content, keep the following general guidelines in mind: Be professional and courteous. Avoid hyperbole and exaggeration, or "extremely online" references and behavior. Do not use OpenTelemetry social accounts to promote a specific proprietary product, company, or service. It's OK to refer to a specific product or service in the context of a technical discussion, but avoid promoting a specific product or service over others. It's also OK to recognize and name individuals employers in the context of their contributions to the project. Generally, avoid naming specific companies or products in a way that could be construed as an endorsement or an opposition. Never use OpenTelemetry accounts to denigrate, demean, or otherwise make negative statements or claims about specific people, companies, products, services, or other projects. Focus on our overall goals when creating social content. This doesn't mean we can't be fun, or have fun, but we should try to keep social content highly relevant. Highlight and celebrate our contributors, releases, achievements, and other 'sister' projects or initiatives in the CNCF/Open Observability world. Strive to reflect our DEI values in our social content. An example of content we should strive to regularly post: New blog posts, videos, or other content from the project. New major releases, especially if accompanied by a blog. Ecosystem developments (new exporters, new instrumentation, new tools, etc.) New SIGs, WGs, events, or other groups. Surveys, polls, or other community engagement activities. The following is a list of official OpenTelemetry social media accounts: Twitter: Mastodon: LinkedIn: YouTube: If you have questions or feedback about these guidelines, please reach out to Austin Parker on the CNCF Slack or email the .
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-4-3.md

hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 8.4.3 <!-- Auto generated by update changelog github action --> Alerting: Grafana uses > instead of >= when checking the For duration. Alerting: Use expanded labels in dashboard annotations. , Logs: Escape windows newline into single newline. , Alerting: Fix use of > instead of >= when checking the For duration. , Azure Monitor: Fixes broken log queries that use workspace. , CloudWatch: Remove error message when using multi-valued template vars in region field. , Middleware: Fix IPv6 host parsing in CSRF check. , ClipboardButton: Use a fallback when the Clipboard API is unavailable. ,
Project: Weave Scope (Observability and Analysis / Observability)
File: md_docs.md

This program can actually generate docs for the kubectl command in the kubernetes project ```go package main import ( "io/ioutil" "os" "github.com/GoogleCloudPlatform/kubernetes/pkg/kubectl/cmd" "github.com/spf13/cobra" ) func main() { kubectl := cmd.NewFactory(nil).NewKubectlCommand(os.Stdin, ioutil.Discard, ioutil.Discard) cobra.GenMarkdownTree(kubectl, "./") } ``` This will generate a whole series of files, one for each command in the tree, in the directory specified (in this case "./") You may wish to have more control over the output, or only generate for a single command, instead of the entire command tree. If this is the case you may prefer to `GenMarkdown` instead of `GenMarkdownTree` ```go out := new(bytes.Buffer) cobra.GenMarkdown(cmd, out) ``` This will write the markdown doc for ONLY "cmd" into the out, buffer. Both `GenMarkdown` and `GenMarkdownTree` have alternate versions with callbacks to get some control of the output: ```go func GenMarkdownTreeCustom(cmd *Command, dir string, filePrepender func(string) string, linkHandler func(string) string) { //... } ``` ```go func GenMarkdownCustom(cmd Command, out bytes.Buffer, linkHandler func(string) string) { //... } ``` The `filePrepender` will prepend the return value given the full filepath to the rendered Markdown file. A common use case is to add front matter to use the generated documentation with : ```go const fmTemplate = ` date: %s title: "%s" slug: %s url: %s ` filePrepender := func(filename string) string { now := time.Now().Format(time.RFC3339) name := filepath.Base(filename) base := strings.TrimSuffix(name, path.Ext(name)) url := "/commands/" + strings.ToLower(base) + "/" return fmt.Sprintf(fmTemplate, now, strings.Replace(base, "_", " ", -1), base, url) } ``` The `linkHandler` can be used to customize the rendered internal links to the commands, given a filename: ```go linkHandler := func(name string) string { base := strings.TrimSuffix(name, path.Ext(name)) return "/commands/" + strings.ToLower(base) + "/" } ```
Project: OpenTelemetry (Observability and Analysis / Observability)
File: one-logging-bridge-per-language.md

During the joint TC/GC call on Jan 11 2024, we agreed on a few items we'd like to accomplish this year. One such item was creating at least one logging bridge per Language SIG, so that our end-users can start using OTLP Logging natively in their applications. We'll strive to get at least one logging bridge for each supported language. Language SIGs will be free to decide which bridge to implement based on the needs of their audiences. To be created. For each one of the following languages, there should be at least one logging bridge available, either as part of their core repository or as part of their contrib repository. Usage of such bridge should be documented on opentelemetry.io's website. Languages (100% of the languages available when this issue was created): One Logging Bridge per language - C++ One Logging Bridge per language - .NET One Logging Bridge per language - Erlang One Logging Bridge per language - Go One Logging Bridge per language - Java One Logging Bridge per language - JavaScript One Logging Bridge per language - PHP One Logging Bridge per language - Python One Logging Bridge per language - Ruby One Logging Bridge per language - Rust One Logging Bridge per language - Swift We anticipate that Language SIG maintainers will share the vision that having at least one bridge, hopefully for the most used logging API for the language, is important for the SIG, and therefore, we don't anticipate new staffing requirements. However, we'll try to recruit new contributors to work on this once we have a few examples to follow. @jpkrohling is the sponsor for this project and will work with the individual Language SIGs to implement this. We'll use the regular Language SIGs meetings, as well as the maintainer's meeting on Monday. We aim to complete this project by the end of 2024.
Project: Grafana Loki (Observability and Analysis / Observability)
File: LICENSING.md

License names used in this document are as per . The default license for this project is . The following folders and their subfolders are licensed under Apache-2.0: ``` clients/ pkg/framedstdcopy/ pkg/ingester/wal pkg/logproto/ pkg/loghttp/ pkg/logqlmodel/ pkg/push pkg/util production/ tools/ ``` The following directories and their subdirectories are licensed under their original upstream licenses: ``` vendor/ ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16736.md

key | value | date | 2024-04-23T07:42:11+00:00 version | 2.4.0b1 class | fix edition | cme component | wato level | 1 compatible | yes Some rulesets like 'Assignment of hosts (or services) to contact groups' use contact groups which may not be synced because they are assigned to a specific customer or to 'Provider' (default). This inconsistency might have already been present in your configuration but went unnoticed in the previous versions. With 2.3, we introduced new validation mechanics which now warn you about this potential issue. With this change we make the shown error message a more helpful so that users get a hint how to solve the situation.
Project: HertzBeat (Observability and Analysis / Observability)
File: document.md

id: 'document' title: 'Documentation Notice' sidebar_position: 1 <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> Good documentation is critical for any type of software. Any contribution that can improve the HertzBeat documentation is welcome. Documentation for the HertzBeat project is maintained in . First you need to fork the document project into your own github repository, and then clone the document to your local computer. ```shell git clone git@github.com:<your-github-user-name>/hertzbeat.git ``` This website is compiled using node, using Docusaurus framework components Download and install nodejs (version 18.8.0) Clone the code to the local `git clone git@github.com:apache/hertzbeat.git` In `home` directory run `npm install` to install the required dependent libraries. In `home` directory run `npm run start`, you can visit http://localhost:3000 to view the English mode preview of the site In `home` directory run `npm run start-zh-cn`, you can visit http://localhost:3000 to view the Chinese mode preview of the site To generate static website resource files, run `npm run build`. The static resources of the build are in the build directory. ```html |-- docs |-- blog |-- i18n | `-- zh-CN // internationalized chinese | |-- code.json | |-- docusaurus-plugin-content-blog | |-- docusaurus-plugin-content-docs | `-- docusaurus-theme-classic |-- resource // static resource file |-- src | |-- theme | |-- css | |-- js | |-- pages | | |-- components | | |-- index.js | |-- constants.js |-- static // picture static resource | |-- img // | | |-- blog // blog picture | | |-- docs // document picture | | |-- home // product picture | | |-- icons // icon |-- docusaurus.config.js |-- sidebars.js // document sidebar menu configuration ``` All lowercase, separated by a dash Positive example: `render-dom.js / signup.css / index.html / company-logo.png` Counter example: `renderDom.js / UserManagement.html` Image resources are unified under `static/img/{module name}` css and other style files are placed in the `src/css` directory All pages doc can be directly jumped to the corresponding github resource modification page through the 'Edit this page' button at the bottom
Project: Vector (Observability and Analysis / Observability)
File: dedupe.md

title: Dedupe events description: Deduplicate logs passing through a topology short: Dedupe component_kind: transform layout: component tags: ["dedupe", "deduplicate", "component", "transform"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: M3 (Observability and Analysis / Observability)
File: pod_identity.md

title: "Pod Identity" menuTitle: "Pod Identity" weight: 11 chapter: true M3DB assumes that if a process is started and owns sealed shards marked as `Available` that its data for those shards is valid and does not have to be fetched from peers. Consequentially this means it will begin serving reads for that data. For more background on M3DB topology, see the . In most environments in which M3DB has been deployed in production, it has been on a set of hosts predetermined by whomever is managing the cluster. This means that an M3DB instance is identified in a toplogy by its hostname, and that when an M3DB process comes up and finds its hostname in the cluster with `Available` shards that it can serve reads for those shards. This does not work on Kubernetes, particularly when working with StatefulSets, as a pod may be rescheduled on a new node or with new storage attached but its name may stay the same. If we were to naively use an instance's hostname (pod name), and it were to get rescheduled on a new node with no data, it could assume that absence of data is valid and begin returning empty results for read requests. To account for this, the M3DB Operator determines an M3DB instance's identity in the topology based on a configurable set of metadata about the pod. The M3DB operator uses a configurable set of metadata about a pod to determine its identity in the M3DB placement. This is encapsulated in the field of a cluster's spec. In addition to the configures sources, a pod's name will always be included. Every pod in an M3DB cluster is annotated with its identity and is passed to the M3DB instance via a downward API volume. This section will be filled out as a number of pending PRs land. If not using PVs, you should set `sources` to `PodUID`: ``` podIdentityConfig: sources: PodUID ``` This way whenever a container is rescheduled, the operator will initiate a replace and it will stream data from its peers before serving reads. Note that not having persistent storage is not a recommended way to run M3DB. If using remote storage you do not need to set sources, as it will default to just the pods name. The data for an M3DB instance will move around with its container. If using persistent local volumes, you should set sources to `NodeName`. In this configuration M3DB will consider a pod to be the same so long as it's on the same node. Replaces will only be triggered if a pod with the same name is moved to a new host. Note that if using local SSDs on GKE, node names may stay the same even though a VM has been recreated. We also support `ProviderID`, which will use the underlying VM's unique ID number in GCE to identity host uniqueness.
Project: Netdata (Observability and Analysis / Observability)
File: retroshare_dht_working.md

The `retrosharedhtworking` alert is related to the Retroshare service, which is a secure communication and file sharing platform. Retroshare uses a Distributed Hash Table (DHT) to manage the network of connected users. If you receive this alert, it means that the number of DHT peers for your Retroshare service is low. This can lead to slow communication and file sharing, impacting the performance of the service. Check the Retroshare service status Make sure that the Retroshare service is running and has an active connection to the internet. You can verify this by checking the service logs or by accessing the Retroshare interface. Inspect the network configuration Verify that your Retroshare service can connect to the required ports for DHT (UDP) to function correctly. Also, ensure the ports are open in any firewall or security software. Increase the number of bootstrap nodes Retroshare requires a list of bootstrap nodes for the initial connection to the DHT network. If the current bootstrap nodes are not sufficient or unresponsive, try adding more bootstrap nodes to the list. Update your Retroshare software Older versions of the Retroshare service may not connect correctly and might have outdated DHT peers list. Ensure your Retroshare service is up-to-date and working with the latest version. Check the Retroshare community If you continue to experience issues with the DHT peer count, visit the Retroshare community forums or support channels to see if other users have encountered similar issues and whether any solutions are suggested.
Project: Checkmk (Observability and Analysis / Observability)
File: 15718.md

key | value | date | 2024-01-16T11:21:43+00:00 version | 2.3.0b1 class | feature edition | cre component | multisite level | 2 compatible | yes The main menu of the UI has now more extended support for keyboard navigation. You can open up the menus with the following key combinations: Monitoring: `ALT + m` Setup: `ALT + s` Customize: `ALT + c` The search field is automatically focussed (as before), you can directly insert your search term. By using `TAB` you can navigate the search results and confirm your choice with `ENTER`. Pressing `ESC` for the first time clears the current search term. A second `ESC` closes the open menu. Utilizing the workflow can make navigating to the desired pages in Checkmk much faster.