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

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/go/collectors/go.d.plugin/modules/logind/README.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/go/collectors/go.d.plugin/modules/logind/metadata.yaml" sidebar_label: "systemd-logind users" learn_status: "Published" learnrelpath: "Collecting Metrics/Systemd" 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/users.svg" width="150"/> Plugin: go.d.plugin Module: logind <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> This collector monitors number of sessions and users as reported by the `org.freedesktop.login1` DBus API. 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. These metrics refer to the entire monitored application. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | logind.sessions | remote, local | sessions | | logind.sessions_type | console, graphical, other | sessions | | logind.sessions_state | online, closing, active | sessions | | logind.users_state | offline, closing, online, lingering, active | users | There are no alerts configured by default for this integration. No action required. The configuration file name for this integration is `go.d/logind.conf`. You can edit the configuration file using the `edit-config` script from the Netdata . ```bash cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata sudo ./edit-config go.d/logind.conf ``` The following options can be defined globally: updateevery, autodetectionretry. There are no configuration examples. To troubleshoot issues with the `logind` collector, run the `go.d.plugin` with the debug option enabled. The output should give you clues as to why the collector isn't working. Navigate to the `plugins.d` directory, usually at `/usr/libexec/netdata/plugins.d/`. If that's not the case on your system, open `netdata.conf` and look for the `plugins` setting under `[directories]`. ```bash cd /usr/libexec/netdata/plugins.d/ ``` Switch to the `netdata` user. ```bash sudo -u netdata -s ``` Run the `go.d.plugin` to debug the collector: ```bash ./go.d.plugin -d -m logind ```
Project: Grafana (Observability and Analysis / Observability)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thank you for sending a pull request! Here are some tips: If this is your first time, please read our contribution guide at https://github.com/grafana/grafana/blob/main/CONTRIBUTING.md Ensure you include and run the appropriate tests as part of your Pull Request. In a new feature or configuration option, an update to the documentation is necessary. Everything related to the documentation is under the docs folder in the root of the repository. If the Pull Request is a work in progress, make use of GitHub's "Draft PR" feature and mark it as such. If you can not merge your Pull Request due to a merge conflict, Rebase it. This gets it in sync with the main branch. Name your PR as "<FeatureArea>: Describe your change", e.g. Alerting: Prevent race condition. If it's a fix or feature relevant for the changelog describe the user impact in the title. The PR title is used to auto-generate the changelog for issues marked with the "add to changelog" label. If your PR content should be added to the What's New document for the next major or minor release, add the add to what's new label to your PR. Note that you should add this label to the main PR that introduces the feature; do not add this label to smaller PRs for the feature. --> What is this feature? [Add a brief description of what the feature or update does.] Why do we need this feature? [Add a description of the problem the feature is trying to solve.] Who is this feature for? [Add information on what kind of user the feature is for.] Which issue(s) does this PR fix?: <!-- Automatically closes linked issue when the Pull Request is merged. Usage: "Fixes #<issue number>", or "Fixes (paste link of issue)" --> Fixes # Special notes for your reviewer: Please check that: [ ] It works as expected from a user's perspective. [ ] If this is a pre-GA feature, it is behind a feature toggle. , it's added to our doc.
Project: Netdata (Observability and Analysis / Observability)
File: portcheck_service_reachable.md

This alert checks if a particular TCP service on a specified host and port is reachable. If the average percentage of successful checks within the last minute is below 75%, it triggers an alert indicating the TCP service is not functioning properly. Verify if the problem is network-related or service-related Check if the host and port are correct and the service is configured to listen on that specific port. Use `ping` or `traceroute` to diagnose the connectivity issues between your machine and the host. Use `telnet` or `nc` to check if the specific port on the host is reachable. For example, `telnet example.com portnumber` or `nc example.com portnumber`. Check the network configuration, firewall settings, and routing rules on both the local machine and the target host. Check if the TCP service is running and functioning properly Check the service logs for any errors or issues that may prevent it from working correctly. Restart the service and monitor its behavior. Investigate if there are any recent changes in the service configuration or updates that may cause the issue. Monitor system resources such as CPU, memory, and disk usage to ensure they are not causing any performance bottlenecks. Optimize the service configuration Review the service's performance-related configurations and fine-tune them, if necessary. Check if there are any optimizations or best practices that can be applied to boost the service performance and reliability.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_ingress.KubeIngress.md

title: "Interface: KubeIngress" linkTitle: "KubeIngress" slug: "libk8singress.KubeIngress" .KubeIngress `KubeIngress` `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 | | : | : | | `defaultBackend?` | { `resource?`: { `apiVersion`: `string` ; `kind`: `string` ; `name`: `string` } ; `service?`: { `name`: `string` ; `port`: { `name?`: `string` ; `number?`: `number` } } } | | `defaultBackend.resource?` | { `apiVersion`: `string` ; `kind`: `string` ; `name`: `string` } | | `defaultBackend.resource.apiVersion` | `string` | | `defaultBackend.resource.kind` | `string` | | `defaultBackend.resource.name` | `string` | | `defaultBackend.service?` | { `name`: `string` ; `port`: { `name?`: `string` ; `number?`: `number` } } | | `defaultBackend.service.name` | `string` | | `defaultBackend.service.port` | { `name?`: `string` ; `number?`: `number` } | | `defaultBackend.service.port.name?` | `string` | | `defaultBackend.service.port.number?` | `number` | | `ingressClassName?` | `string` | | `rules` | [] \| `LegacyIngressRule`[] | | `tls?` | { `hosts`: `string`[] ; `secretName`: `string` }[] |
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: elasticsearch.md

title: Elasticsearch weight: 200 generated_file: true Based on the . {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: SyslogNGOutput metadata: name: elasticsearch spec: elasticsearch: url: "https://elastic-search-endpoint:9200/_bulk" index: "indexname" type: "" user: "username" password: valueFrom: secretKeyRef: name: elastic key: password {{</ highlight >}} The document ID. If no ID is specified, a document ID is automatically generated. This option enables putting outgoing messages into the disk buffer of the destination to avoid message loss in case of a system failure on the destination side. For details, see the . Default: false Name of the data stream, index, or index alias to perform the action on. Set the suffix for logs in logstash format. Default: `"${YEAR}.${MONTH}.${DAY}"` Set the prefix for logs in logstash format. If set, then the Index field will be ignored. Set the separator between LogstashPrefix and LogStashDateformat. Default: "-" The template to format the record itself inside the payload body The document type associated with the operation. Elasticsearch indices now support a single document type: `_doc`
Project: Netdata (Observability and Analysis / Observability)
File: ceph_cluster_space_usage.md

The `cephclusterspace_usage` alert is triggered when the percentage of used disk space in your Ceph cluster reaches a high level. Ceph is a distributed storage system designed to provide excellent performance, reliability, and scalability. If the usage surpasses certain thresholds (warning: 85-90%, critical: 90-98%), this indicates high disk space utilization, which may affect the performance and reliability of your Ceph cluster. Perform the following actions: Check the Ceph cluster status Run the following command to see the overall health of the Ceph cluster: ``` ceph status ``` Pay attention to the `HEALTH` status and the `cluster` section, which provides information about the used and total disk space. Review the storage utilization for each pool Run the following command to review the storage usage for each pool in the Ceph cluster: ``` ceph df ``` Identify the pools with high utilization and consider moving or removing data from these pools. Investigate high storage usage clients or applications Check the clients or applications that interact with the Ceph cluster and the associated file systems. You can use monitoring tools, disk usage analysis programs, or log analysis tools to identify any unusual patterns, such as excessive file creation, large file uploads, or high I/O operations. Add more storage or nodes to the cluster If the cluster is reaching its full capacity due to normal usage, consider adding more storage or nodes to the Ceph cluster. This can help prevent the cluster from becoming overloaded and maintain its performance and reliability. You can use the following commands to add more storage or nodes to the Ceph cluster: ``` ceph osd create ceph osd add ``` Optimize data replication and placement The high disk usage might be a result of non-optimal data replication and distribution across the cluster. Review the Ceph replication and placement settings, and update the CRUSH map if needed to ensure better distribution of data.
Project: LinDB (Observability and Analysis / Observability)
File: README.md

Each patch release only includes changes against previous patch release. For example, the change log of v3.5.5 should only include items which are new to v3.5.4. For the first release (e.g. 3.4.0, 3.5.0, 3.6.0, 4.0.0 etc.) for each minor or major version, it only includes changes which are new to the first release of previous minor or major version. For example, v3.5.0 should only include items which are new to v3.4.0, and v3.6.0 should only include items which are new to v3.5.0.
Project: Grafana Loki (Observability and Analysis / Observability)
File: merge-release-pr.md

title: Merge Release PR description: Describes the process to release Loki by merging the release PR. To release Loki, merge the release PR. This PR will have the title `chore(<BRANCH>): release <VERSION>`. Here's what the 3.0 release PR looked like. 3.0 was the first major release using this new process, and enforcing conventional commits was relatively new. Going forward the release notes in the release PR will be much more thorough, as we're now enforcing that every PR has a conventional commit message. To test the artifacts before releasing, you can download the artifacts from the link in the footer of the PR description. Merging the PR will: Fetch the built artifacts. Create a draft GitHub release with the release notes in the PR description. Upload fetched binareis to the draft release. Publish fetched images to Docker Hub as multi-arch images. Publish the draft release and create the GitHub tag. (Optionally) Mark the release as the latest if it represents the newest version of Loki. If something goes wrong with the release automation, you may need to rerun the job. This may require updating the release code in the `grafana/loki` repo via a PR, or it may include updating the code in `grafana/loki-release` that the release pipeline fetches. In either case, if you need to re-release a merge release PR, you'll need to remove the `autorelease: tagged` label from that PR and add the `autorelease: pending` label. The automation relies on these labels to determine which merged PRs have and have not yet been released. After fixing the labels, re-run the release workflow, and it should correctly get passed the `should-release` step. The release process is idempotent, so if a draft release has already been created via a previously failed release, the process will continue, re-upload the binaries, and re-publish the images. Once the release is finished, you may need to manually flip the label back to `autorelease: tagged`.
Project: HertzBeat (Observability and Analysis / Observability)
File: victoria-metrics-init.md

id: victoria-metrics-init title: Use Time Series Database VictoriaMetrics to Store Metrics Data (Recommended) sidebar_label: Use VictoriaMetrics Store Metrics HertzBeat's historical data storage relies on the time series database, you can choose one of them to install and initialize, or not to install (note but it is strongly recommended to configure in the production environment) We recommend VictoriaMetrics for long term support. VictoriaMetrics is a fast, cost-effective and scalable monitoring solution and time series database.Recommend Version(VictoriaMetrics:v1.95.1+, HertzBeat:v1.4.3+) Note Time series database is optional, but production environment configuration is strongly recommended to provide more complete historical chart functions and high performance If you do not configure a time series database, only the last hour of historical data is retained. If you already have an VictoriaMetrics environment, you can skip directly to the YML configuration step. Refer to the official website Download and install Docker environment Docker tools download refer to . After the installation you can check if the Docker version normally output at the terminal. ``` $ docker -v Docker version 20.10.12, build e91ed57 ``` Install VictoriaMetrics via Docker ```shell $ docker run -d -p 8428:8428 \ -v $(pwd)/victoria-metrics-data:/victoria-metrics-data \ --name victoria-metrics \ victoriametrics/victoria-metrics:v1.95.1 ``` `-v $(pwd)/victoria-metrics-data:/victoria-metrics-data` is local persistent mount of VictoriaMetrics data directory use```$ docker ps``` to check if the database started successfully Configure the database connection in hertzbeat `application.yml`configuration file Modify `hertzbeat/config/application.yml` configuration file NoteThe docker container way need to mount application.yml file locally, while you can use installation package way to unzip and modify `hertzbeat/config/application.yml` Config the `warehouse.store.jpa.enabled` `false`. Replace `warehouse.store.victoria-metrics` data source parameters, HOST account and password. ```yaml warehouse: store: jpa: enabled: false victoria-metrics: enabled: true url: http://localhost:8428 username: root password: root ``` Restart HertzBeat Do both the time series databases need to be configured? Can they both be used? You don't need to configure all of them, you can choose one of them. Use the enable parameter to control whether it is used or not. You can also install and configure neither, which can affects the historical chart data.
Project: Checkmk (Observability and Analysis / Observability)
File: 16609.md

key | value | compatible | no version | 2.4.0b1 date | 2024-03-14T09:54:25+00:00 level | 1 class | fix component | multisite edition | cre Werk 13498 introduced the possibility to set limit publish permissions to certain contact groups, sites etc. Still, the permission "Publish views" (e.g. for publishing views) was needed to see the published views. With Werk 16320 this has been fixed for dashboards, views and reports. This werk fixes the behavior for the remaining components (Bookmarks, Graphs, SLAs and Reports). Note: Please check the respective publish configuration.
Project: Spring Cloud Sleuth (Observability and Analysis / Observability)
File: CONTRIBUTING.md

Spring Cloud is released under the non-restrictive Apache 2.0 license, and follows a very standard Github development process, using Github tracker for issues and merging pull requests into master. If you want to contribute even something trivial please do not hesitate, but follow the guidelines below. Before we accept a non-trivial patch or pull request we will need you to sign the . Signing the contributor's agreement does not grant anyone commit rights to the main repository, but it does mean that we can accept your contributions, and you will get an author credit if we do. Active contributors might be asked to join the core team, and given the ability to merge pull requests. This project adheres to the Contributor Covenant [code of conduct](https://github.com/spring-cloud/spring-cloud-build/blob/main/docs/src/main/asciidoc/code-of-conduct.adoc). By participating, you are expected to uphold this code. Please report unacceptable behavior to spring-code-of-conduct@pivotal.io. None of these is essential for a pull request, but they will all help. They can also be added after the original pull request but before a merge. Use the Spring Framework code format conventions. If you use Eclipse you can import formatter settings using the `eclipse-code-formatter.xml` file from the project. If using IntelliJ, you can use the to import the same file. Make sure all new `.java` files to have a simple Javadoc class comment with at least an `@author` tag identifying you, and preferably at least a paragraph on what the class is for. Add the ASF license header comment to all new `.java` files (copy from existing files in the project) Add yourself as an `@author` to the .java files that you modify substantially (more than cosmetic changes). Add some Javadocs and, if you change the namespace, some XSD doc elements. A few unit tests would help a lot as well -- someone has to do it. If no-one else is using your branch, please rebase it against the current master (or other target branch in the main project). When writing a commit message please follow , if you are fixing an existing issue please add `Fixes gh-XXXX` at the end of the commit message (where XXXX is the issue number).
Project: Botkube (Observability and Analysis / Observability)
File: feature_request.md

name: Feature request about: Suggest how we can improve labels: enhancement <!-- Thank you for your contribution. Before you submit the issue: Search open and closed issues for duplicates. Read the contributing guidelines (CONTRIBUTING.md file on root of the repository). --> <!-- Provide a clear and concise overview of the feature. --> <!-- Provide a list of conditions that must be satisfied to close this issue. --> [ ] Make sure documentation is up-to-date, create one if needed [ ] Add test coverage for happy-path (unit or e2e test) [ ] Record raw demo video for the user-facing changes <!-- Explain why we should add this feature. -->
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: Roadmap.md

sort: 8 weight: 8 title: VictoriaLogs roadmap disableToc: true menu: docs: parent: "victorialogs" weight: 8 title: Roadmap aliases: /VictoriaLogs/Roadmap.html The Preview is ready for evaluation in production. It is recommended running it alongside the existing solutions such as Elasticsearch and Grafana Loki and comparing their resource usage and usability. It isn't recommended migrating from existing solutions to VictoriaLogs Preview yet. The following functionality is available in VictoriaLogs Preview: . . . See for details. The following functionality is planned in the future versions of VictoriaLogs: Support for from popular log collectors and formats: OpenTelemetry for logs Fluentd Syslog Journald (systemd) Add missing functionality to : . . . The ability to use subqueries inside function. Live tailing for aka `tail -f`. Web UI with the following abilities: Explore the ingested logs (). Build graphs over time for the ingested logs. Integration with Grafana. Ability to make instant snapshots and backups in the way . Cluster version of VictoriaLogs. Ability to store data to object storage (such as S3, GCS, Minio). Alerting on LogsQL queries.
Project: Checkmk (Observability and Analysis / Observability)
File: 16489.md

key | value | date | 2024-02-05T07:51:38+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes This werk adds two missing counters to the mentioned plugin, the counters `svmnfsv3:readops` and `svmnfsv3:writeops`.