cwielenb/CNCF-Dataset huggingface dataset:
Project: Grafana Loki (Observability and Analysis / Observability)
File: LICENSE.md

The MIT License (MIT) Copyright (c) 2014 Mitchell Hashimoto Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: dynamic-scheduler-plugin.md

title: "Dynamic-scheduler: a load-aware scheduler plugin" description: "Docs for load-aware scheduler plugin" weight: 12 Native scheduler of kubernetes can only schedule pods by resource request, which can easily cause a series of load uneven problems: for some nodes, the actual load is not much different from the resource request, which will lead to a very high probability of stability problems. for others, the actual load is much smaller than the resource request, which will lead to a huge waste of resources. To solve these problems, Dynamic scheduler builds a simple but efficient model based on actual node utilization dataand filters out those nodes with high load to balance the cluster. As shown above, Dynamic scheduler relies on `Prometheus` and `Node-exporter` to collect and aggregate metrics data, and it consists of two components: !!! note "Note" `Node-annotator` is currently a module of `Crane-scheduler-controller`. `Node-annotator` periodically pulls data from Prometheus and marks them with timestamp on the node in the form of annotations. `Dynamic plugin` reads the load data directly from the node's annotation, filters and scores candidates based on a simple algorithm. Dynamic provides a default and supports user-defined policies. The default policy reies on following metrics: `cpuusageavg_5m` `cpuusagemaxavg1h` `cpuusagemaxavg1d` `memusageavg_5m` `memusagemaxavg1h` `memusagemaxavg1d` At the scheduling `Filter` stage, the node will be filtered if the actual usage rate of this node is greater than the threshold of any of the above metrics. And at the `Score` stage, the final score is the weighted sum of these metrics' values. In the production cluster, scheduling hotspots may occur frequently because the load of the nodes can not increase immediately after the pod is created. Therefore, we define an extra metrics named `Hot Value`, which represents the scheduling frequency of the node in recent times. And the final priority of the node is the final score minus the `Hot Value`.
Project: Checkmk (Observability and Analysis / Observability)
File: 14620.md

key | value | date | 2024-01-30T12:49:59+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes Mails sent by `checkmailloop` had been deprecated only after 24h, which potentially resulted in thousands of mails in circumstances when sent mails could not be processed for whatever reasons. This change lowers this age to 2h resulting in 'only' 120 mails (for this active check being executed every minute).
Project: Grafana Tempo (Observability and Analysis / Observability)
File: CONDUCT.md

Cobra will follow a steady release cadence. Non breaking changes will be released as minor versions quarterly. Patch bug releases are at the discretion of the maintainers. Users can expect security patch fixes to be released within relatively short order of a CVE becoming known. For more information on security patch fixes see the CVE section below. Releases will follow . Users tracking the Master branch should expect unpredictable breaking changes as the project continues to move forward. For stability, it is highly recommended to use a release. We will maintain two major releases in a moving window. The N-1 release will only receive bug fixes and security updates and will be dropped once N+1 is released. Deprecation of Go versions or dependent packages will only occur in major releases. To reduce the change of this taking users by surprise, any large deprecation will be preceded by an announcement in the and an Issue on Github. Maintainers will make every effort to release security patches in the case of a medium to high severity CVE directly impacting the library. The speed in which these patches reach a release is up to the discretion of the maintainers. A low severity CVE may be a lower priority than a high severity one. Cobra maintainers will use GitHub issues and the as the primary means of communication with the community. This is to foster open communication with all users and contributors. Breaking changes are generally allowed in the master branch, as this is the branch used to develop the next release of Cobra. There may be times, however, when master is closed for breaking changes. This is likely to happen as we near the release of a new version. Breaking changes are not allowed in release branches, as these represent minor versions that have already been released. These version have consumers who expect the APIs, behaviors, etc, to remain stable during the lifetime of the patch stream for the minor release. Examples of breaking changes include: Removing or renaming exported constant, variable, type, or function. Updating the version of critical libraries such as `spf13/pflag`, `spf13/viper` etc... Some version updates may be acceptable for picking up bug fixes, but maintainers must exercise caution when reviewing. There may, at times, need to be exceptions where breaking changes are allowed in release branches. These are at the discretion of the project's maintainers, and must be carefully considered before merging. Maintainers will ensure the Cobra test suite utilizes the current supported versions of Golang. Changes to this document and the contents therein are at the discretion of the maintainers. None of the contents of this document are legally binding in any way to the maintainers or the users.
Project: Checkmk (Observability and Analysis / Observability)
File: 16645.md

key | value | date | 2024-03-16T23:26:40+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes In the page "Effective parameters of \<HOST\> / Check_MK Discovery" the parameters of the periodic service discovery where not shown. In addition some values have been shown that are not relevant to this service.
Project: Vector (Observability and Analysis / Observability)
File: 2019-11-25-unit-testing-vector-config-files.md

date: "2020-03-31" title: "Unit Testing Your Vector Config Files" description: "Treating your Vector configuration files as code" authors: ["binarylogic"] pr_numbers: [1220] release: "0.6.0" hideonrelease_notes: false badges: type: "new feature" domains: ["config"] aliases: ["/blog/unit-testing-vector-config-files"] Today we're excited to announce beta support for unit testing Vector configurations, allowing you to define tests directly within your Vector configuration file. These tests are used to assert the output from topologies of components given certain input events, ensuring that your configuration behavior does not regress; a very powerful feature for mission-critical production pipelines that are collaborated on. <!--more--> Let's look at a basic example that uses the [`regex_parser` transform][docs.transforms.regex_parser] to parse log lines: ```toml title="vector.toml" [sources.my_logs] type = "file" include = ["/var/log/my-app.log"] [transforms.parser] inputs = ["my_logs"] type = "regex_parser" regex = "^(?P<timestamp>[\\w\\-:\\+]+) (?P<level>\\w+) (?P<message>.*)$" [[tests]] name = "verify_regex" [tests.input] insert_at = "parser" type = "raw" value = "2019-11-28T12:00:00+00:00 info Hello world" [[tests.outputs]] extract_from = "parser" [[tests.outputs.conditions]] type = "check_fields" "timestamp.equals" = "2019-11-28T12:00:00+00:00" "level.equals" = "info" "message.equals" = "Hello world" ``` And you can run the tests via the new `test` subcommand: ```sh $ vector test ./vector.toml Running ./vector.toml tests Test ./vector.toml: verify_regex ... passed ``` Many Vector configurations will be simple transformations across straight forward pipelines (such as and piping the data to ) and don't really need protection from regressions. However, Vector configs are capable of expanding indefinitely with in order to solve as much of your processing needs as possible. As a configuration grows, and as the number of owners of a configuration grow, the potential for regressions also grows just like a regular code base. The lack of testing capabilities of configuration driven services is therefore a common pain for larger organizations. We hope that natively supporting unit tests in Vector configs will preemptively solve this problem. To help you get started we put together two documentation pages: These should be everything you need and will be actively maintained as this feature matures. We're eager to hear your feedback! Unit testing, as a `beta` feature, is still in an early phase and we need case studies and comments in order to ensure it works well for everyone. Please let us know what you think either in our or by .
Project: Vector (Observability and Analysis / Observability)
File: 2021-06-01-removing-helm-rawconfig.md

date: "2021-06-01" title: "Deprecating Helm `rawConfig` option" description: "The `rawConfig` option in the Vector Helm charts will be fully deprecated in an upcoming release" authors: ["spencergilbert"] pr_numbers: [7671] release: "0.14.0" hideonrelease_notes: false badges: type: "deprecation" platforms: ["kubernetes"] domains: ["config"] With the release of Vector 0.14.0, we are announcing the planned deprecation of the `rawConfig` option in our Helm charts. This will remove a source of complexity in our chart logic, and is a step towards using configuration provided in the `values.yaml` without converting them for the `managed.toml` config file. The values that were in `rawConfig` in TOML format now need to be moved up a level and written as YAML. Please refer to the `vector.yaml` on each component's documentation page for specific configuration examples. Below is an example of how to transition your `values.yaml` file: ```diff title="values.yaml" sources: dummy: type: "generator" rawConfig: | format = "shuffle" lines = ["Hello world"] interval = 60 # once a minute format: "shuffle" lines: ["Hello world"] interval: 60 # once a minute sinks: stdout: type: "console" inputs: ["dummy"] rawConfig: | target = "stdout" encoding.codec = "json" target: "stdout" encoding.codec: "json" ```
Project: M3 (Observability and Analysis / Observability)
File: components.md

title: "Components" weight: 1 M3 Coordinator is a service that coordinates reads and writes between upstream systems, such as Prometheus, and M3DB. It is a bridge that users can deploy to access the benefits of M3DB such as long term storage and multi-DC setup with other monitoring systems, such as Prometheus. See for more on long term storage in Prometheus. M3DB is a distributed time series database that provides scalable storage and a reverse index of time series. It is optimized as a cost effective and reliable realtime and long term retention metrics store and index. For more details, see the . {{< fileinclude file="m3query_intro.md" >}} {{< fileinclude file="m3aggregator_intro.md" >}}
Project: Checkmk (Observability and Analysis / Observability)
File: 16494.md

key | value | date | 2024-02-26T17:16:55+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes The above-mentioned plugin now monitors the list of ambient and internal temperature sensors, sticking to the logic of the netappapitemp plugin (old Netapp API). A re-discovery is needed to monitor the new services.
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: v1-4.md

title: Version 1.4 release notes menuTitle: V1.4 description: Release notes for Grafana Pyroscope 1.4 weight: 700 We are excited to present Grafana Pyroscope 1.4. This release includes several new features which are precursors to larger projects like: Adhoc profiling Time series scoped to a flame graph function Traces to profiles tooling Additionally, numerous other changes improve stability, performance, and documentation. Notable changes are listed below. For more details, check out the Full 1.4.0 Changelog: https://github.com/grafana/pyroscope/compare/v1.3.0...v1.4.0. Features and enhancements for version 1.4 include: Adhoc profiles API () Add query-tracer to profilecli () Add ServiceMonitor support to Helm chart (, , ) Scope time series to flame graph node API () Version 1.4 includes the following improvements and updates: Improve release workflows and documentation (, , , , , ) Improve block grouping in admin block viewer () Remove tenant settings from microservices deploy () Add test ids () Bump chart app version () Bump godeltaprof and jfr-parser dependencies () Update default image tag in chart () Per target configuration with labels () Async profile row iterator () Disable Go names decoration () Version 1.4 includes the following fixes: Add missing module dependencies () Fix missing icon assets () Store-gateway: Handle index read error properly () Use correct field in mappingsKey () Bump golang.org/x/net () Fix elf base for unaligned PT_LOAD offset, make build id error not fatal () Version 1.4 includes the following documentation updates: Add 1.3 release notes for docs () Add span profiles documentation () Update eBPF and Java documentation (, )
Project: Checkmk (Observability and Analysis / Observability)
File: 16806.md

key | value | date | 2024-04-23T12:04:08+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Checkmk 2.3.0 beta crashed during various operations if unexpected files where put into `local/lib/python3/cmk_addons/plugins/` or `local/lib/python3/cmk/plugins/`. They are ignored now.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: sidecar-proxy.md

title: Run Tempo distributed with sidecar proxies menuTitle: Configure sidecar proxies description: Configure Tempo distributed to run with sidecar proxies aliases: ../../configuration/sidecar-proxy/ # /docs/tempo/<TEMPO_VERSION>/configuration/sidecar-proxy/ You can route inter-pod gRPC traffic run through a sidecar proxy to meet requirements such as custom security, routing, or logging. Common examples include Envoy, Nginx, Traefik, or service meshes like Istio and Linkerd. Tempo pods communicate using gRPC. The different components like distributors and ingesters find each other by a shared ring with the list of pods, their roles, and their addresses. Pods advertise their address and listening port into the ring when they start, and deregister themselves when they exit. The overall network looks like this: The low-level ring data for ingesters can be viewed by browsing to the `/ingester/ring` URL on a distributor. It looks like this: By default, gRPC traffic uses port 9095, but this can be changed by customizing the `grpclistenport` for each pod that needs it. ```yaml server: grpclistenport: 12345 ``` The ring contents reflect the new port: Some installations require that the inter-pod gRPC traffic runs through a sidecar proxy. Running Tempo with proxies requires setting two ports for each pod: one for the Tempo process and one for the sidecar. Additionally, the ring contents must reflect the proxy's port so that traffic from other pods goes through the proxy. The overall network looks like this: This cannot be accomplished by setting the same `grpclistenport` as in the previous example. Instead, we need the ingester to listen on port A but advertise itself on port B. This is done by customizing the ingester's lifecycler port: ```yaml ingester: lifecycler: port: 12345 ``` Now, the ingester is listening for regular traffic on port 9095, but the distributor will route traffic to it on port 12345. You can customize the lifecyler port in the metrics-generator. To set an instance port for the metrics-generator, use this configuration: ```yaml metrics_generator: ring: instance_port: 12345 ``` Replace `12345` with the correct port number.
Project: HertzBeat (Observability and Analysis / Observability)
File: influxdb-init.md

id: influxdb-init title: Use Time Series Database InfluxDB to Store Metrics Data (Optional) sidebar_label: Use InfluxDB Store Metrics HertzBeat's historical data storage depends on the time series database InfluxDB, TDengine or IoTDB, choose one of them to install and initialize, or not to install (note but it is strongly recommended to configure in the production environment) TDengine is the Time Series Data Platform where developers build IoT, analytics, and cloud applications. Note Time series database is optional, but production environment configuration is strongly recommended to provide more complete historical chart functions and high performance If you do not configure a time series database, only the last hour of historical data is retained. Note Need InfluxDB 1.x Version. Use Get the `GaussDB For Influx` service url, username and password config. Note `GaussDB For Influx` enable SSL default, the service url should use `https:` Refer to the official website Download and install Docker environment Docker tools download refer to . After the installation you can check if the Docker version normally output at the terminal. ``` $ docker -v Docker version 20.10.12, build e91ed57 ``` Install InfluxDB with Docker ``` $ docker run -p 8086:8086 \ -v /opt/influxdb:/var/lib/influxdb \ influxdb:1.8 ``` `-v /opt/influxdb:/var/lib/influxdb` is local persistent mount of InfluxDB data directory. `/opt/influxdb` should be replaced with the actual local directory. use```$ docker ps``` to check if the database started successfully Configure HertzBeat's configuration file Modify `hertzbeat/config/application.yml` configuration file NoteThe docker container way need to mount application.yml file locally, while you can use installation package way to unzip and modify `hertzbeat/config/application.yml` Replace `warehouse.store.influxdb` data source parameters, URL account and password. ```yaml warehouse: store: jpa: enabled: false influxdb: enabled: true server-url: http://localhost:8086 username: root password: root expire-time: '30d' replication: 1 ``` Restart HertzBeat Do both the time series databases InfluxDB, IoTDB and TDengine need to be configured? Can they both be used? You don't need to configure all of them, you can choose one of them. Use the enable parameter to control whether it is used or not. You can also install and configure neither, which only affects the historical chart data.
Project: Checkmk (Observability and Analysis / Observability)
File: 16614.md

key | value | date | 2024-03-11T10:43:27+00:00 version | 2.4.0b1 class | fix edition | cre component | core level | 1 compatible | no When Checkmk is configured to Trust system wide configured CAs the system CA store is traversed and the certificates are added to the trusted CAs. With RFC 5280 certificate serial numbers are required to be positive. Unfortunately there are CA certificates out from before this RFC and the might contain negative serial numbers. One we encountered several times while testing is: commonName = EC-ACC organizationalUnitName = Jerarquia Entitats de Certificacio Catalanes organizationalUnitName = Vegeu https://www.catcert.net/verarrel (c)03 organizationalUnitName = Serveis Publics de Certificacio organizationName = Agencia Catalana de Certificacio (NIF Q-0801176-I) countryName = ES Our underlying library we use for handling certificates announced to no longer support certificates with negative serial numbers in one of the next versions. Therefore we decided to ignore certificates with negative serial numbers so we can update this library during the lifetime of this Checkmk release without changing this behaviour. Since the mentioned `EC-ACC` certificate was encountered multiple times during testing and is not widely used the fact that this certificate was encountered and is ignored is NOT logged. If you use certificates issued by CA certificates with negative serial numbers you can add them manually to your list of trusted certificates via the UI. This might cause warnings appearing in console outputs and in logfiles and may stop to work in the future.
Project: Checkmk (Observability and Analysis / Observability)
File: 16585.md

key | value | date | 2024-03-21T16:10:04+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Previously it was not possible to select an MBean that had a path separator. This Werk implements the Jolokia path separator `!/`. An example is shown in the following fragment of the jolokia.cfg file: ``` ... custom_vars = [('Catalina:J2EEApplication=none,J2EEServer=none,WebModule=*localhost!/docs,j2eeType=Servlet,name=default','requestCount','myspecialmetric',[],False,'number')]] ... ``` This will match the entry `myinstance,Catalina:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/docs,j2eeType=Servlet,name=defaultmyspecialmetric.requestCount0number`
Project: Checkmk (Observability and Analysis / Observability)
File: 16754.md

key | value | date | 2024-04-16T10:28:20+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes During the data parsing of a container, it is possible to encounter incomplete metric sets, which previously caused a crash. Since the data in these instances is simply unavailable, we now skip the discovery or check cycle for such cases. This adjustment is applied to docker container disktat and memory check plugins.
Project: Netdata (Observability and Analysis / Observability)
File: web_log_1m_total_requests.md

This alert calculates the total number of HTTP requests received by the web server in the last minute. If you receive this alert, it means that your web server is experiencing an increase in workload, which might affect its performance or availability. An increase in workload means that your web server is handling more traffic than usual, or there might be an unexpected spike in the number of HTTP requests received. This might be because of a variety of reasons, like marketing campaigns, product promotions, or even a sudden surge in user demand. Analyze web traffic logs To understand the reason behind the increased workload, the first step is to analyze the web server traffic logs. Look for any patterns, specific time intervals, or specific user agents that are contributing to the high number of requests. Check the web server performance Monitoring web server performance metrics like CPU usage, memory usage, and disk space can provide insight into the resource utilization. Use tools like `top`, `vmstat`, `iostat`, and `free` for this assessment. Monitor response times Checking the response time statistics, like average response time and peak response time, can help to understand if the server is struggling to serve the high number of requests. Tools like `apachetop` or `logstash` can be used to track this information. Evaluate server scaling options If none of the previous steps help to identify or resolve the issue, it might be time to consider scaling options. If the server is unable to handle the increased workload, vertically or horizontally scaling the system can help. Investigate application-level issues Application-level issues might also be the reason for high web server traffic. Profiling the web application, checking for slow database queries, or inefficient scripts can help to identify and resolve performance issues.