cwielenb/CNCF-Dataset huggingface dataset:
Project: Botkube (Observability and Analysis / Observability)
File: YYYY-MM-DD-template.md

Created on {date in the `2020-11-02` format} by {Author} ({GitHub username}) | Status | || | `PROPOSED/REJECTED/ACCEPTED/IMPLEMENTED` | <!-- General overview of the proposal and section with ToC --> <!-- toc --> * * + <!-- tocstop --> <!-- What other approaches did you consider, and why did you rule them out? These do not need to be as detailed as the proposal, but should include enough information to express the idea and why it was not acceptable. -->
Project: Grafana (Observability and Analysis / Observability)
File: configure-slack.md

canonical: https://grafana.com/docs/grafana/latest/alerting/configure-notifications/manage-contact-points/integrations/configure-slack/ description: Configure the Slack integration to connect alerts generated by Grafana Alerting keywords: grafana alerting slack integration labels: products: cloud enterprise oss menuTitle: Slack title: Configure Slack for Alerting weight: 300 Use the Grafana Alerting - Slack integration to send Slack notifications when your alerts are firing. There are two ways of integrating Slack into Grafana Alerting. Use a Enable your app to access the Slack API. If, for example, you are interested in more granular control over permissions, or your project is expected to regularly scale, resulting in new channels being created, this is the best option. Use a Webhooks is the simpler way to post messages into Slack. Slack automatically creates a bot user with all the necessary permissions to post messages to one particular channel of your choice. {{< admonition type="note" >}} Grafana Alerting only allows one Slack channel per contact point. {{< /admonition >}} If you are using a Slack API Token, complete the following steps. Follow steps 1 and 2 of the . Add the scope to give your app the ability to post in all public channels without joining. In OAuth Tokens for Your Workspace, copy the Bot User OAuth Token. Open your Slack workplace. Right click the channel you want to receive notifications in. Click View channel details. Scroll down and copy the Channel ID. {{< admonition type="note" >}} While going through these steps, Slack may prompt you to Reinstall your app in order for the changes to take effect. {{< /admonition >}} If you are using a Webhook URL, follow steps 1 and 5 in the . {{< admonition type="note" >}} Make sure you copy the Slack app Webhook URL. You will need this when setting up your contact point integration in Grafana Alerting. {{< /admonition >}} To create your Slack integration in Grafana Alerting, complete the following steps. Navigate to Alerts & IRM -> Alerting -> Contact points. Click + Add contact point. Enter a contact point name. From the Integration list, select Slack. If you are using a Slack API token: In the Recipient field, copy in the channel ID. In the Token field, copy in the Bot User OAuth Token that starts with xoxb-. If you are using a Webhook URL, in the Webhook field, copy in your Slack app Webhook URL. Click Test to check that your integration works. Click Save contact point. To add the contact point and integration you created to your default notification policy, complete the following steps. Navigate to Alerts & IRM -> Alerting -> Notification policies. In the Default policy, click the ellipsis icon () and then Edit. Change the default policy to the contact point you created. Click Update default policy. Note: If you have more than one contact point, add a new notification policy rather than edit the default one, so you can route specific alerts to Slack. For more information, refer to . {{% docs/reference %}} {{% /docs/reference %}}
Project: Graylog (Observability and Analysis / Observability)
File: Jumbotron.md

```js { "props": { "className": "container" } } import { Button } from 'components/bootstrap'; <Jumbotron> <h1>Hello, world!</h1> <p> This is a simple hero unit, a simple jumbotron-style component for calling extra attention to featured content or information. </p> <p> <Button bsStyle="primary">Learn more</Button> </p> </Jumbotron> ```
Project: HertzBeat (Observability and Analysis / Observability)
File: hadoop.md

id: hadoop title: Monitoring Hadoop sidebar_label: Hadoop keywords: [Open Source Monitoring System, Open Source Java Monitoring, Hadoop JVM Monitoring] Collect and monitor general performance metrics for the JVM virtual machine in Hadoop. Protocol used: JMX You need to enable JMX service in the Hadoop application before monitoring. HertzBeat uses the JMX protocol to collect performance metrics from Hadoop's JVM. Add JVM parameters when the application starts. Note that you can customize the exposed port and external IP. 1.Enter the hadoop-env.sh configuration file and enter the following command in the terminal: ```shell vi $HADOOP_HOME/etc/hadoop/hadoop-env.sh ``` 2.Add the following parameters, where `port` is the number of the custom-exposed port ```shell export HADOOPOPTS= "$HADOOPOPTS -Djava.rmi.server.hostname=ip -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false " ``` 3.Save and exit, and then execute "start-all.sh" in the "$HADOOP_HOME/sbin" directory to restart the service. | 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 | Port provided by JMX | | Username | JMX connection user name, optional | | Password | JMX connection password, optional | | 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 | |-|-|-| | name | | metrics name | | committed | kb | total size | | init | kb | init size | | max | kb | max size | | used | kb | used size | | Metric name | Metric unit | Metric help description | |-|-|-| | committed | kb | total size | | init | kb | init size | | max | kb | max size | | used | kb | used size | | Metric name | Metric unit | Metric help description | |--|-|--| | LoadedClassCount | | Loaded Class Count | | TotalLoadedClassCount | | Total Loaded Class Count | | UnloadedClassCount | | Unloaded Class Count | | Metric name | Metric unit | Metric help description | |-|-|-| | TotalStartedThreadCount | | Total Started Thread Count | | ThreadCount | | Thread Count | | PeakThreadCount | | Peak Thread Count | | DaemonThreadCount | | Daemon Thread Count | | CurrentThreadUserTime | ms | Current Thread User Time | | CurrentThreadCpuTime | ms | Current Thread Cpu Time |
Project: M3 (Observability and Analysis / Observability)
File: namespace_mgmt.md

title: "Namespace Management" weight: 8 draft: true <!-- TODO: Where does this doc come from? --> M3DB uses the concept of namespaces to determine how metrics are stored and retained. The M3DB operator allows a user to define their own namespaces, or to use a set of presets we consider to be suitable for production use cases. Namespaces are configured as part of an m3dbcluster spec. 10s:2d This preset will store metrics at 10 second resolution for 2 days. For example, in your cluster spec: spec: ... namespaces: name: metrics-short-term preset: 10s:2d 1m:40d This preset will store metrics at 1 minute resolution for 40 days. spec: ... namespaces: name: metrics-long-term preset: 1m:40d You can also define your own custom namespaces by setting the NamespaceOptions within a cluster spec. The API lists all available fields. As an example, a namespace to store 7 days of data may look like: ... spec: ... namespaces: name: custom-7d options: bootstrapEnabled: true flushEnabled: true writesToCommitLog: true cleanupEnabled: true snapshotEnabled: true repairEnabled: false retentionOptions: retentionPeriod: 168h blockSize: 12h bufferFuture: 20m bufferPast: 20m blockDataExpiry: true blockDataExpiryAfterNotAccessPeriod: 5m indexOptions: enabled: true blockSize: 12h
Project: Grafana (Observability and Analysis / Observability)
File: secret-scan.md

description: Detect and revoke leaked Grafana service account tokens labels: products: enterprise oss menuTitle: Configure secret scanning title: Configure Grafana secret scanning and notifications weight: 1000 With Grafana, you can use the GitHub Secret Scanning service to determine if your have been leaked on GitHub. When GitHub Secret Scanning detects a Grafana secret, its hash is stored in Grafana Labs' secret scanning service. Grafana instances, whether on-premises or on the cloud, can use this service to verify if a token generated by the instance has been made public. This verification is done by comparing the token's hash with the exposed token's hash. If the service detects a leaked token, it immediately revokes it, making it useless, and logs the event. {{% admonition type="note" %}} If the `revoke` option is disabled, the service only sends a notification to the configured webhook URL and logs the event. The token is not automatically revoked. {{% /admonition %}} You can also configure the service to send an outgoing webhook notification to a webhook URL. The notification includes a JSON payload that contains the following data: ```json { "alert_uid": "c9ce50a1-d66b-45e4-9b5d-175766cfc026", "linktoupstream_details": <URL to token leak>, "message": "Token of type grafanaserviceaccount_token with name sa-the-toucans has been publicly exposed in <URL to token leak>. Grafana has revoked this token", "state": "alerting", "title": "SecretScan Alert: Grafana Token leaked" } ``` {{% admonition type="note" %}} Secret scanning is disabled by default. Outgoing connections are made once you enable it. {{% /admonition %}} Ensure all your API keys have been migrated to service accounts. For more information about service account migration, refer to . Open the Grafana configuration file. In the `[secretscan]` section, update the following parameters: ```ini [secretscan] enabled = true revoke = true ``` Save the configuration file and restart Grafana. Create an oncall integration of the type Webhook and set up alerts. To learn how to create a Grafana OnCall integration, refer to . Copy the webhook URL of the new integration. Open the Grafana configuration file. In the `[secretscan]` section, update the following parameters, replacing the URL with the webhook URL you copied in step 2. ```ini [secretscan] oncall_url = https://example.url/integrations/v1/webhook/3a359nib9eweAd9lAAAETVdOx/ ``` Save the configuration file and restart Grafana.
Project: Checkmk (Observability and Analysis / Observability)
File: 16529.md

key | value | date | 2024-02-23T08:14:30+00:00 version | 2.4.0b1 class | fix edition | cee component | ec level | 1 compatible | yes Previously, the tooltip on a matched rule would say it is a cancelling rule. This message was misleading and was changed.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-dashboard_graph_update.md

category: DashboardGraph apiurl: '/api/v1/dashboard/graph/:id' title: 'Update a DashboardGraph' type: 'PUT' sample_doc: 'dashboard.html' layout: default Required ``` { "counters": ["value/name=pfc.push.ms","value/name=pfc.push.size", "agent.alive"], "falcon_tags": "srv=falcon" } ``` ```Status: 200``` ```{"message":"ok"}``` For errors responses, see the .
Project: Kuberhealthy (Observability and Analysis / Observability)
File: bug.md

name: Bug about: You have found a software bug title: '' labels: bug assignees: '' Describe the bug A clear and concise description of what the bug is. Steps To Reproduce Have 5,000,000 pods in kube-system. Enable restart checking. Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. You can paste images into github and they will upload automatically. Versions Cluster OS: [e.g. CoreOS 1800.1.0] Kubernetes Version: 1.9.7 Kuberhealthy Release or build [e.g. 0.1.5 or 235] Additional context Add any other context about the problem here.
Project: Grafana Loki (Observability and Analysis / Observability)
File: introduction.md

title: "Introduction" description: "The Loki Operator provides Kubernetes native deployment and management of Loki and related logging components" lead: "" date: 2022-06-21T08:48:45+00:00 lastmod: 2022-06-21T08:48:45+00:00 draft: false images: [] menu: docs: parent: "prologue" weight: 100 toc: true The Loki Operator provides native deployment and management of and related logging components. The purpose of this project is to simplify and automate the configuration of a Loki based logging stack for Kubernetes clusters. The Loki operator includes, but is not limited to, the following features: Kubernetes Custom Resources: Use Kubernetes custom resources to deploy and manage Loki, Alerting rules, Recording rules, and related components. Simplified Deployment Configuration: Configure the fundamentals of Loki like tenants, limits, replication factor and storage from a native Kubernetes resource. One page summary of how to start with the Loki Operator.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_pod.KubePodSpec.md

title: "Interface: KubePodSpec" linkTitle: "KubePodSpec" slug: "libk8spod.KubePodSpec" .KubePodSpec containers: [] _ `Optional` ephemeralContainers: [] _ `Optional` initContainers: [] _ nodeName: `string` _ `Optional` nodeSelector: `Object` _ `Optional` readinessGates: { `conditionType`: `string` }[] _ `Optional` volumes: []
Project: Elastic (Observability and Analysis / Observability)
File: to_long.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Converts an input value to a long value. If the input parameter is of a date type, its value will be interpreted as milliseconds since the Unix epoch, converted to long. Boolean true will be converted to long 1, false to 0. ``` ROW str1 = "2147483648", str2 = "2147483648.2", str3 = "foo" | EVAL long1 = TOLONG(str1), long2 = TOLONG(str2), long3 = TO_LONG(str3) ```
Project: Grafana Loki (Observability and Analysis / Observability)
File: tenant.md

title: tenant menuTitle: description: The 'tenant' Promtail pipeline stage. aliases: ../../../clients/promtail/stages/tenant/ weight: The tenant stage is an action stage that sets the tenant ID for the log entry picking it from a field in the extracted data map. If the field is missing, the default promtail client will be used. ```yaml tenant: [ label: <string> ] [ source: <string> ] [ value: <string> ] ``` For the given pipeline: ```yaml pipeline_stages: json: expressions: customerid: customerid tenant: source: customer_id ``` Given the following log line: ```json {"customer_id":"1","log":"log message\n","stream":"stderr","time":"2019-04-30T02:12:41.8443515Z"} ``` The first stage would extract `customer_id` into the extracted map with a value of `1`. The tenant stage would set the `X-Scope-OrgID` request header (used by Loki to identify the tenant) to the value of the `customer_id` extracted data, which is `1`. For the given pipeline: ```yaml pipeline_stages: json: expressions: app: message: labels: app: match: selector: '{app="api"}' stages: tenant: value: "team-api" output: source: message ``` Given the following log line: ```json {"app":"api","log":"log message\n","stream":"stderr","time":"2019-04-30T02:12:41.8443515Z"} ``` The pipeline would: Decode the JSON log Set the label `app="api"` Process the `match` stage checking if the `{app="api"}` selector matches and - whenever it matches - run the sub stages. The `tenant` sub stage would override the tenant with the value `"team-api"`. ```yaml scrape_configs: job_name: kubernetes-pods-name kubernetessdconfigs: role: pod relabel_configs: action: replace source_labels: metakubernetesnamespace target_label: namespace pipeline_stages: match: selector: '{namespace=~".+"}' stages: tenant: label: "namespace" output: source: message ``` The pipeline would: Match any log where the `namespace` label matched the regexp `.+` Process the `match` stage checking if the `{namespace=~".+"}` selector matches and - whenever it matches - run the sub stages. The `tenant` sub stage would override the tenant with the value with the value of the `namespace` label, if it was set.
Project: Pinpoint (Observability and Analysis / Observability)
File: bug_report.md

name: Bug report about: Create a report to help us improve Please check the , and search existing for similar questions before creating a new issue.YOU MAY DELETE THIS PREREQUISITES SECTION. , and and found no answer. master/v1.7.3/v1.7.2 etc. A clear and concise description of what the bug is. Steps to reproduce, for example: Ran '...' with agent attached '...' method invoked '...' interceptor threw '...' exception A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. If applicable, please attach agent/collector/web DEBUG log that includes the code execution that led to the bug. In case of agents, including the start-up log may be of great help. Add any other context about the problem here, such as affected library for agents, how your collector/web/hbase is set up if applicable.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: configure-tracing.md

aliases: ../configuring/configuring-tracing/ configuring-tracing/ ../operators-guide/configure/configure-tracing/ description: Learn how to configure Grafana Mimir to send traces to Jaeger. menuTitle: Tracing title: Configure Grafana Mimir tracing weight: 100 Grafana Mimir uses to implement distributed tracing. Jaeger is a valuable tool for troubleshooting the behavior of Grafana Mimir in production. Set up Jaeger deployment to collect and store traces from Grafana Mimir. A deployment includes either the Jaeger all-in-one binary, or a distributed system of agents, collectors, and queriers. If you run Grafana Mimir on Kubernetes, refer to [Jaeger Kubernetes](https://github.com/jaegertracing/jaeger-kubernetes). To configure Grafana Mimir to send traces, perform the following steps: Set the `JAEGERAGENTHOST` environment variable in all components to point to the Jaeger agent. Enable sampling in the appropriate components: The ingester and ruler self-initiate traces and should have sampling explicitly enabled. Sampling for the distributor and query-frontend can be enabled in Grafana Mimir or in an upstream service, like a proxy or gateway running in front of Grafana Mimir. To enable sampling in Grafana Mimir components you can specify either `JAEGERSAMPLERMANAGERHOSTPORT` for remote sampling, or `JAEGERSAMPLERTYPE` and `JAEGERSAMPLERPARAM` to manually set sampling configuration. Refer to [Jaeger Client Go documentation](https://github.com/jaegertracing/jaeger-client-go#environment-variables) for the full list of environment variables you can configure. Note that you must specify one of `JAEGERAGENTHOST` or `JAEGERSAMPLERMANAGERHOSTPORT` in each component for Jaeger to be enabled, even if you plan to use the default values.
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_registry.EditResourceEvent.md

title: "Interface: EditResourceEvent" linkTitle: "EditResourceEvent" slug: "plugin_registry.EditResourceEvent" .EditResourceEvent Event fired when editing a resource. data: `Object` | Name | Type | Description | | : | : | : | | `resource` | `any` | The resource for which the deletion was called. | | `status` | `OPENED` \| `CLOSED` | What exactly this event represents. 'OPEN' when the edit dialog is opened. 'CLOSED' when it is closed. | _ type: `EDIT_RESOURCE`
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_connack_sent_reason_unsuccessful.md

This alert is triggered when there is a significant increase in the number of unsuccessful v3/v5 CONNACK packets sent by the VerneMQ broker within the last minute. A higher-than-normal rate of unsuccessful CONNACKs indicates that clients are experiencing difficulties establishing a connection with the MQTT broker. A CONNACK packet is an acknowledgment packet sent by the MQTT broker to a client in response to a CONNECT command. The CONNACK packet informs the client if the connection has been accepted or rejected, which is indicated by the return code. An unsuccessful CONNACK packet indicates a rejected connection. Check VerneMQ logs: Inspect the VerneMQ logs for error messages or reasons why the connections are being rejected. By default, these logs are located at `/var/log/vernemq/console.log` and `/var/log/vernemq/error.log`. Look for entries with "CONNACK" and discern the cause of the unsuccessful connections. Diagnose client configuration issues: Analyze the rejected connection attempts' client configurations, such as incorrect credentials, unsupported protocol versions, or security settings. Debug the client-side applications, fix the configurations, and try reconnecting to the MQTT broker. Evaluate broker capacity: Check the system resources and settings of the VerneMQ broker. An overloaded broker or insufficient system resources, such as CPU and memory, can cause connection rejections. Optimize the VerneMQ configuration, upgrade the broker's hardware, or distribute the load between multiple brokers to resolve the issue. Assess network issues: Verify the network topology, firewalls, and router settings to ensure clients can reach the MQTT broker. Network latency or misconfigurations can lead to unsuccessful CONNACKs. Use monitoring tools such as `ping`, `traceroute`, or `netstat` to diagnose network issues and assess connectivity between clients and the broker. Verify security settings and permissions: Check the VerneMQ broker's security settings, including access control lists (ACL), user permissions, and authentication/authorization settings. Restricted access or incorrect permissions can lead to connection rejections. Update the security settings accordingly and test the connection again.
Project: Grafana (Observability and Analysis / Observability)
File: e2e-core.md

This document is specific to the . Be sure that you've read the . `yarn e2e` Creates an isolated `grafana-server` home under \<repo-root>/e2e/tmp with provisioned data sources and dashboards. This copies locally build binary and frontend assets from your repo root so you need to have a built backend and frontend for this to run locally. The server starts on port 3001 so it does not conflict with your normal dev server. `yarn e2e:debug` Same as above but runs the tests in chrome and does not shutdown after completion. `yarn e2e:dev` Same as above but does not run any tests on startup. It lets you pick a test first. If you already have a Grafana instance running, you can provide a specific URL by setting the `BASE_URL` environment variable: ```shell BASE_URL=http://172.0.10.2:3333 yarn e2e ``` The above commands use some utils scripts under that can also be used for more control. `./scripts/grafana-server/start-server` This creates a fresh new grafana server working dir, setup's config and starts the server. It will also kill any previously started server that is still running using pid file at \<repo-root>/scripts/grafana-server/tmp/pid. `./scripts/grafana-server/wait-for-grafana` waits for `$HOST` and `$PORT` to be available. Per default localhost and 3001. `./e2e/run-suite <debug|dev|noarg>` Starts cypress in different modes. All the integration tests are located at \<repo-root>/e2e/suite\<x>/specs.