cwielenb/CNCF-Dataset huggingface dataset:
Project: Grafana Mimir (Observability and Analysis / Observability)
File: v3.2.md

title: "Grafana Mimir Helm chart version 3.2 release notes" menuTitle: "V3.2 release notes" description: "Release notes for Grafana Mimir Helm chart version 3.2" weight: 300 Grafana Labs is excited to announce version 3.2 of the Grafana Mimir Helm chart, which is compatible with Grafana Mimir v2.4 or Grafana Enterprise Metrics (GEM) v2.3. The `mimir-distributed` Helm chart is the best way to install Mimir on Kubernetes. To learn about new features and enhancements in Grafana Mimir or GEM, see the release notes for or . The highlights that follow include the top features, enhancements, and bugfixes in this release. For a comprehensive list of changes, see the . Note: If you are upgrading from Grafana Mimir Helm chart 3.1, review the that follow. Notable enhancements are as follows: Added support for . Replaced the default anti-affinity rules with topologySpreadConstraints for all components which puts less restrictions on where Kubernetes can run pods. Updated the anti affinity rules in the sizing plans (`small.yaml`, `large.yaml`, `capped-small.yaml`, or `capped-large.yaml`). The sizing plans now enforce that no two pods of the ingester, store-gateway, or alertmanager StatefulSets are scheduled on the same Node. Pods from different StatefulSets can share a Node. Support for Openshift Route resource for NGINX has been added. In Grafana Mimir Helm chart v3.2, the following changes were made: If you are not using the sizing plans (`small.yaml`, `large.yaml`, `capped-small.yaml`, or `capped-large.yaml`) in production, you must reintroduce pod affinity rules for the ingester and store-gateway. This also fixes a missing label selector for the ingester. Merge the following configuration into your custom values file: ```yaml ingester: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: labelSelector: matchExpressions: key: target operator: In values: ingester topologyKey: "kubernetes.io/hostname" labelSelector: matchExpressions: key: app.kubernetes.io/component operator: In values: ingester topologyKey: "kubernetes.io/hostname" store_gateway: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: labelSelector: matchExpressions: key: target operator: In values: store-gateway topologyKey: "kubernetes.io/hostname" labelSelector: matchExpressions: key: app.kubernetes.io/component operator: In values: store-gateway topologyKey: "kubernetes.io/hostname" ``` : Fix wrong label selector in ingester anti affinity rules in the sizing plans. : Query-scheduler no longer periodically terminates connections from query-frontends and queriers. This caused some queries to time out and EOF errors in the logs.
Project: Netdata (Observability and Analysis / Observability)
File: kubelet_node_config_error.md

This alert, `kubeletnodeconfig_error`, is related to the Kubernetes Kubelet component. If you receive this alert, it means that there is a configuration-related error in one of the nodes in your Kubernetes cluster. Kubernetes Kubelet is an agent that runs on each node in a Kubernetes cluster. It ensures that containers are running in a pod and manages the lifecycle of those containers. Identify the node with the configuration error The alert should provide information about the node experiencing the issue. You can also use the `kubectl get nodes` command to list all nodes in your cluster and their statuses: ``` kubectl get nodes ``` Check the Kubelet logs on the affected node The logs for Kubelet can be found on each node of your cluster. Login to the affected node and check its logs using either `journalctl` or the log files in `/var/log/`. ``` journalctl -u kubelet ``` or ``` sudo cat /var/log/kubelet.log ``` Look for any error messages related to the configuration issue or other problems. Review and update the node configuration Based on the error messages you found in the logs, review the Kubelet configuration on the affected node. You might need to update the `kubelet-config.yaml` file or other related files specific to your setup. If any changes are made, don't forget to restart the Kubelet service on the affected node: ``` sudo systemctl restart kubelet ``` Check the health of the cluster After the configuration issue is resolved, make sure to check the health of your cluster using `kubectl`: ``` kubectl get nodes ``` Ensure that all nodes are in a `Ready` state and no errors are reported for the affected node.
Project: SkyWalking (Observability and Analysis / Observability)
File: on-demand-pod-log.md

This feature is to fetch the Pod logs on users' demand, the logs are fetched and displayed in real time, and are not persisted in any kind. This is helpful when users want to do some experiments and monitor the logs and see what's happing inside the service. Note: if you print secrets in the logs, they are also visible to the UI, so for the sake of security, this feature is disabled by default, please read the configuration documentation to enable this feature manually. As the name indicates, this feature only works for Kubernetes Pods. SkyWalking OAP collects and saves the service instance's namespace and Pod name in the service instance's properties, named `namespace` and `pod`, users can select the same and UI should fetch the logs by service instance in a given interval and display the logs in UI, OAP receives the query and checks the instance's properties and use the `namespace` and `pod` to locate the Pod and query the logs. If you want to register a service instance that has on demand logs available, you should add `namespace` and `pod` in the service instance properties, so that you can query the real time logs from that Pod. That said, in order to make this feature work properly, you should in advance configure the cluster role for OAP to list/get namespaces, services, pods and pods/log.
Project: Pixie (Observability and Analysis / Observability)
File: README.md

This directory contains the logic to extract and compile our license notice release document. To get all of the licenses, run the following command: ``` bazel build //tools/licenses:all_licenses ``` And copy the file output by the bazel build command into wherever you need it. To ensure that you don't get rate limited by Github, license builds need a Github API Key. This is read from the GHAPIKEY env var which is set through bazel action_env. Jenkins is setup with credentials and a bazelrc file to manage this automatically, but if you need to run a prod build locally that doesn't fail stamping, add `build --actionenv=GHAPIKEY=<ghtoken>` with your personal Github access token to your `user.bazelrc` file. Insturctions to create a token are here: https://help.github.com/en/articles/creating-a-personal-access-token-for-the-command-line Note that you don't need to provide any extra permissions, this is used to verify that a repo exists at a public github URL and avoid .
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: webhook.md

sidebar_position: 2 The Webhook notifier will perform an HTTP POST request to the specified endpoint everytime that a change in the flags is detected. The format of the call is specified in the and, you can to trust the data you are receiving. ```go ffclient.Config{ // ... Notifiers: []notifier.Notifier{ &webhooknotifier.Notifier{ EndpointURL: " https://example.com/hook", Secret: "Secret", Meta: map[string]string{ "app.name": "my app", }, }, // ... }, } ``` | Field | Description | ||-| | `EndpointURL` | The complete URL of your API (we will send a POST request to this URL, ) | | `Secret` | (optional)<br/>A secret key you can share with your webhook. We will use this key to sign the request (see for more details). | | `Meta` | (optional)<br/>A list of key value that will be add in your request, this is super useful if you want to add information on the current running instance of your app.<br/><br/>By default the hostname is always added in the meta information. | If you have configured a webhook, a `POST` request will be sent to the `EndpointURL` with a body in this format: ```json { "meta": { "hostname": "server01", // ... }, "flags": { "deleted": {}, // map of your deleted flags "added": {}, // map of your added flags "updated": { "flag-name": { // an object that contains old and new value "old_value": {}, "new_value": {} } } } } ``` ```json { "meta":{ "hostname": "server01" }, "flags":{ "deleted": { "test-flag": { "rule": "key eq \"random-key\"", "percentage": 100, "true": true, "false": false, "default": false } }, "added": { "test-flag3": { "percentage": 5, "true": "test", "false": "false", "default": "default" } }, "updated": { "test-flag2": { "old_value": { "rule": "key eq \"not-a-key\"", "percentage": 100, "true": true, "false": false, "default": false }, "new_value": { "disable": true, "rule": "key eq \"not-a-key\"", "percentage": 100, "true": true, "false": false, "default": false } } } } } ``` This header `X-Hub-Signature-256` is sent if the webhook is configured with a secret. This is the HMAC hex digest of the request body, and is generated using the SHA-256 hash function and the secret as the HMAC key. :::caution The recommendation is to always use the `Secret` and on your API/webook always verify the signature key to be sure that you don't have a man in the middle attack. :::
Project: Grafana Mimir (Observability and Analysis / Observability)
File: how-to-upgrade-golang-version.md

To upgrade the Golang version: Upgrade the build image version: Upgrade the Golang version in `mimir-build-image/Dockerfile`. Open PR and wait for mimir-build-image to be updated. Refer to the for more information. If the minimum supported Golang version should be upgraded as well: Upgrade `go` version in `go.mod`
Project: Grafana Mimir (Observability and Analysis / Observability)
File: SECURITY.md

Join the [kubernetes-security-announce] group for security and vulnerability announcements. You can also subscribe to an RSS feed of the above using . Instructions for reporting a vulnerability can be found on the [Kubernetes Security and Disclosure Information] page. Information about supported Kubernetes versions can be found on the [Kubernetes version and version skew support policy] page on the Kubernetes website.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: configure-hashicorp-vault-agent.md

title: "Configure Grafana Mimir to allow Vault Agent to inject certificates and keys into Pods" menuTitle: "Vault Agent" description: "Learn how to configure Grafana Mimir to receive client and server certificates and keys via Hashicorp Vault Agent" When you enable this feature, Helm updates the annotations on all Pods that have TLS (transport layer security) configurable components. When you deploy Mimir or GEM, Vault Agent fetches the relevant secrets from Vault according to the annotations and mounts them to the Pod. Note: Vault and Vault Agent must to be running already. Example `values.yaml` file: ```yaml vaultAgent: enabled: true roleName: "test-role" clientCertPath: "client/cert/path" clientKeyPath: "client/key/path" serverCertPath: "server/cert/path" serverKeyPath: "server/key/path" caCertPath: "ca/cert/path" ``` Generated Kubernetes Deployment YAML file based on the preceding example: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: release-name labels: helm.sh/chart: mimir-release-1.2.3 app.kubernetes.io/name: mimir app.kubernetes.io/instance: release-name app.kubernetes.io/component: comonent-name app.kubernetes.io/version: "123" app.kubernetes.io/managed-by: Helm annotations: {} namespace: "default" spec: replicas: 1 selector: matchLabels: app.kubernetes.io/name: mimir app.kubernetes.io/instance: release-name app.kubernetes.io/component: component-name strategy: type: RollingUpdate template: metadata: annotations: vault.hashicorp.com/agent-inject: "true" vault.hashicorp.com/role: "test-role" vault.hashicorp.com/agent-inject-secret-client.crt: "client/cert/path" vault.hashicorp.com/agent-inject-secret-client.key: "client/key/path" vault.hashicorp.com/agent-inject-secret-server.crt: "server/cert/path" vault.hashicorp.com/agent-inject-secret-server.key: "server/key/path" vault.hashicorp.com/agent-inject-secret-root.crt: "ca/cert/path" ``` `vault.hashicorp.com/agent-inject-secret-<FILENAME>: '<PATH>'` tells Vault Agent where to find the secret, and the name of the file to write the secret to. For example: `vault.hashicorp.com/agent-inject-secret-client.crt: 'client/cert/path'` will look for the secret at the path `client/cert/path` within Vault, and mount this secret to the pod as `client.crt` in the `/vault/secrets/` directory. For more information about Vault and Vault Agent, see . To configure TLS in Mimir, refer to [Securing Grafana Mimir communications with TLS]. {{% docs/reference %}} {{% /docs/reference %}}
Project: Netdata (Observability and Analysis / Observability)
File: riakkv_1h_kv_get_mean_latency.md

This alert calculates the average time between the reception of client `GET` requests and their subsequent responses in a `Riak KV` cluster over the last hour. If you receive this alert, it means that the average `GET` request latency in your Riak database has increased. Mean latency measures the average time taken between the start of a request and its completion, indicating the efficiency of the Riak system in processing `GET` requests. High mean latency implies slower processing times, which can negatively impact your application's performance. Check the system resources High latency might be related to resource bottlenecks on your Riak nodes. Check CPU, memory, and disk usage using `top` or `htop` tools. ``` top ``` or ``` htop ``` If you find any resource constraint, consider scaling your Riak cluster or optimize resource usage by tuning the application configurations. Investigate network issues Networking problems between the Riak nodes or the client and the nodes could cause increased latency. Check for network performance issues using `ping` or `traceroute`. ``` ping nodeipaddress ``` or ``` traceroute nodeipaddress ``` Investigate any anomalies or network congestion and address them accordingly. Analyze Riak KV configurations Check Riak configuration settings, like read/write parameters and anti-entropy settings, for any misconfigurations. Re-evaluate and optimize settings for performance based on your application requirements. Monitor application performance Analyze your application's request patterns and workload. High request rates or large amounts of data being fetched can cause increased latency. Optimize your application workload to reduce latency and distribute requests uniformly across the Riak nodes.
Project: Vector (Observability and Analysis / Observability)
File: 2020-07-09-add-musl-and-glibc-support-to-install-sh.md

date: "2020-07-17" title: "Leveraging glibc when possible" description: "If your Linux uses glibc, Vector will too." authors: ["hoverbear"] hideonrelease_notes: false pr_numbers: [2969, 2518] release: "0.10.0" badges: type: "performance" domains: ["operations"] As a result of some recent profiling and benchmarking, we determined that builds of Vector targeting `x8664-unknown-linux-gnu` outperformed builds targeting `x8664-unknown-linux-musl` under most usage scenarios on supported operating systems. Glibc builds may see performance improve by up to 20% over musl. For more information see the . We're investigating ways to improve our MUSL performance, too! Stay tuned to future releases. After some deliberation, we've opted to package and ship glibc builds where it's safe. While this change means Vector is no longer fully static on operating systems which use glibc, it should provide a better user experience. For the vast majority of users no special action needs to be taken. This change only affects x86 platforms. This change affects `.deb` and `.rpm` packages and Vectors installed via `https://sh.vector.dev`. This change does not affect any you may already be using. We now publish archives with the `gnu` prefix that contain glibc builds. Musl builds are untouched as `musl` still. This change does not affect non-Linux platforms. If you've fought with glibc before, you've probably got a burning question: Which version do we support? Don't worry. We have your back. We're using a base of CentOS 7, which means new Vector glibc builds will support all the way back to glibc 2.17 (released 2012-12-25). If that's still too new for your machines, please keep using the Musl builds. (Also, ) You should not need to do anything. If you are using a normal, recommended method of installing Vector, you should not experience issues. If you're provisioning Vector, the best way to make sure you get the most up to date stable version is to run this: ```bash title="provision_vector.sh" curl --proto '=https' --tlsv1.2 -sSfL https://sh.vector.dev | bash -s -- -y ``` If you don't need the latest and greatest, check your official distribution repository. Some distributions, such as , have official Vector packages. You can also find Vector packages in the official repositories. Interested in packaging Vector for your OS? We are too.
Project: Grafana (Observability and Analysis / Observability)
File: tooltip-options-1.md

title: Tooltip options comments: | There are two tooltip shared files, tooltip-options-1.md and tooltip-options-2.md, to cover the most common combinations of options. Using two shared files ensures that content remains consistent across visualizations that share the same options and users don't have to figure out which options apply to a specific visualization when reading that content. This file is used in the following visualizations: bar chart, pie chart, state timeline, status history Tooltip options control the information overlay that appears when you hover over data points in the visualization. When you hover your cursor over the visualization, Grafana can display tooltips. Choose how tooltips behave. Single - The hover tooltip shows only a single series, the one that you are hovering over on the visualization. All - The hover tooltip shows all series in the visualization. Grafana highlights the series that you are hovering over in bold in the series list in the tooltip. Hidden - Do not display the tooltip when you interact with the visualization. Use an override to hide individual series from the tooltip. When you set the Tooltip mode to All, the Values sort order option is displayed. This option controls the order in which values are listed in a tooltip. Choose from the following: None - Grafana automatically sorts the values displayed in a tooltip. Ascending - Values in the tooltip are listed from smallest to largest. Descending - Values in the tooltip are listed from largest to smallest. Set the maximum height of the tooltip box. The default is 600 pixels.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-strategy_info_by_id.md

category: Strategy apiurl: '/api/v1/strategy/#{strategy_id}' title: "Get Strategy info by id" type: 'GET' sample_doc: 'template.html' layout: default Required ex. /api/v1/strategy/904 ```Status: 200``` ```{ "id": 904, "metric": "agent.alive", "tags": "", "max_step": 3, "priority": 1, "func": "all(#3)", "op": "==", "right_value": "1", "note": "this is a test", "run_begin": "00:00", "run_end": "24:00", "tpl_id": 221 }```
Project: Graylog (Observability and Analysis / Observability)
File: EntityDataTable.md

Define custom cell and header renderer: ```js import EntityDataTable from './EntityDataTable'; <EntityDataTable visibleColumns={['title', 'description']} data={[{ id: 'row-id', title: 'Row title', description: 'Row description', }]} columnDefinitions={[ { id: 'title', title: 'Title' }, { id: 'description', title: 'Description' }, ]} columnRenderers={{ title: { renderCell: (listItem) => `The title: ${listItem.title}`, renderHeader: (attribute) => `Custom ${attribute.title}`, }, }} /> ``` Render row actions: ```js import EntityDataTable from './EntityDataTable'; <EntityDataTable visibleColumns={['title', 'description']} data={[{ id: 'row-id', title: 'Row title', description: 'Row description', }]} columnDefinitions={[ { id: 'title', title: 'Title' }, { id: 'description', title: 'Description' }, ]} rowActions={() => <div><button type="button">Actions</button></div>}/> ``` Only render a column when the user has the required permissions: ```js import EntityDataTable from './EntityDataTable'; <EntityDataTable visibleColumns={['title', 'description']} data={[{ id: 'row-id', title: 'Row title', description: 'Row description', }]} columnDefinitions={[ { id: 'title', title: 'Title' }, { id: 'description', title: 'Description' }, ]} attributePermissions={{ description: { permissions: ['description:read'], }, }} /> ``` Change the width of a column, with the related column renderer. Column renderers can have either a `width` defined as a fraction like `2`. If no width is defined we are using a default of `1`. The width defines which fraction of the assignable space the column should claim. It works similar to the css attribute `flex`. Optionally you can also define a `minWidth` to override the default min width for flexible columns. This can be helpful to ensure a column has enough space, no matter how large the table width is. or a `staticWidth` in px. Useful when the cells contain e.g. just an icon and its width never changes. Please have a look at the default column renderers defined in the `EntityDataTable` since they contain predefined widths for common attributes like `description`. ```js import EntityDataTable from './EntityDataTable'; <EntityDataTable visibleColumns={['title', 'summary', 'status']} data={[{ id: 'row-id', title: 'Entity title', summary: 'Entity summary', status: 'status', }]} columnDefinitions={[ { id: 'title', title: 'Title' }, { id: 'summary', title: 'Summary' }, { id: 'status', title: 'Status' }, ]} columnRenderers={{ summary: { width: 2, minWidth: 200 }, status: { staticWidth: 100 } }}/> ```
Project: Centreon (Observability and Analysis / Observability)
File: httpserver.md

This module aims to provide a HTTP/S server to expose handy endpoints to talk to Gorgone. It relies on a core API module to server Gorgone events and can dispatch any other piece of code. | Directive | Description | Default value | | : | :-- | : | | address | IP address for the server to bind to | `0.0.0.0` | | port | Port on which the server will listen to requests | `8080` | | ssl | Boolean to enable SSL terminaison | `false` | | sslcertfile | Path to the SSL certificate (if SSL enabled) | | | sslkeyfile | Path to the SSL key (if SSL enabled) | | | auth | Basic credentials to access the server | | | allowed_hosts | Peer address to access the server | | ```yaml name: httpserver package: "gorgone::modules::core::httpserver::hooks" enable: true address: 0.0.0.0 port: 8443 ssl: true sslcertfile: /etc/pki/tls/certs/server-cert.pem sslkeyfile: /etc/pki/tls/server-key.pem auth: enabled: true user: admin password: password allowed_hosts: enabled: true subnets: 127.0.0.1/32 10.30.2.0/16 ``` Below the configuration to add other endpoints: ```yaml dispatch: endpoint: "/mycode" method: GET class: "path::to::my::code" ``` | Event | Description | | :-- | :-- | | HTTPSERVERREADY | Internal event to notify the core |