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

Here is a list of `khcheck`s you can apply to your kubernetes cluster once you have Kuberhealthy installed. If you have a check you would like to share with the community, please open a PR to this file! | Check Name | Description | khcheck Resource | Contributor | | - | | | -- | | | Ensures daemonsets can be successfully deployed | | @integrii @joshulyne | | | Ensures that a Deployment and Service can be provisioned, created, and serve traffic within the Kubernetes cluster | | @jonnydawg | | | Checks for excessive pod restarts in any namespace | | @integrii @joshulyne | | | Checks for unhealthy pod statuses in a target namespace | | @integrii @rukatm | | | Checks for failures with DNS, including resolving within the cluster and outside of the cluster | | @integrii @joshulyne | | | Verifies that an image can be pulled from an image repository | | @zjhans | | | Checks that a URL endpoint can serve a 200 OK response | | @jonnydawg | | | Checks that KIAM Servers and Agents are able to provide credentials | | @jonnydawg | | | Checks for specific string in body of URL | | @jdowni000 | | | Checks if resource quotas (CPU & memory) are available | | @jonnydawg | | | Checks if a network connection (tcp or udp) could be done to a remote target | | @bavarianbidi | | | Checks if an initialized storage via PVC is available and usable at each discovered/desired Node | | @chrishirsch | | | Checks if containers running within your cluster can properly make AWS service requests | | @mmogylenko | | | Checks if the AMI(s) used by running AWS nodes still exist | | @mtougeron | | | Checks for a specified event reason for cronjobs in a namespace | | @jdowni000 | | | Ensures that an SSL certificate has plenty of validity time left | | @zjhans | | | Ensures that an SSL handshake is working as expected | | @zjhans | | | Checks if the external secrets operator is functional | | @Nick-Triller | | | Checks if a minio storage endpoint is healthy | | @rjacks161 | | | Checks ssh on each node of a cluster | | @rjacks161 |
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: enhance_k8s.md

title: Enhance K8s Metadata weight: 200 generated_file: true Fluentd Filter plugin to fetch several metadata for a Pod Kubernetes resources api groups Default: `["apps/v1", "extensions/v1beta1"]` Bearer token path Default: nil Kubernetes API CA file Default: nil Cache refresh Default: 60*60 Cache refresh variation Default: 60*15 Cache size Default: 1000 Cache TTL Default: 60602 Kubernetes API Client certificate Default: nil // Kubernetes API Client certificate key Default: nil Kubernetes core API version (for different Kubernetes versions) Default: ['v1'] Sumologic data type Default: metrics parameters for read/write record Default: `['$.namespace']` Default: `['$.pod','$.pod_name']` Kubernetes API URL Default: nil If `cafile` is for an intermediate CA, or otherwise we do not have the root CA and want to trust the intermediate CA certs we do have, set this to `true` - this corresponds to the openssl sclient -partialchain flag and X509VFLAGPARTIAL_CHAIN Default: false Service account directory Default: /var/run/secrets/kubernetes.io/serviceaccount Verify SSL Default: true {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: Logging metadata: name: demo-flow spec: globalFilters: enhanceK8s: {} {{</ highlight >}} Fluentd config result: {{< highlight xml >}} <filter > @type enhancek8smetadata @id test_enhanceK8s </filter> {{</ highlight >}}
Project: Grafana Loki (Observability and Analysis / Observability)
File: multi-tenancy.md

title: Multi-tenancy menuTitle: description: Describes how Loki implements multi-tenancy to isolate tenant data and queries. weight: Grafana Loki is a multi-tenant system; requests and data for tenant A are isolated from tenant B. Requests to the Loki API should include an HTTP header (`X-Scope-OrgID`) that identifies the tenant for the request. Tenant IDs can be any alphanumeric string that fits within the Go HTTP header limit (1MB). Operators are recommended to use a reasonable limit for uniquely identifying tenants; 20 bytes is usually enough. Loki defaults to running in multi-tenant mode. Multi-tenant mode is set in the configuration with `auth_enabled: true`. When configured with `auth_enabled: false`, Loki uses a single tenant. The `X-Scope-OrgID` header is not required in Loki API requests. The single tenant ID will be the string `fake`. In multi-tenant mode, queries may gather results from multiple tenants. Set the querier configuration option `multitenantqueries_enabled: true` to enable queries across tenants. The query API request defines the tenants. Specify multiple tenants in the query request HTTP header `X-Scope-OrgID` by separating the tenant IDs with the pipe character (`|`). For example, a query for tenants `A` and `B` requires the header `X-Scope-OrgID: A|B`. Only query endpoints support multi-tenant calls. Calls to `GET /loki/api/v1/tail` and `POST /loki/api/v1/push` will return an HTTP 400 error if more than one tenant is defined in the HTTP header. Instant and range queries support label filtering using tenant IDs. For example, the query ``` {app="foo", tenant_id=~"a.+"} | logfmt ``` will return results for all tenants that have a tenant ID that begins with the character `a`. If the label `tenant_id` is already present in a log stream, it is prepended with the string `original_`. Tenant ID filtering in stages is not supported. An example of a query that will not work: ``` {app="foo"} | tenant_id="1" | logfmt ```
Project: Grafana Mimir (Observability and Analysis / Observability)
File: configure-object-storage-backend.md

aliases: ../../operators-guide/deploy-grafana-mimir/jsonnet/configure-object-storage-backend/ description: Learn how to configure the Grafana Mimir object storage backend when using Jsonnet. menuTitle: Configure object storage title: Configure the Grafana Mimir object storage backend with Jsonnet weight: 20 You can configure the object storage backend for all Mimir components from a single place. The minimum Jsonnet code required for this is: ```jsonnet { _config+:: { storage_backend: 'gcs', blocksstoragebucket_name: 'blocks-bucket', } } ``` The `storage_backend` option must be one of either `azure`, `gcs`, or `s3`. Additional configuration options are available for each one of these providers. Amazon S3 storage can be accessed without credentials when . In this case, `storages3secretaccesskey` and `storages3accesskeyid` are optional and can be left null, as in the following example: ```jsonnet { _config+:: { storage_backend: 's3', blocksstoragebucket_name: 'blocks-bucket', aws_region: 'af-south-1', } } ``` If credentials are required, it is a good practice to keep them in secrets. In that case environment variable interpolation can be used: ```jsonnet { _config+:: { storage_backend: 's3', storages3accesskeyid: '$(BLOCKSSTORAGES3ACCESSKEY_ID)', storages3secretaccesskey: '$(BLOCKSSTORAGES3SECRETACCESS_KEY)', aws_region: 'af-south-1', blocksstoragebucket_name: 'blocks-bucket', } } ``` must be disabled in Azure Blob Storage. Otherwise, Grafana Mimir will leave empty directories behind after deleting blocks. The Azure storage client requires the `storageazureaccountname` and `storageazureaccountkey` to be configured. It is a good practice to keep them in secrets. In that case environment variable interpolation can be used: ```jsonnet { _config+:: { storage_backend: 'azure', storageazureaccountname: '$(STORAGEAZUREACCOUNTNAME)', storageazureaccountkey: '$(STORAGEAZUREACCOUNTKEY)', blocksstoragebucket_name: 'blocks-bucket', } } ``` There are multiple . If you run Mimir on Google Cloud Platform it is possible that , in that case the minimum jsonnet configuration is valid: ```jsonnet { _config+:: { storage_backend: 'gcs', blocksstoragebucket_name: 'blocks-bucket', } } ``` You can use the `storagegcsservice_account` configuration key to provide the service account when authentication is needed. It is a good practice to keep credentials in secrets, so environment variable interpolation can be used: ```jsonnet { _config+:: { storage_backend: 'gcs', storagegcsserviceaccount: '$(STORAGEGCSSERVICEACCOUNT)', blocksstoragebucket_name: 'blocks-bucket', } } ``` Alternatively, you can set the `GOOGLEAPPLICATIONCREDENTIALS` environment variable to point to the service account file mounted from a secret.
Project: Grafana Loki (Observability and Analysis / Observability)
File: .operatorhub-pr-template.md

Thanks submitting your Operator. Please check below list before you create your Pull Request. ? your Operator for Operator Framework? [ ] Have you tested your Operator with all Custom Resource Definitions? ? ? ? set? ? [ ] Is your new CSV pointing to the previous version with the `replaces` property if you chose `replaces-mode` via the `updateGraph` property in `ci.yaml`? defined in the `package.yaml` or `annotations.yaml` ? [ ] Have you tested an update to your Operator when deployed via OLM? ? [ ] Modify more than one operator [ ] Modify an Operator you don't own [ ] Rename an operator - please remove and add with a different name instead [ ] Submit operators to both `upstream-community-operators` and `community-operators` at once [ ] Modify any files outside the above mentioned folders [ ] Contain more than one commit. Please squash your commits.* [ ] Description about the managed Application and where to find more information [ ] Features and capabilities of your Operator and how to use it [ ] Any manual steps about potential pre-requisites for using your Operator [ ] Human readable name and 1-liner description about your Operator <sup>1</sup> <sup>2</sup> [ ] Links to the maintainer, source code and documentation [ ] Example templates for all Custom Resource Definitions intended to be used [ ] A quadratic logo Remember that you can preview your CSV . -- <sup>1</sup> If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need <sup>2</sup> For more information see
Project: Checkmk (Observability and Analysis / Observability)
File: 15327.md

key | value | compatible | no version | 2.4.0b1 date | 2024-04-04T07:59:38+00:00 level | 2 class | fix component | checks edition | cre You might be affected by this Werk if you use <tt>mk_oracle</tt> on a unix system. You might be affected by this Werk if you use oracle wallet to connect to your database. You are definitively affected by this Werk if you use oracle wallet to connect to your database and used the instructions of our official documentation to setup your configuration. This Werk fixes connection problems introduced with 2.1.0p41, 2.2.0p24 and 2.3.0b4. Since <a href="https://checkmk.com/werk/16232">Werk #16232</a> we switch to a unprivileged user when executing oracle binaries. This causes problems when using an oracle wallet as the unprivileged user might not be able to access files defining the connection details and credentials. We introduced an additional permission check to the <code>-t</code> "Just check the connection" option of <code>mk_oracle</code>. It should help you modifying the permissions to continue using <code>mk_oracle</code> with oracle wallet. You can execute it with the following command: <pre> MKCONFDIR=/etc/checkmk/ MKVARDIR=/var/lib/checkmkagent /usr/lib/checkmkagent/plugins/mkoracle --no-spool -t </pre> The path to mk_oracle might be different if you execute it asynchronously. For a 60 second interval the path would be <code>/usr/lib/checkmkagent/plugins/60/mk_oracle</code> The script will test permissions of the files needed to connect to the database. It boils down to the following: <code>mk_oracle</code> will switch to the owner of <code>$ORACLE_HOME/bin/sqlplus</code> before executing <code>sqlplus</code>. So this user has to have the following permissions: <ul> <li>read <code>$TNS_ADMIN/sqlnet.ora</code></li> <li>read <code>$TNS_ADMIN/tnsnames.ora</code></li> <li>execute the wallet folder (<code>/etc/checkmk/oraclewallet</code> if followed the official documentation)</li> <li>read files inside the wallet folder (<code>/etc/checkmk/oraclewallet/*</code> if followed the official documentation)</li> </ul> Beside that we also fixed some bash syntax errors we introduced with <a href="https://checkmk.com/werk/16232">Werk #16232</a>. See <a href="https://checkmk.atlassian.net/wiki/spaces/KB/pages/70582273/Troubleshooting+mk+oracle+for+Windows+and+Linux">Troubleshooting mk_oracle for Windows and Linux</a> for more information about troubleshooting this problem.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_util.units.md

title: "Namespace: units" linkTitle: "units" slug: "lib_util.units" .units TO\_GB: `number` _ TO\_ONE\_CPU: ``1000000000`` _ TO\_ONE\_M\_CPU: ``1000000`` parseCpu(`value`): `number` | Name | Type | | : | : | | `value` | `string` | `number` _ parseDiskSpace(`value`): `number` | Name | Type | | : | : | | `value` | `string` | `number` _ parseRam(`value`): `number` | Name | Type | | : | : | | `value` | `string` | `number` _ unparseCpu(`value`): `Object` | Name | Type | | : | : | | `value` | `string` | `Object` | Name | Type | | : | : | | `unit` | `string` | | `value` | `number` | _ unparseRam(`value`): `Object` | Name | Type | | : | : | | `value` | `number` | `Object` | Name | Type | | : | : | | `unit` | `string` | | `value` | `number` |
Project: Vector (Observability and Analysis / Observability)
File: arc.md

title: Adaptive request concurrency (ARC) short: ARC weight: 1 tags: ["arc", "request", "concurrency", "adaptive request concurrency", "performance", "http"] Adaptive Request Concurrency (ARC) is a Vector networking feature that does away with static rate limits and automatically optimizes HTTP concurrency limits based on downstream service responses. The underlying mechanism is a feedback loop inspired by TCP congestion control algorithms. The end result is improved performance and reliability across your entire observability infrastructure. Check out the feature announcement for more information: {{< jump "/blog/adaptive-request-concurrency" >}}
Project: Netdata (Observability and Analysis / Observability)
File: vcsa_applmgmt_health.md

The `vcsaapplmgmthealth` alert is related to the health of VMware vCenter Server Appliance (VCSA) components. This alert is triggered when the health of one or more components is in a degraded or critical state, meaning that your VMware vCenter Server Appliance may be experiencing issues. Access the vSphere Client for the affected vCenter Server Appliance Log in to the vSphere Client to check detailed health information and manage your VCSA. Check the health status of VCSA components In the vSphere Client, navigate to `Administration` > `System Configuration` > `Services` and `Nodes` tab. The component health status will be shown in the `Health` column. Inspect the affected component(s) If any components show a status other than "green" (healthy), click on the component to view more details and understand the issue. Check logs related to the affected component(s) Access the vCenter Server Appliance Management Interface (VAMI) by navigating to `https://<appliance-IP-address-or-FQDN>:5480` and logging in with the administrator account. In the VAMI, click on the `Monitoring` tab > `Logs`. Download and inspect the logs to identify the root cause of the issue. Take appropriate actions Depending on the nature of the issue identified, perform the necessary actions or modifications to resolve it. Consult the VMware documentation for recommended solutions for specific component health issues. Monitor the component health After performing appropriate actions, continue to monitor the VCSA component health in the vSphere Client to ensure they return to a healthy status. Contact VMware support If you are unable to resolve the issue, contact VMware support for further assistance.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-9-1-1.md

aliases: [] hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 9.1.1 <!-- Auto generated by update changelog github action --> Cloud Monitoring: Support SLO burn rate. , Schema: Restore "hidden" in LegendDisplayMode. , Timeseries: Revert the timezone(s) property name change back to singular. , Alerting: Fix links in Microsoft Teams notifications. , Alerting: Fix notifications for Microsoft Teams. , Alerting: Fix width of Adaptive Cards in Teams notifications. , ColorPickerInput: Fix popover in disabled state. , Decimals: Fixes auto decimals to behave the same for positive and negative values. , Loki: Fix unique log row id generation. , Plugins: Fix file extension in development authentication guide. , TimeSeries: Fix jumping legend issue. , TimeSeries: Fix memory leak on viz re-init caused by KeyboardPlugin. , TimePicker: Fixes relative timerange of less than a day not displaying. , GrafanaUI: Fixes ClipboardButton to always keep multi line content. ,
Project: Grafana (Observability and Analysis / Observability)
File: alertmanager.md

aliases: ../../fundamentals/alertmanager/ # /docs/grafana/<GRAFANA_VERSION>/alerting/fundamentals/alertmanager/ ../../unified-alerting/fundamentals/alertmanager/ # /docs/grafana/<GRAFANA_VERSION>/alerting/unified-alerting/fundamentals/alertmanager/ ../../manage-notifications/alertmanager/ # /docs/grafana/<GRAFANA_VERSION>/alerting/manage-notifications/alertmanager/ canonical: https://grafana.com/docs/grafana/latest/alerting/notifications/alertmanager/ description: Learn about Alertmanagers and the Alertmanager options for Grafana Alerting labels: products: cloud enterprise oss title: Alertmanager weight: 111 Grafana sends firing and resolved alerts to Alertmanagers. The Alertmanager receives alerts, handles silencing, inhibition, grouping, and routing by sending notifications out via your channel of choice, for example, email or Slack. Grafana has its own Alertmanager, referred to as "Grafana" in the user interface, but also supports sending alerts to other Alertmanagers, such as the . You can use both internal and external Alertmanagers. The Grafana Alertmanager uses notification policies and contact points to configure how and where a notification is sent; how often a notification should be sent; and whether alerts should all be sent in the same notification, sent in grouped notifications based on a set of labels, or as separate notifications. Alertmanagers are visible from the drop-down menu on the Alerting Contact Points, Notification Policies, and Silences pages. In Grafana, you can use the Cloud Alertmanager, Grafana Alertmanager, or an external Alertmanager. You can also run multiple Alertmanagers; your decision depends on your set up and where your alerts are being generated. Grafana Alertmanager is an internal Alertmanager that is pre-configured and available for selection by default if you run Grafana on-premises or open source. The Grafana Alertmanager can receive alerts from Grafana, but it cannot receive alerts from outside Grafana, for example, from Mimir or Loki. Note that inhibition rules are not supported. Cloud Alertmanager runs in Grafana Cloud and it can receive alerts from Grafana, Mimir, and Loki. External Alertmanager can receive all your Grafana, Loki, Mimir, and Prometheus alerts. External Alertmanagers can be configured and administered from within Grafana itself. Here are two examples of when you may want to and send your alerts there instead of the Grafana Alertmanager: You may already have Alertmanagers on-premises in your own Cloud infrastructure that you have set up and still want to use, because you have other alert generators, such as Prometheus. You want to use both Prometheus on-premises and hosted Grafana to send alerts to the same Alertmanager that runs in your Cloud infrastructure. {{% docs/reference %}} {{% /docs/reference %}}
Project: Kuberhealthy (Observability and Analysis / Observability)
File: README.md

Use `helm package` to make a new helm archive file. You must be in the `deploy/helm/kuberhealthy/` directory so that the chart is found. Add a new section to the `index.yaml` file in this directory and edit the entries to point to the package file created in the prior step Install the newest Helm chart using the following commands: Create namespace "kuberhealthy" in the desired Kubernetes cluster/context: `kubectl create namespace kuberhealthy` Set your current namespace to "kuberhealthy": `kubectl config set-context --current --namespace=kuberhealthy` Add the kuberhealthy repo to Helm: `helm repo add kuberhealthy https://kuberhealthy.github.io/kuberhealthy/helm-repos` Install kuberhealthy: `helm install kuberhealthy kuberhealthy/kuberhealthy`
Project: Kepler (Observability and Analysis / Observability)
File: license.md

MIT License Copyright (c) 2019 Josh Bleecher Snyder Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Project: HertzBeat (Observability and Analysis / Observability)
File: ntp.md

id: ntp title: Monitoring NTP sidebar_label: NTP Monitor keywords: [ open source monitoring tool, open source NTP monitoring tool, monitoring NTP metrics ] Collect and monitor the general performance Metrics of NTP. Protocol UseNTP | 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 | | 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 | |--|-|| | responseTime | ms | The time it takes for the NTP server to respond to a request). | | time | ms | The current time reported by the NTP server). | | date | | The date corresponding to the current time reported by the NTP server). | | offset | ms | The time difference between the NTP server's clock and the client's clock). | | delay | ms | The time it takes for a request to reach the NTP server and for the response to return). | | version | | The version number of the NTP protocol used by the server). | | mode | | The operating mode of the NTP server, such as client, server, or broadcast). | | stratum | | The stratumevel of the NTP server, indicating its distance from a reference clock). | | referenceId | | An identifier that indicates the reference clock or time source used by the NTP server). | | precision | | The precision of the NTP server's clock, indicating its accuracy). |