cwielenb/CNCF-Dataset huggingface dataset:
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: store_your_flags.md

sidebar_position: 10 description: Where to store your configuration flag? To work GO Feature Flag is using a configuration file to store your feature flags configuration. Ideally this file should be placed somewhere accessible by all your app that are using the GO Feature Flag module. In the solution there is a system we call `retriever` that is in charge of reading the file remotely. GO Feature Flag supports different ways to retrieve the configuration file (see list bellow). Sometimes, you may need to store your feature flags in different locations. In such cases, you can configure multiple retrievers to retrieve the flags from different sources within your GO Feature Flag instance. To set this up, you need to configure the field to consume from different retrievers. What this does is that it calls all the retrievers in parallel and applies them in the order you have provided. Keep in mind that if a flag is defined in multiple retrievers, it can be overridden by a later flag. For instance, if you have a flag named `my-feature-flag` in the first file and another flag with the same name in the second file, the second configuration will take precedence. AWS S3 is the object store of AWS, you can add your GO Feature Flag configuration file in any bucket and reference it in your configuration. Google Cloud Storage is a RESTful online file storage web service for storing and accessing data on Google Cloud Platform infrastructure. You can add your GO Feature Flag configuration file in any bucket and reference it. A ConfigMap is an API object used to store non-confidential data in key-value pairs inside kubernetes. GO Feature Flag can read directly in a `configmap` in your namespace. When your feature flags file is ready you can store it directly in your kubernetes instance by using this command: ```shell kubectl create configmap goff --from-file=examples/retriever_configmap/flags.yaml ``` It will allow your file to be available inside Kubernetes. Serving file with an HTTP server is probably something you are already doing, GO Feature Flag can retrieve your configuration file, from any HTTP endpoint and read it from there. Reading the file from GitHub is pretty straight forward. You commit your file into your favorite repository (it can be public or private) and GO Feature Flag can retrieve your configuration file and use it. You can store your feature flags configuration in your hard drive directly. :::tip Using a file is great for local testing, but in production it is recommended to use a distributed system instead. ::: If you are using the GO module, you can also implement your own retriever. For this look at this to start building your own `retriever`.
Project: Sentry (Observability and Analysis / Observability)
File: notification_actions.md

Notification Actions are meant to be a generic abstraction of the actions we fire when alert rules go off. The structure of the model for `NotificationAction` was abstracted from `AlertRuleTriggerAction` but decouples it from issues/events/incidents. Instead, they are meant to help send notifications to third-party integrations rather than individual channels such as email, or personal notifications settings. These notifications can be configured across the whole organization/project, rather than per recipient. It was originally designed for Spike Protection, but should be generic enough to apply to any other part of Sentry. Some examples of possible notification actions: Receiving audit log entries to a slack channel Creating jira tickets from new user feedback items Triggering a GitHub notification whenever a release is created in Sentry Sending quota notifications or billing updates to a specific non-user email Project notifications send to a slack channel instead of the teams/members Notification Actions all rely on a few things: Triggers - the source of the notification (i.e. what happened in Sentry that caused the notification) Services - the delivery mechanism (e.g. Slack, PagerDuty, MSTeams, Sentry Notifications, etc.) Targets - the type of recipeint for the notification. (i.e. is the recipient a user, a team, or specific to the integration) Registrations - the `ActionRegistration` subclass which helps setup new actions If you need to setup new types of triggers, services or targets, you can do so by extending the relevant enums in the `notificationaction.py`. These enums are used by Django when validating new Notification Actions before saving, meaning this step cannot be skipped. The registration classes can be set up via the decorator: ```python @NotificationAction.register_action( triggertype=ActionTrigger.AUDITLOG.value, servicetype=ActionService.SENTRYNOTIFICATION.value, target_type=ActionTarget.SPECIFIC.value, ) class SentryAuditLogRegistration(ActionRegistration) ``` The registration methods are initialized to the following (when they inherit from `ActionRegistration`). `fire()` is where you should write the logic for talking to the service, and it must be specified for each registration. `validate_action()` will be invoked when validating new actions. If your action requires unique validation (on top of database integrity checks) this is where you can do so. `serialize_available()` will be invoked to serialize the availability of your action to the frontend. This allows the app to hit one endpoint for all available actions rather than querying across the resources it may take to determine if your action is available. ```python class SentryAuditLogRegistration(ActionRegistration): def fire(self, data: Any) -> None: pass @classmethod def validate_action(cls, data: NotificationActionInputData) -> None: pass @classmethod def serialize_available( cls, organization: Organization, integrations: List[RpcIntegration] = None ) -> List[Any]: return [] ```
Project: Netdata (Observability and Analysis / Observability)
File: windows_10min_cpu_usage.md

This alert calculates the average total `CPU utilization` on a Windows system over the last 10 minutes. If you receive this warning or critical alert, it means that your system is experiencing high CPU usage, which could lead to performance issues. `CPU utilization` is the percentage of time the CPU spends executing tasks, as opposed to being idle. A high CPU utilization means that the CPU is working on a large number of tasks and may not have enough processing power to handle additional tasks efficiently. This can result in slow response times and overall system performance issues. Identify high CPU usage processes: Open Task Manager by pressing `Ctrl + Shift + Esc` on your keyboard, or right-click on the Taskbar and select "Task Manager." Click the "Processes" tab, and sort by the "CPU" column to identify the processes consuming the most CPU resources. Analyze process details: Right-click on the process with high CPU usage and select "Properties" or "Go to details" to learn more about the process, its location, and its purpose. Determine if the process is essential: Research the process in question to ensure that it is safe to terminate. Some processes are integral to the system, and terminating them may cause instability or crashes. Terminate or optimize the problematic process: If the process is not essential, you can right-click on it and select "End task" to stop it. If the process is necessary, consider optimizing its performance or updating the software responsible for the process. In some cases, restarting the system may help resolve temporary high CPU usage issues. Monitor CPU usage after taking action: Continue monitoring CPU usage to ensure that the issue has been resolved. If the problem persists, further investigation may be required, such as examining system logs or using performance analysis tools like Windows Performance Monitor.
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: SECURITY.md

The of Pyroscope is supported. Please email security@pyroscope.io, and we will respond as quickly as possible. Please provide as much information as possible: A detailed description of the vulnerability we can use to reproduce your findings. Who can exploit this vulnerability and what would they gain. An attack scenario. Information about known exploits if any. If the vulnerability is considered valid and accepted, a patch will be made for the latest pyroscope version. If the vulnerability is deemed invalid, no further action is required.
Project: Vector (Observability and Analysis / Observability)
File: 2020-05-27-add-support-for-loading-multiple-cas.md

date: "2020-07-13" title: "Support for loading multiple CAs" description: "Complicated PEM? No PEM-blem with Vector!" authors: ["hoverbear"] hideonrelease_notes: false pr_numbers: [2616] release: "0.10.0" badges: type: "enhancement" sources: ["socket"] Working with `openssl` isn't very fun, and we don't want to inflict that on you. Vector can deal non-trivial certificate chains now. This means if you have a `.pem` file with 2 chains of 4 certs, well, Vector should be able to work it out. This is particularly useful if you have a socket source: ```toml title="vector.toml" [sources.tls] type = "socket" address = "0.0.0.0:6514" mode = "tcp" tls.enabled = true tls.crt_path = "cert.pfx" tls.ca_path = "ca.pem" # Now supported: More complicated PEMS! tls.verify_certificate = true ``` If it doesn't, that's a bug. We squash bugs.
Project: Cortex (Observability and Analysis / Observability)
File: how-to-run-website-locally.md

title: "How to run the website locally" linkTitle: "How to run the website locally" weight: 3 slug: how-to-run-the-website-locally The Cortex documentation is compiled into a website published at . These instructions explain how to run the website locally, in order to have a quick feedback loop while contributing to the documentation or website styling. The following initial setup is required only once: Install (extended version) Look for value of `HUGO_VERSION` in `build-image/Dockerfile`. Install `v14` or above (alternatively via ) Install required Node modules with: ``` cd website && npm install && cd - ``` Install `v1.0.0`: ``` go install github.com/campoy/embedmd@v1.0.0 ``` Run `make BUILDINCONTAINER=false web-build` Once the initial setup is completed, you can run the website with the following command. The local website will run at ```bash make web-serve ``` Whenever you change the content of `docs/` or markdown files in the repository root `/` you should run: ```bash make BUILDINCONTAINER=false web-pre ``` Whenever you change the config file or CLI flags in the Cortex code, you should rebuild the config file reference documentation: ```bash make BUILDINCONTAINER=false doc web-pre ```
Project: Netdata (Observability and Analysis / Observability)
File: zfs_memory_throttle.md

This alert indicates the number of times ZFS had to limit the Adaptive Replacement Cache (ARC) growth in the last 10 minutes. ARC stores the most recently used and most frequently used data in RAM, helping to improve read performance. When ARC growth is throttled, it can impact read performance due to a higher chance of cold hits. Monitor RAM usage: Check your system's RAM usage to determine if there is sufficient memory available for ARC. If other processes are consuming a large amount of RAM, ARC growth may be throttled to free up resources. Increase RAM capacity: If you consistently experience ARC throttling, consider increasing your RAM capacity. This will allow for a larger ARC size, improving read performance and reducing the likelihood of cold hits. Adjust ARC size: If you are using ZFS on Linux, you can adjust the ARC size by modifying the `zfsarcmin` and `zfsarcmax` parameters in the `/etc/modprobe.d/zfs.conf` file. On FreeBSD, you can adjust the `vfs.zfs.arc_max` sysctl parameter. Make sure to set these values according to your system's RAM capacity and workload requirements. Evaluate workload: Analyze your system's workload to identify if there are any specific processes or applications that are causing high memory usage, leading to ARC throttling. Optimize or limit these processes if necessary.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: example-demo-app.md

title: Example setups description: This page provides setup examples of how Tempo can be configured for a sample environment. aliases: /docs/tempo/latest/getting-started/quickstart-tempo/ /docs/tempo/latest/guides/loki-derived-fields/ weight: 300 The following examples show various deployment and configuration options using trace generators so you can get started experimenting with Tempo without an existing application. For more information about Tempo setup and configuration, see: If you are interested in instrumentation, see . The are simpler and designed to show minimal configuration. Some of the examples include: Trace discovery with Loki Basic Grafana Agent/OpenTelemetry Setup Various Backends (S3/GCS/Azure) This is a great place to get started with Tempo and learn about various trace discovery flows. The Helm shows a complete microservice based deployment. There are monolithic mode and microservices examples. To install Tempo on Kubernetes, use the procedure. To view an example of a complete microservice-based deployment, this shows a complete microservice based deployment. There are monolithic mode and microservices examples. To learn how to set up a Tempo cluster, see . The provides a self-contained environment for learning about Mimir, Loki, Tempo, and Grafana. It includes detailed explanations of each compononent, annotated configurations for each component. The README.md file has full details on how to quickly download and , including instructions for using Grafana Cloud and the OpenTelemetry Agent.
Project: M3 (Observability and Analysis / Observability)
File: COMPATIBILITY.md

This document describes versioning compatibility guarantees. Any compatibility outlined here will be maintained for at least the current major version. Additional guarantees may be added within the same major version, but existing guarantees may only be modified or removed as part of a major version change. If you discover a breaking change, please . As of version 1.0, m3db/m3 and its components are guaranteed to have binary, configuration, wire, and transport API compatibility: | Compatibility | Scope | Guarantee | | : | :- | :-- | | binary | All released executable components. | All executable components will maintain their current functionality. Components may have additional functionality added, but no existing functionality will be changed or removed. | | configuration | All configuration serialization for binary components. | All configuration will maintain serialization compatibility. New configuration properties may be added, but existing properties will not be renamed, removed, re-typed, or changed semantically or behaviorally. | | wire | All on-the-wire encoding for data to/from binary components. | All wire encoding (e.g. Protobuf, Thrift) will maintain wire compatibility. Any changes to IDLs or other encodings will be backwards-compatible. | | transport API | All exposed transport APIs for communication to/from binary components. | All transport APIs (e.g. m3msg, Thrift, HTTP+JSON) will maintain their current surface area, definitions, semantics, and behavior. Any changes to APIs will be additive or done semantically and with wire compatibility. | This version does not guarantee library-level compatibility. Users are not encouraged to integrate libraries from m3db/m3 directly: use at your own risk.
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_puback_unexpected.md

This alert is related to VerneMQ, a high-performance MQTT broker. It monitors the number of unexpected v3/v5 PUBACK packets received in the last minute. If you receive this alert, it means that there are more PUBACK packets received than expected, which could indicate an issue with your MQTT broker or your MQTT client application(s). In MQTT (Message Queuing Telemetry Transport) protocol, PUBACK packets are acknowledgement packets sent by the MQTT broker to confirm the receipt of a PUBLISH message with QoS (Quality of Service) level 1. The MQTT client will wait for this acknowledgment packet before it can continue with the next transaction. Check VerneMQ logs for any unusual events, errors, or issues that could be related to the PUBACK packets. The VerneMQ logs can be found in `/var/log/vernemq` by default, or any custom location defined in the configuration file. ``` sudo tail -f /var/log/vernemq/console.log ``` Investigate your MQTT client application(s) to ensure they are handling the PUBLISH messages correctly and not causing duplicate or unexpected PUBACK packets. You can use an MQTT client library that supports QoS level 1 to eliminate the possibility of custom code not following the MQTT protocol properly. Monitor your MQTT broker and client application(s) for any network connectivity issues that could cause unexpected PUBACK packets. You can use tools like `ping` and `traceroute` to check the network connectivity between the MQTT broker and client application(s). Analyze the load and performance of your MQTT broker using the various metrics provided by VerneMQ. You can access the VerneMQ status and metrics using the `vmq-admin` command: ``` sudo vmq-admin metrics show ``` Look for any unusual spikes or bottlenecks that could cause unexpected PUBACK packets in the output. If none of the above steps resolve the issue, consider reaching out to the VerneMQ community or opening a GitHub issue to seek further assistance.
Project: Grafana (Observability and Analysis / Observability)
File: panel-links-intro.md

labels: products: enterprise oss title: Panel links intro Each panel can have its own set of links that are shown in top left of a panel after the panel title. You can link to any available URL, including dashboards, panels, or external sites. You can even control the time range to ensure the user is zoomed in on the right data in Grafana.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: span-metrics.md

title: Generate metrics from spans menuTitle: Generate metrics from spans description: Span metrics allow you to generate metrics from your tracing data automatically. weight: aliases: /docs/tempo/grafana-agent/span-metrics Span metrics allow you to generate metrics from your tracing data automatically. Span metrics aggregates request, error and duration (RED) metrics from span data. Metrics are exported in Prometheus format. There are two options available for exporting metrics: using remote write to a Prometheus compatible backend or serving the metrics locally and scraping them. Span metrics generate two metrics: a counter that computes requests, and a histogram that computes operations durations. Span metrics are of particular interest if your system is not monitored with metrics, but it has distributed tracing implemented. You get out-of-the-box metrics from your tracing pipeline. Even if you already have metrics, span metrics can provide in-depth monitoring of your system. The generated metrics show application-level insight into your monitoring, as far as tracing gets propagated through your applications. Span metrics are also used in the service graph view. For more information, refer to the . The same span metrics can also be generated by Tempo. This is more efficient and recommended for larger installations. For a deep look into span metrics, visit . <p align="center"><img src="../../../metrics-generator/span-metrics-example.png" alt="Span metrics overview"></p>
Project: Teletrace (Observability and Analysis / Observability)
File: distributed-tracing.md

Distributed tracing is a technique used in software systems to trace requests as they flow through multiple services or components of a distributed application. It is used to diagnose and debug complex issues that may arise in distributed systems, where a request can travel through multiple services before it is fulfilled. In a distributed tracing system, a unique identifier, called a trace ID, is assigned to each request as it enters the system. As the request flows through different services, each service creates a span, which is a record of the time spent processing that request. Each span is associated with the trace ID, allowing the tracing system to reconstruct the entire request path through the system. <figure markdown> {width="600"} <figcaption>example trace</figcaption> </figure> Spans are created by instrumentation libraries that are included in the application. A span represents a single operation within a trace, it contains a start and end time, a unique identifier, the name of the operation, and any relevant in its Attributes, for example: | Attribute Name | Attribute Value | | - | | | `db.system` | redis | | `db.redis.database_index` | 0 | | `db.redis.flags` | DemandMaster | | `db.statement` | HMSET ef00fdce-ef3c-11ed-a06a-fa7627f72bbb |
Project: Grafana (Observability and Analysis / Observability)
File: pager-duty.md

aliases: ../../../alerting-rules/manage-contact-points/integrations/pager-duty/ # /docs/grafana/<GRAFANA_VERSION>/alerting/alerting-rules/manage-contact-points/integrations/pager-duty/ canonical: https://grafana.com/docs/grafana/latest/alerting/configure-notifications/manage-contact-points/integrations/pager-duty/ description: Configure the PagerDuty integration for Alerting keywords: grafana alerting pagerduty labels: products: cloud enterprise oss menuTitle: PagerDuty title: Configure PagerDuty for Alerting weight: 400 Use the Grafana Alerting - PagerDuty integration to receive notifications in PagerDuty when your alerts are firing. To set up PagerDuty for integration with Grafana Alerting, you need to create a account. There are several set up steps to perform within PagerDuty before you set up the integration in Grafana Alerting. In PagerDuty, a service represents a component, microservice, or infrastructure element that a team oversees, manages, and monitors. Refer to . Follow steps 1 to 5 under Create a Service. {{< admonition type="note" >}} In step 5, choose Create a service without an integration. {{< /admonition >}} Once the service is created, click Integrations within the Service options. Click + Add an integration. Select Events API V2. Click Add. Click the drop-down arrow to display the integration details. Copy the Integration Key. To create your PagerDuty 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 PagerDuty. In the Integration Key field, copy in your integration key. Click Test to check that your integration works. An incident should display in the Services Activity tab in PagerDuty. 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. {{< admonition type="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 PagerDuty. {{< /admonition >}}