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

This alert indicates that your domain name registration is close to its expiration date. It will trigger a warning when there are less than 90 days remaining and a critical alert when there are less than 30 days remaining. If you do not renew the domain registration, it will be deactivated, and you might lose ownership of the domain. Domain names are registered for a limited period, usually between 1 and 10 years. When the registration period comes to an end, you need to renew it if you want to continue using the domain. If you fail to renew the domain, it will become inactive, and after a certain period (known as the grace period), it will be available for anyone else to register. This might result in losing access to your website and email services associated with the domain. Verify domain expiration date: To verify the current expiration date of your domain, you can conduct a WHOIS search by visiting whois.icann.org. This will provide you with details about your domain, including the registrar information, registration date, and expiration date. Contact your domain registrar: If you want to renew your domain, contact your domain registrar (or reseller) as soon as possible to discuss the renewal options available to you. You can find the contact information for your domain registrar in the WHOIS search results. Renew your domain: Once you have contacted your domain registrar, follow their instructions to renew your domain. It's a good idea to renew it for a longer period to avoid the risk of domain expiration in the near future. Review domain auto-renewal settings: Many registrars offer an auto-renewal option, which can help you avoid domain expiration by automatically renewing the domain before it expires. Make sure to review your account settings and enable auto-renewal if you wish to take advantage of this feature. Monitor the domain renewal process: After renewing your domain, verify that the updated expiration date is reflected in the WHOIS search results. Keep an eye on this to ensure that the renewal process has been completed successfully.
Project: Vector (Observability and Analysis / Observability)
File: 2022-03-31-native-event-codecs.md

date: "2022-04-25" title: "New `native` and `native_json` codecs" description: "" authors: ["lukesteensen"] pr_numbers: [] release: "0.22.0" hideonrelease_notes: false badges: type: "announcement" We have added new experimental `native` and `native_json` codecs that allow users to provide Vector with data directly in its native format. This allows simpler, more efficient configuration of some often-requested use cases. Generic event sources like the `http` source or `exec` source can now directly receive metrics rather than needing to pass them through a `logtometric` transform. For example, an `exec` source can now be configured to receive events via the `native_json` codec: ```toml [sources.in] type = "exec" mode = "scheduled" command = ["./scrape.sh"] decoding.codec = "native_json" ``` If `scrape.sh` contained: ```bash echo $RANDOM | jq --raw-input --compact-output \ '{ metric: { name: "my_metric", counter: { value: .|tonumber }, kind: "incremental", } }' ``` Vector would read in counters with random values. Logs are just simple JSON objects, but it is typical to include a `message` and a `timestamp` key like: ```json { "log": { "message": "hello world", "timestamp": "2019-10-12T07:20:50.52Z" } } ``` The specific JSON schema here is subject to change, but you can find an initial schema . The protobuf schema for the `native` codec is the same used in the `vector` source and sink, and the definition can be found . We will be providing more thorough guidance for using each as the feature matures. One current limitation of the JSON-based native codec is that timestamp fields within log messages will be converted to strings. This is partially due to limitations with JSON itself, but we are exploring workarounds. Another example use case is Vector-to-Vector communication via a transport other than our existing gRPC-based `vector` source and sink. Using the `native` encoding on a source/sink pair like `kafka` will utilize the same Protocol Buffers-based encoding scheme, providing compact binary messages that deserialize directly to the same native representation within Vector. Example source configuration: ```toml [sources.in] type = "kafka" bootstrap_servers = "localhost:9092" topics = ["vector"] decoding.codec = "native" ``` This would allow an instance of Vector to receive events from another Vector instance that has a `kafka` sink configured like: ```toml [sinks.out] type = "kafka" inputs = ["..."] bootstrap_servers = "localhost:9092" topic = "vector" encoding.codec = "native" ``` Note that the new `native` encoding option is not yet documented on sinks as we are waiting until it is fully rolled out to document and announce the feature; however, is available on `kafka` and some other sinks.
Project: Promscale (Observability and Analysis / Observability)
File: dataset.md

Promscale stores some configuration information in the Postgres database which it is connected to. We call this configuration the Promscale dataset configuration. Promscale accepts an option to set the dataset values. This document describes its format and mechanics. Setup is done via the `config.yaml` under `startup.dataset`: ```yaml startup: dataset: metrics: defaultchunkinterval: 6h compress_data: true haleaserefresh: 10s haleasetimeout: 1m defaultretentionperiod: 90d traces: defaultretentionperiod: 30d ``` Note: Any configuration omitted from the configuration structure will be set to its default value. | Section | Setting | Type | Default | Description | |:--|:-|:--:|:-:|:-| | metrics | defaultchunkinterval | duration | 8h | Chunk interval used to create hypertable chunks that store the metric data | | metrics | compress_data | bool | true | Boolean setting to turn on or off compression of metric data | | metrics | haleaserefresh | duration | 10s | High availability lease refresh duration, period after which the lease will be refreshed | | metrics | haleasetimeout | duration | 1m | High availability lease timeout duration, period after which the lease will be lost in case it wasn't refreshed | | metrics | defaultretentionperiod | duration | 90d | Retention period for metric data, all data older than this period will be dropped | | traces | defaultretentionperiod | duration | 90d | Retention period for tracing data, all data older than this period will be dropped | The flag `startup.dataset.config` accepts the string representation of YAML. This was so that it could be used not only in the config file, but also as a command line flag or environment variable. In a config file: ```yaml startup.dataset.config: | metrics: defaultchunkinterval: 8h ``` Or as a command line flag: ```bash ./promscale -startup.dataset.config="metrics:\n defaultchunkinterval: 8h" ``` Or as an environment variable ```bash PROMSCALESTARTUPDATASETCONFIG="metrics:\n defaultchunk_interval: 8h" ./promscale ``` Using a string has some implications, specially for validation in a Kubernetes environment. In a future release of Promscale, `statup.dataset.config` will be deprecated in favor of `startup.dataset` which is a YAML mapping node, instead of a string, that can only be set using the config file: Old to be deprecated Config: ```yaml startup.dataset.config: | metrics: defaultchunkinterval: 8h ``` Recommended dataset config as YAML mapping ``` startup: dataset: metrics: defaultchunkinterval: 8h ```
Project: Vector (Observability and Analysis / Observability)
File: 2021-08-24-vector-source-sink.md

date: "2021-08-20" title: "Version 2 of the Vector source/sink released" description: "" authors: ["JeanMertz"] pr_numbers: [] release: "0.16.0" hideonrelease_notes: false badges: type: "announcement" We've released a new major version (`v2`) of our `vector` / components. This release resolves several issues and limitations we experienced with our previous (`v1`) TCP-based implementation of these two components: `vector` sink does not work in k8s with dynamic IP addresses () Allow for HTTP in the vector source and sinks () Allow Vector Source and Sink to Communicate over GRPC () RFC 5843 - Encoding/Decoding for Vector to Vector Communication () The new version transitions to using gRPC over HTTP as its communication protocol, which resolves those limitations. To allow operators to transition at their leisure, this new release of Vector still defaults to `v1`. In `0.20.0` we'll require operators to explicitly state which version they want to use, but continue to support `v1`. In `0.22.0` we'll drop `v1` completely, and default to `v2`. We will also no longer require you to explicitly set the version since there will only be one supported going forward. If you want to opt in to the new (stable!) `v2` version, you can do so as follows: ```diff [sinks.vector] type = "vector" version = "2" [sources.vector] type = "vector" version = "2" ``` There are a couple of things to be aware of: There are some configuration options that are no longer valid with version 2 of the source and sink: `vector` source: `keepalive` and `receivebufferbytes` `vector` sink: `keepalive` and `sendbufferbytes` As these were specific to the TCP-based version 1 of the protocol. You have to upgrade both the source and sink to `v2`, or none at all, you cannot update one without updating the other. Doing so will result in a loss of events. If you want to do a zero-downtime upgrade to `v2`, you'll have to introduce the new source/sink versions next to the existing versions, before removing the existing one. First, deploy the configuration that defines the source: ```diff [sources.vector] address = "0.0.0.0:9000" type = "vector" version = "1" [sources.vector] address = "0.0.0.0:5000" type = "vector" version = "2" ``` Then, deploy the sink configuration, switching it over to the new version: ```diff [sinks.vector] address = "127.0.1.2:9000" address = "127.0.1.2:5000" type = "vector" version = "2" ``` Once the sink is deployed, you can do another deploy of the source, removing the old version: ```diff [sources.vector] address = "0.0.0.0:9000" type = "vector" version = "1" [sources.vector] address = "0.0.0.0:5000" type = "vector" version = "2" ``` That's it! You are now using the new transport protocol for Vector-to-Vector communication.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-7-4-5.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 7.4.5 <!-- Auto generated by update changelog github action --> Security: Fix API permissions issues related to team-sync CVE-2021-28146, CVE-2021-28147. (Enterprise) Security: Usage insights requires signed in users CVE-2021-28148. (Enterprise) Security: Do not allow editors to incorrectly bypass permissions on the default data source. CVE-2021-27962. (Enterprise)
Project: Grafana Mimir (Observability and Analysis / Observability)
File: configure-tsdb-block-upload.md

aliases: ../operators-guide/configure/configure-tsdb-block-upload/ description: Learn how to configure Grafana Mimir to enable TSDB block upload menuTitle: TSDB block upload title: Configure TSDB block upload weight: 120 Grafana Mimir supports uploading of historic TSDB blocks, sourced from Prometheus, Cortex, or even other Grafana Mimir installations. Upload from Thanos is currently not supported; for more information, see . To make performing block upload simple, we've built support for it into Mimir's CLI tool, . For more information, see . Block upload is still considered experimental and is therefore disabled by default. You can enable it via the `-compactor.block-upload-enabled` CLI flag, or via the corresponding `limits.compactorblockupload_enabled` configuration parameter: ```yaml limits: compactorblockupload_enabled: true ``` If your Grafana Mimir has multi-tenancy enabled, you can still use the preceding method to enable TSDB block upload for all tenants. If instead you wish to enable it per tenant, you can use the runtime configuration to set a per-tenant override: Enable . Add an override for the tenant that should have TSDB block upload enabled: ```yaml overrides: tenant1: compactorblockupload_enabled: true ``` Because Thanos blocks contain unsupported labels among their metadata, they cannot be uploaded. For information about limitations that relate to importing blocks from Thanos as well as existing workarounds, see . Grafana Mimir does not validate that the uploaded blocks are well-formed. This means that users could upload malformed blocks to Grafana Mimir. These malformed blocks could potentially cause problems on the Mimir query path or for the operation of Mimir's compactor component. We intend to add validation of uploaded blocks in a future release, which would allow us to identify and reject malformed blocks at upload time and prevent any downstream impact to Grafana Mimir. After uploading one or more blocks, the results-cache needs flushing. The reason is that Grafana Mimir caches query results for queries that dont touch the most recent 10 minutes of data. After uploading blocks however, queries may return different results (because new data was uploaded). Therefore cached results may be wrong, meaning the cache should manually be flushed after uploading blocks. When queriers receive a query for a given [start, end] period, they consult this period to decide whether to read data from storage, ingesters, or both. Say `-querier.query-store-after` is set to `12h`. It means that a query `[now-13h, now]` will read data from storage. But a query `[now-5h, now]` will not. If a user uploads blocks that are too new, the querier may not query them, because it is configured to only query ingesters for fresh time ranges.
Project: Kubecost (Observability and Analysis / Continuous Optimization)
File: opencost-feature-request.md

name: OpenCost Feature request about: Suggest an idea for this project title: '' labels: '' assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context, documentation links, or screenshots about the feature request here.
Project: Loggie (Observability and Analysis / Observability)
File: README.md

](https://pkg.go.dev/sigs.k8s.io/json) This library is a subproject of . It provides case-sensitive, integer-preserving JSON unmarshaling functions based on `encoding/json` `Unmarshal()`. The `UnmarshalCaseSensitivePreserveInts()` function behaves like `encoding/json#Unmarshal()` with the following differences: JSON object keys are treated case-sensitively. Object keys must exactly match json tag names (for tagged struct fields) or struct field names (for untagged struct fields). JSON integers are unmarshaled into `interface{}` fields as an `int64` instead of a `float64` when possible, falling back to `float64` on any parse or overflow error. Syntax errors do not return an `encoding/json` `*SyntaxError` error. Instead, they return an error which can be passed to `SyntaxErrorOffset()` to obtain an offset. The `UnmarshalStrict()` function decodes identically to `UnmarshalCaseSensitivePreserveInts()`, and also returns non-fatal strict errors encountered while decoding: Duplicate fields encountered Unknown fields encountered You can reach the maintainers of this project via the . Participation in the Kubernetes community is governed by the . me.Millisecond) doSomethingElse(ctx) } ```
Project: Netdata (Observability and Analysis / Observability)
File: outbound_packets_dropped_ratio.md

When we want to investigate the outbound traffic, the journey of a network packet starts at the application layer. Data are written (commonly) to a socket by a user program. The programmer may (raw sockets) or may not (datagram and stream sockets) have the possibility of absolute control over the data which is being sent through the network. The kernel will take the data which is written in a socket queue and allocate the necessary socket buffers. The kernel will try to forward the packets to their destination encapsulating the routing metadata (headers, checksums, fragmentation information) for each packet through a network interface. The Netdata Agent calculates the ratio of outbound dropped packets for a specific network interface over the last 10 minutes. Receiving this alarm means that packets were dropped on their way to transmission. This alert is triggered in warning state when the ratio of outbound dropped packets for a specific network interface over the last 10 minutes is more than 2%. The main reasons of outbound packet drops are: Link congestion Overburdened devices Defective hardware Faulty network configuration Restricted access from firewall rules Inspect the packets your network interface sends using Wireshark. Wireshark is a free and open-source packet analyzer. It is used for network troubleshooting, analysis, software and communications protocol development.
Project: Netdata (Observability and Analysis / Observability)
File: x509check_revocation_status.md

This alert indicates that the X.509 certificate has been revoked, meaning that it is no longer valid or trusted. The certificate can be revoked for various reasons, such as key compromise, errors within the certificate, change of usage, or the certificate owner no longer being deemed trustworthy. Identify the affected certificate: The alert should provide information about the affected X.509 certificate. Take note of the certificate's details, such as the domain name, subject, issuer, and serial number. Verify the revocation status: You can use the `openssl` command to verify the revocation status of the affected certificate. Use the following command to check the certificate against the Certificate Revocation List (CRL) provided by the CA: ``` openssl verify -crlcheck -CAfile CAcertificate.pem -CRLfile CRL.pem certificate.pem ``` Replace `CA_certificate.pem`, `CRL.pem`, and `certificate.pem` with the appropriate file names of the CA certificate, CRL file, and the target X.509 certificate. Alternatively, you can use online tools such as to verify the revocation status. Be sure to input the domain and port associated with the revoked certificate. Remove or replace the revoked certificate: If you have confirmed that the certificate is indeed revoked, you should stop using it immediately. Remove the revoked certificate from your server or application, and replace it with a valid one. If the certificate was issued by a commercial CA, you can request a new certificate from the CA. The CA might provide you with a free replacement or require you to purchase a new one. If the certificate was issued by , you can renew the certificate using or another ACME client. If the certificate was self-signed, you can create a new self-signed certificate using the `openssl` command or another certificate management tool. Update server or application configuration: After obtaining a new certificate, update your server or application configuration to use the new certificate. Make sure to restart the server or application for the changes to take effect. Monitor the new certificate: Keep an eye on the new certificate's status using the X.509 monitoring tools provided by Netdata. Regularly check for any new alerts or changes in the certificate's status.
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: tcpretrans.md

title: 'Using trace tcpretrans' weight: 20 description: > Trace TCP retransmissions. The trace tcpretrans gadget traces TCP retransmissions by the kernel. In terminal 1, start the trace tcpretrans gadget: ```bash $ kubectl gadget trace tcpretrans K8S.NODE K8S.NAMESP K8S.POD K8S.CONTAI PID COMM IP SRC DST STATE TCPFLA TYPE ``` In terminal 2, start a pod and configure the network emulator to drop 25% of the packets. This will cause TCP retransmissions: ```bash $ kubectl create service nodeport nginx --tcp=80:80 $ kubectl create deployment nginx --image=nginx $ kubectl run --rm -ti --privileged --image ubuntu shell -- bash root@shell:/# apt-get update root@shell:/# apt install -y iproute2 curl root@shell:/# tc qdisc add dev eth0 root netem drop 25% root@shell:/# curl nginx ``` The results in terminal 1 will show that some TCP transmissions cause by the dropped packets: ``` K8S.NODE K8S.NAMESP K8S.POD K8S.CONTAI PID COMM IP SRC DST STATE TCPFLA TYPE minikuocker default shell shell 60274 curl 4 p/default/shell:46022 s/default/nginx:80 ESTABLIS LOSS minikuocker default shell shell 60274 curl 4 p/default/shell:46022 s/default/nginx:80 ESTABLIS PSH|ACK RETRANS ``` In terminal 1, start the trace tcpretrans gadget: ```bash $ sudo ig trace tcpretrans -r docker -c netem CONTAINER PID COMM IP SRC DST STATE TCPFLAGS ``` In terminal 2, start a container, configure the network emulator to drop 25% of the packets, and download a web page: ```bash $ docker run -ti --rm --cap-add NET_ADMIN --name=netem wbitt/network-multitool -- /bin/bash ``` The container needs NET_ADMIN capability to manage network interfaces The results in terminal 1 will show some TCP transmissions caused by the dropped packets: ``` RUNTIME.CONTAINERNAME PID COMM IP SRC DST STATE TCPFLAGS TYPE netem 21686 wget 4 10.10.0.3:46326 1.1.1.1:80 SYN_SENT SYN RETRANS netem 21686 wget 4 10.10.0.3:46326 1.1.1.1:80 ESTABLISHED LOSS ```
Project: Elastic (Observability and Analysis / Observability)
File: to_ip.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Converts an input string to an IP value. ``` ROW str1 = "1.1.1.1", str2 = "foo" | EVAL ip1 = TOIP(str1), ip2 = TOIP(str2) | WHERE CIDR_MATCH(ip1, "1.0.0.0/8") ```
Project: Netdata (Observability and Analysis / Observability)
File: web_log_1m_successful.md

HTTP response status codes indicate whether a specific HTTP request has been successfully completed or not. The Netdata Agent calculates the ratio of successful HTTP requests over the last minute. These requests consist of 1xx, 2xx, 304, 401 response codes. You receive this alert in warning when the percentage of successful requests is less than 85% and in critical when it is below 75%. This alert can indicate: A malfunction in the services of your web server Malicious activity towards your website Broken links towards your servers. In most cases, Netdata will send you another alert indicating high incidences of "abnormal" HTTP requests code, for example you could also receive the `weblog1mbadrequests` alert. There are a number of reasons triggering this alert. All of them could eventually cause bad user experience with your web services. Identify exactly what HTTP response code your web server sent back to your clients. Open the Netdata dashboard and inspect the `detailedresponsecodes` chart for your web server. This chart keeps track of exactly what error codes your web server sends out.
Project: Trickster (Observability and Analysis / Observability)
File: prometheus.md

Trickster fully supports accelerating Prometheus, which we consider our First Class backend provider. They work great together, so you should give it a try! Most configuration options that affect Prometheus reside in the main Backend config, since they generally apply to all TSDB providers alike. We offer one custom configuration for Prometheus, which is the ability to inject labels, on a per-backend basis to the Prometheus response before it is returned to the caller. Here is the basic configuration for adding labels: ```yaml backends: prom-1a: provider: prometheus origin_url: http://prometheus-us-east-1a:9090 prometheus: labels: datacenter: us-east-1a prom-1b: provider: prometheus origin_url: http://prometheus-us-east-1b:9090 prometheus: labels: datacenter: us-east-1b ```