cwielenb/CNCF-Dataset huggingface dataset:
Project: Grafana Mimir (Observability and Analysis / Observability)
File: migrate-helm-chart-4.x-to-5.0.md

description: "Migrate the Helm chart from version 4.x to 5.0" title: "Migrate the Helm chart from version 4.x to 5.0" menuTitle: "Migrate Helm chart 4.x to 5.0" weight: 110 The `mimir-distributed` Helm chart version 5.0 and later does not install objects on Kubernetes version 1.24 by default to prepare for upgrade to Kubernetes version 1.25. This procedure is only applicable if `rbac.create` is `true` and `rbac.type` is `psp` in your current Helm values. This was the case by default before Helm chart version 5.0. If `rbac.create` is `false` or `rbac.type` is `scc`, then there is nothing to do, skip the whole procedure. Choose between the following options: If you are on Kubernetes version 1.22 or later and already have set up, you don't need to do anything and can upgrade to Helm chart version 5.0. If you are on Kubernetes version 1.22 or later but don't have set up and want to upgrade to Kubernetes version 1.25 after this procedure, then follow the guide. If you are on Kubernetes version 1.24 and want to keep using PodSecurityPolicy, then merge the following setting into your custom values file: ```yaml rbac: forcePSPOnKubernetes124: true ``` {{% admonition type="warning" %}} Using `rbac.forcePSPOnKubernetes124` equal `true` value prevents you from upgrading to Kubernetes version 1.25. {{% /admonition %}}
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: flag-lifecycle.md

title: Feature Flags Lifecycles Feature Flags generally have two lifecycles: Short-Lived Flags Long-Lived Flags Lets go over each type in detail. Short-lived flags are designed to be removed from your code and from Flagsmith at some point in the future. Their typical lifecycle is normally something like: Create flag in Flagsmith. Add the flag to your application code. Toggle the flag and/or apply Segment overrides to control your application behaviour. Once you are finished with the flag, remove the flag from your codebase. Deploy your application, so that there is no reference to the flag. Remove the flag from Flagsmith. Short lived flags are typically used for the following use-cases: The most common use of flags in general is to decouple the deployment of a feature from it's release. When using a flag to achieve this, you will generally remove the flag from your code and from Flagsmith once you are happy with the feature and it is rolled out to your entire user population. Once this is the case, there is no reason to have the flag exist either in Flagsmith or your code, hence it is considered good practise to remove it from both. You can use Multi-variate flags to drive . Once your experiment is complete, there is typically no need for the flag to remain, and hence it can be removed. Conversely, sometimes you will create flags that are long-lived - quite possibly for the lifetime of the application. Here are a few use cases where this approach can be used. There are often times where you need to be able remotely remove a feature, area of your application or sometimes the application as a whole (in the event of a large deployment, for example). In these instances, flags can be used as 'kill switches' to remove a feature altogether, or maybe to prevent users from using the application in the event of downtime. Kill switches are generally long-lived; they often exist in the event of an unexpected event or error, and so they need to be long-lived in case they need to be put to use. You can make use of and Flags to control how different features are enabled or disabled depending on the user. For example, you can send a Trait `plan` with the relevant user value (e.g. `scale-up`) to Flagsmith, then create a Segment that defines all users on the `scale-up` plan. You can then show or hide features based on this Segment and plan. When employing feature flags in this manner, generally you would never remove this Flag or Segment, as you are using them to drive platform features for the lifetime of the application.
Project: Netdata (Observability and Analysis / Observability)
File: httpcheck_web_service_bad_content.md

The Netdata Agent monitors your HTTP endpoints. You can specify endpoints that the agent will monitor in Agent's Go module under `go.d/httpcheck.conf`. You can also specify the expected response pattern. This HTTP endpoint will send in the `responsematch` option. If the endpoint's response does not match the `responsematch` pattern, then the Agent marks the response as unexpected. The Netdata Agent calculates the average ratio of HTTP responses with unexpected content over the last 5 minutes. This alert is escalated to warning if the percentage of unexpected content is greater than 10% and then raised to critical if it is greater than 40%. Check the actual response and the expected response. Try to implement a request with a verbose result: ``` curl -v <yourhttpendpoint>:<port>/<path> ``` Compare it with the expected response. Check your configuration under `go.d/httpcheck.conf`: ``` cd /etc/netdata # Replace this path with your Netdata config directory sudo ./edit-config go.d/httpcheck.conf ```
Project: M3 (Observability and Analysis / Observability)
File: headers_optional_read_all.md

`M3-Restrict-By-Tags-JSON`: If this header is set it can ensure specific label matching is performed as part of every query including series metadata endpoints. As an example, the following header would unconditionally cause `globaltag=somevalue` to be a part of all queries issued regardless of if they include the label or not in a query and also strip the "globaltag" from appearing as a label in any of the resulting timeseries: ``` M3-Restrict-By-Tags-JSON: '{"match":[{"name":"globaltag","type":"EQUAL","value":"somevalue"}],"strip":["globaltag"]}' ``` {{% fileinclude file="headersoptionalread_limits.md" %}}
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: btfgen.md

title: 'btfgen' weight: 100 description: 'Using btfgen to enable the gadget in systems without BTF' enables running gadgets on system that don't provide BTF information. The `ig image build` command generates a new layer on the gadget image with the BTF information of the types used by the gadget for the most common kernels available in , this information is then used when running the gadget if the kernel doesn't have BTF enabled. Given that generating the BTF information for a gadget takes a while, this support is disabled by default. The repository needs to be present on the machine: ```bash $ git clone --depth 1 https://github.com/aquasecurity/btfhub-archive/ $HOME/btfhub-archive/ ``` Then, pass the `--btfgen` and the path of the btfhub-archive repository to the build command: ```bash $ sudo -E ig image build . --btfgen --btfhub-archive $HOME/btfhub-archive -t myimage ``` The resulting image will contain the BTF information and can be pushed, run or tagged as any other gadget image.
Project: Promscale (Observability and Analysis / Observability)
File: prometheus_api.md

The defines endpoints for executing PromQL expression queries (instant and range), query metadata about the series and labels, retrieve information about alerts, targets and the complete configuration of the prometheus server. We implemented the endpoints for executing PromQL and labels metadata to allow the Promscale connector to be used as a Prometheus compatible data-source in applications like Grafana. <img src="assets/promscale-arch.png" alt="Promscale Architecture Diagram" width="800"/> When requesting a query to run on data that is in the long-term storage through Prometheus, the query goes through the following steps. The user issues a query to the prometheus server Query engine requests the data through the remote_read protocol; The connector translates the request to SQL statement with only a time range and label matchers applied; The database returns almost raw data; The connector marshals it into a format compatible with the remote_read protocol; The Query engine combines the local and remote data and applies any functions or aggregations before returning a result. By having the Connector implement the PromQL APIs, the connector can: The user issues a query directly to the connector Parse the PromQL and translate it to a SQL statement that with a time range, label matchers, calculations and aggregates to be pushed down; The database executes the query; A slightly modified Prometheus Query Engine (to leverage more pushdowns) finalizes the calculation and marshals the data to a proper response. By using the Connector for PromQL queries directly a network trip is avoided, and TimescaleDB is better utilized to actually perform some calculations. | Name | Endpoint | Description | |||| | | `GET,POST /api/v1/query` | Evaluate an instant query at a single point in time | | | `GET,POST /api/v1/query_range` | Evaluate an expression query over a range of time | | | `GET,POST /api/v1/series` | Return a list of time series that match a label set | | | `GET,POST /api/v1/labels` | Return a list of label names | | | `GET /api/v1/label/<label_name>/values` | Return a list of label values for a provided label name | | | `PUT,POST /api/v1/admin/tsdb/deleteseries` | Deletes sets whose labelset matches the provided matchers | | | `GET,POST /api/v1/query_exemplars` | (Experimental) Evaluate an expression query for Exemplars |
Project: Netdata (Observability and Analysis / Observability)
File: haproxy_backend_status.md

This alert monitors the average number of failed HAProxy backends over the last 10 seconds. If you receive this alert in a critical state, it means that one or more HAProxy backends are inaccessible or offline. HAProxy is a reverse-proxy that provides high availability, load balancing, and proxying for TCP and HTTP-based applications. A backend in HAProxy is a set of servers that receive forwarded requests and are defined in the backend section of the configuration. Check the HAProxy configuration file for errors Making changes in the configuration file may introduce errors. Always validate the correctness of the configuration file. In most Linux distros, you can run the following check: ``` haproxy -c -f /etc/haproxy/haproxy.cfg ``` Check the HAProxy service for errors Use `journalctl` and inspect the log: ``` journalctl -u haproxy.service --reverse ``` Check the HAProxy log By default, HAProxy logs under `/var/log/haproxy.log`: ``` cat /var/log/haproxy.log | grep 'emerg\|alert\|crit\|err\|warning\|notice' ``` You can also search for log messages with `info` and `debug` tags. Investigate the backend servers Verify that the backend servers are online and accepting connections. Check the backend server logs for any errors or issues. Ensure that firewall rules or security groups are not blocking traffic from HAProxy to the backend servers. Review the HAProxy load balancing algorithm and configuration Analyze the load balancing algorithm used in the configuration to ensure it is suitable for your setup. Check for any misconfigurations, such as incorrect server addresses, ports, or weights.
Project: Cortex (Observability and Analysis / Observability)
File: ingesters-rolling-updates.md

title: "Ingesters rolling updates" linkTitle: "Ingesters rolling updates" weight: 10 slug: ingesters-rolling-updates Cortex are semi-stateful. A running ingester holds several hours of time series data in memory, before they're flushed to the long-term storage. When an ingester shutdowns, because of a rolling update or maintenance, the in-memory data must not be discarded in order to avoid any data loss. The Cortex requires ingesters to run with a persistent disk where the TSDB WAL and blocks are stored (eg. a StatefulSet when deployed on Kubernetes). During a rolling update, the leaving ingester closes the open TSDBs, synchronize the data to disk (`fsync`) and releases the disk resources. The new ingester, which is expected to reuse the same disk of the leaving one, will replay the TSDB WAL on startup in order to load back in memory the time series that have not been compacted into a block yet.
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: github.md

The following diagram shows the flow of data when fetching source code from GitHub. ```mermaid sequenceDiagram autonumber actor User participant Client participant Pyroscope participant GitHub User->>Client: Select a Flame graph Node Client->>Pyroscope: Request Flame graph Data For Node Pyroscope-->>Client: Flame graph Data Client-->Client: if the data has source code information Client->>Pyroscope: Request Github App client ID Pyroscope-->>Client: Github App client ID Client->>GitHub: Redirect for Authorization of Pyroscope App GitHub-->>Client: Send Authorization Code Client->>Pyroscope: Login to GitHub with Authorization Code Pyroscope->>GitHub: Request Access Token GitHub-->>Pyroscope: Send OAuth token Pyroscope-->>Client: Set OAuth token in cookie User-->>Client: Select a git version Client->>Pyroscope: Request code for given git version, file path and repo Pyroscope->>GitHub: Fetch code GitHub-->>Pyroscope: Send code Pyroscope-->>Client: Send code Client-->>Client: Render code and map line number ``` Pyroscope uses GitHub OAuth App to fetch source code for a given git version, file path and repo. This is done by using the to get an OAuth token for the user. This token is then used to fetch the source code from GitHub. Pyroscope supports a new API to fetch Github App client ID. This API is used to get the client ID for the GitHub OAuth App. This client ID is then used to redirect the user to GitHub to authorize Pyroscope to access the user's GitHub account. Github will redirect the user back to the client with an authorization code. This authorization code is then used to get an OAuth token from GitHub via Pyroscope. The OAuth token is never stored by Pyroscope. It is only stored in the user's browser as a cookie. Only Pyroscope can access this cookie as it is encrypted with a secret key that is only known to Pyroscope. When requesting a file to Pyroscope and it returns a `401 Unauthorized` response, it means that the OAuth token has expired. At the same, time the user's browser will delete the cookie containing the OAuth token. The user will then have to log in again to GitHub to get a new OAuth token.
Project: Grafana (Observability and Analysis / Observability)
File: 3-grafana_ui_component.md

name: '@grafana/ui component request' about: Suggest a component for the @grafana/ui package labels: 'area/grafana/ui' <!-- By using this template you will make it easier for us to make sure that documentation and implementation stays up to date for every component in @grafana/ui Thank you! --> Why is this component needed: <!-- Explain your use case --> _ [ ] Is/could it be used in more than one place in Grafana? Where is/could it be used?: _ [ ] Post screenshots possible. [ ] It has a single use case. [ ] It is/could be used in multiple places. Implementation (Checklist meant for the person implementing the component) [ ] Component has a story in Storybook. . [ ] It is extendable (rest props are spread, styles with className work, and so on). . [ ] Works with both light and dark theme. Documentation [ ] Properties are documented. [ ] Use cases are described. [ ] Code examples for the different use cases. [ ] Dos and don'ts. [ ] Styling guidelines, specific color usage (if applicable).
Project: Grafana Tempo (Observability and Analysis / Observability)
File: CHANGELOG.md

Releases ======== v1.11.0 (2023-03-28) ==================== `Errors` now supports any error that implements multiple-error interface. Add `Every` function to allow checking if all errors in the chain satisfies `errors.Is` against the target error. v1.10.0 (2023-03-08) ==================== Comply with Go 1.20's multiple-error interface. Drop Go 1.18 support. Per the support policy, only Go 1.19 and 1.20 are supported now. Drop all non-test external dependencies. v1.9.0 (2022-12-12) =================== Add `AppendFunc` that allow passsing functions to similar to `AppendInvoke`. Bump up yaml.v3 dependency to 3.0.1. v1.8.0 (2022-02-28) =================== `Combine`: perform zero allocations when there are no errors. v1.7.0 (2021-05-06) =================== Add `AppendInvoke` to append into errors from `defer` blocks. v1.6.0 (2020-09-14) =================== Actually drop library dependency on development-time tooling. v1.5.0 (2020-02-24) =================== Drop library dependency on development-time tooling. v1.4.0 (2019-11-04) =================== Add `AppendInto` function to more ergonomically build errors inside a loop. v1.3.0 (2019-10-29) =================== Switch to Go modules. v1.2.0 (2019-09-26) =================== Support extracting and matching against wrapped errors with `errors.As` and `errors.Is`. v1.1.0 (2017-06-30) =================== Added an `Errors(error) []error` function to extract the underlying list of errors for a multierr error. v1.0.0 (2017-05-31) =================== No changes since v0.2.0. This release is committing to making no breaking changes to the current API in the 1.X series. v0.2.0 (2017-04-11) =================== Repeatedly appending to the same error is now faster due to fewer allocations. v0.1.0 (2017-31-03) =================== Initial release
Project: Netdata (Observability and Analysis / Observability)
File: web_log_5m_successful.md

This alert monitors the average number of successful HTTP requests per second, over the last 5 minutes (`weblog.typerequests`). If you receive this alert, it means that there has been a significant change in the number of successful HTTP requests to your web server. A successful HTTP request is one that receives a response with an HTTP status code in the range of `200-299`. In other words, these requests have been processed correctly by the web server and returned the expected results to the client. Check your web server logs Inspect your web server logs for any abnormal activity or issues that might have led to increased or decreased successful HTTP requests. Depending on your web server (e.g., Apache, Nginx), the location of the logs will vary. Analyze the type of requests Check the logs for request types (e.g., GET, POST, PUT, DELETE) and their corresponding distribution during the time of the alert. This might help you identify a pattern or source of the issue. Monitor web server resources Use monitoring tools like `top`, `htop`, or `glances` to check the resource usage of your web server during the alert period. High resource usage may indicate that your server is struggling to handle the load, causing an abnormal number of successful HTTP requests. Verify client connections Investigate the IP addresses and user agents that are making a significant number of requests during the alert period. If there's a spike in requests from a single or a few IPs, it could be a sign of a coordinated attack, excessive crawling, or other unexpected behavior. Check your web application Make sure that your web application is functioning well and generating the expected response for clients, which can impact successful HTTP requests.
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_pubrec_received_reason_unsuccessful.md

This alert indicates that the number of received unsuccessful v5 `PUBREC` packets in the last minute is higher than expected. VerneMQ is an open-source MQTT broker. MQTT is a lightweight messaging protocol for small sensors and mobile devices optimized for high-latency or unreliable networks. `PUBREC` is an MQTT packet that is part of the quality of service 2 (QoS 2) message flow for MQTT publish/subscribe model. An unsuccessful `PUBREC` could mean that there are issues with the MQTT messages being processed by the MQTT broker. `PUBREC` stands for "Publish Received." In MQTT, it is part of the QoS 2 message flow to ensure end-to-end delivery of a message between clients (publishers) and subscribers connected to an MQTT broker. When a client sends a `PUBLISH` message with QoS 2, the broker acknowledges the receipt with a `PUBREC` message. To address this alert and identify the root cause, follow these steps: Check the VerneMQ log files: Inspect the VerneMQ log files to find any issues or errors related to the processing of MQTT messages. Look for messages related to `PUBREC` or QoS 2 issues. The logs are typically located at `/var/log/vernemq/console.log`or `/var/log/vernemq/error.log`. Monitor the VerneMQ metrics: Check VerneMQ metrics using tools like `vmq-admin` to get insights into the broker's performance and message statistics. The command `vmq-admin metrics show` provides various metrics, including the number of received `PUBREC` and the number of unsuccessful `PUBREC` messages. Verify the publisher's configuration: Check the configuration of the MQTT clients (publishers) that are sending the QoS 2 messages to ensure a proper message flow. It's crucial to confirm that the clients are using the correct version of MQTT and adhere to the limitations set by MQTT v5, like the packet size or the maximum topic aliases used. Identify unsupported features: Some MQTT brokers may not support all MQTT v5 features. Verify that the publisher's MQTT library supports MQTT v5 features in use, such as user properties or message expiration interval, and that it is compatible with VerneMQ. Analyze network conditions: Unreliable network conditions or high traffic load may cause unsuccessful MQTT messages. Evaluate the network and identify any issues causing packet loss or latency. Often, improving the network conditions, migrating the broker/server to a stronger network, or adjusting the user's connection settings can help with such issues.
Project: Beats (Observability and Analysis / Observability)
File: packaging.pipeline.md

is used to build and publish the packages for the Beats. The pipeline is triggered by a commit to the `main` or release branches. The pipeline definition is located in the `.buildkite/packaging.pipeline.yml` Staging packaging DRA is triggered for release branches only. Snapshot is triggered for `main` and release branches. Generates `build/distributions/dependencies.csv` and `tar.gz` and adds them to the `beats-dashboards` artifact. This is required by the release-manager configuration. Builds the Beats packages for all supported platforms and architectures (`mage package, mage ironbank`) Copies artifacts `build/distributions/<beat>/` directory and adds it as an artifact, where `<beat>` is the corresponding beat name. x-pack artifacts are also copied to `build/distributions/<beat>/` directory, where `<beat>` is the name of the beat. For example, `auditbeat`, not `x-pack/auditbeat`. It's required for the DRA publish step by . Downloads the artifacts from the `packaging snapshot/staging` step and publishes them to the Elastic DRA registry.