cwielenb/CNCF-Dataset huggingface dataset:
Project: Krkn (Observability and Analysis / Chaos Engineering)
File: build_own_image-README.md

Git clone the Kraken repository using `git clone https://github.com/redhat-chaos/krkn.git`. Modify the python code and yaml files to address your needs. Execute `podman build -t <newimagename>:latest .` in the containers directory within kraken to build an image from a Dockerfile. Execute `podman run --detach --name <containername> <newimage_name>:latest` to start a container based on your new image. Git clone the Kraken repository using `git clone https://github.com/redhat-chaos/krkn.git` on an IBM Power Systems server. Modify the python code and yaml files to address your needs. Execute `podman build -t <newimagename>:latest -f Dockerfile-ppc64le` in the containers directory within kraken to build an image from the Dockerfile for Power. Execute `podman run --detach --name <containername> <newimage_name>:latest` to start a container based on your new image.
Project: Promscale (Observability and Analysis / Observability)
File: sql_api.md

The content in this page has been moved to https://docs.timescale.com/promscale/latest/sql-api/ <!-- SQL To generate \pset border 1 \pset format aligned \pset linestyle ascii \o funcs.txt SELECT n.nspname as "Schema", p.proname as "Name", pgcatalog.pggetfunctionarguments(p.oid) as "Argument data types", pgcatalog.pggetfunctionresult(p.oid) as "Result data type", p.proname || ' ' || pgcatalog.objdescription(p.oid, 'pg_proc') || '.' as "Description" FROM pgcatalog.pgproc p LEFT JOIN pgcatalog.pgnamespace n ON n.oid = p.pronamespace LEFT JOIN pgcatalog.pglanguage l ON l.oid = p.prolang WHERE n.nspname like 'prom%' or n.nspname = 'pstrace' ORDER BY 1, 2, 3; -->
Project: Centreon (Observability and Analysis / Observability)
File: LICENSE.md

The MIT License Copyright 2013 by Remy Elazare 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: Vector (Observability and Analysis / Observability)
File: expressions.md

title: VRL expression reference short: Expressions weight: 4 VRL programs can be constructed with the following syntax rules. {{< vrl/syntax >}} As in most other languages, literals in VRL are values written exactly as they are meant to be interpreted. Literals include things like strings, Booleans, and integers. {{< vrl/literal-expressions >}} VRL is an expression-oriented language. A VRL program consists entirely of expressions and every expression returns a value. {{< vrl/dynamic-expressions >}}
Project: Teletrace (Observability and Analysis / Observability)
File: instrumentation.md

Instrumentation is the practice of adding additional code to an application to generate runtime information, like execution time and other metrics, to be used for troubleshooting, performance optimizations and to track execution flow. We can instrument our code in a various or ways, and the output format can change from implementation to implementation, fortunately though, by utilizing OpenTelemetry, which is a community driven specification for instrumentation data, we gain access to a vast collection of instrumentation libraries, written for a variety of languages and in a format that is accepted by most vendors in the industry. Manual instrumentation is the most basic form of instrumentation, you can think of it like upgraded debug prints, we manually include instrumentation points to the application code to gather information we think would be necessary in the future. Manual instrumentation is usually done using an SDK of some sort, and OpenTelemetry has SDKs for all supported languages. The major benefit of using a tool like OpenTelemetry is that we can leverage automatic instrumentation that will give us lots information out of the box, without the need for any code changes. Automatic Instrumentation is usually done by injecting instrumentation libraries at runtime and modifying the executed code on the fly. The topic of instrumentation is a major topic and probably too deep to fully explain here, please refer to the OpenTelemetry guides: <https://opentelemetry.io/docs/concepts/instrumenting/> <https://opentelemetry.io/docs/instrumentation/>
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-5-13.md

aliases: [] hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 8.5.13 <!-- Auto generated by update changelog github action --> Plugins: Expose @emotion/react to plugins to prevent load failures. , AuthNZ: Security fixes for CVE-2022-35957 and CVE-2022-36062. ,
Project: Netdata (Observability and Analysis / Observability)
File: windows_inbound_packets_discarded.md

This alert is triggered when the number of inbound discarded packets for a network interface on a Windows system exceeds the threshold (5 packets) within the last 10 minutes. If you receive this alert, it means that your network interface may have an issue that is causing packets to be discarded. Inbound discarded packets refer to network packets that are received by the network interface but are not processed by the system. Packets may be discarded for various reasons such as network congestion, packet corruption, or reaching the system's capacity limits. Identify the problematic network interface To find out which network interface is causing the problem, log in to the Windows system and open Performance Monitor. Go to the Windows Networking Network Interface section in the left pane and check the Packets Received Discarded counter to identify the offending interface. Check network interface hardware Verify that the network interface is working correctly and hasn't malfunctioned. Inspect the cables and ensure that they are connected properly. If possible, try a different network interface. Check network congestion and bandwidth usage High network congestion and bandwidth usage can cause packets to be discarded. Monitor your network's usage and check for any unusual patterns or excessive bandwidth usage. Consider using a network monitoring tool to gather more in-depth information about your network. Inspect system logs Check system logs for errors or warnings related to the network interface. The Windows Event Viewer can be a valuable resource for identifying issues related to the network interface. Update network adapter drivers Outdated or incompatible drivers can cause network issues, including inbound discarded packets. Ensure that your network adapter drivers are up-to-date and provided by a reliable source. Investigate packet corruption Packet corruption can be caused by faulty hardware, software issues, or even cyber-attacks. Ensure that your system is adequately protected, and investigate any possible software-related issues that may lead to packet corruption.
Project: Netdata (Observability and Analysis / Observability)
File: mysql_replication.md

This alert is triggered when the replication status of a MySQL server is indicating a problem or failure. Replication is important for redundancy, data backup, or load balancing. Issues with replication threads can lead to data inconsistencies or potential loss of data. Identify the failing thread: As mentioned above, use the appropriate command for your MySQL or MariaDB version to check the status of replication threads and determine which of them (I/O or SQL) is not running. For MySQL and MariaDB before v10.2.0, use: ``` SHOW SLAVE STATUS\G ``` For MariaDB v10.2.0+, use: ``` SHOW ALL SLAVES STATUS\G ``` Inspect the MySQL error log: The MySQL error log can provide valuable information about the possible cause of the replication issues. Check the log for any replication-related error messages: ``` tail -f /path/to/mysql/error.log ``` Replace `/path/to/mysql/error.log` with the correct path to the MySQL error log file. Check the source MySQL server: Replication issues can also originate from the source MySQL server. Make sure that the source server is properly configured and running, and that the binary logs are being written and flushed correctly. Refer to the for more information on configuring replication. Restart the replication threads: After identifying and resolving any issues found in the previous steps, you can try restarting the replication threads: ``` STOP SLAVE; START SLAVE; ``` For MariaDB v10.2.0+ with multi-source replication, you may need to specify the connection name: ``` STOP ALL SLAVES; START ALL SLAVES; ``` Verify the replication status: After restarting the replication threads, use the appropriate command from step 1 to verify that the threads are running, and that the replication is working as expected.
Project: M3 (Observability and Analysis / Observability)
File: upgrading.md

title: "Upgrading M3" date: 2020-04-21T20:50:39-04:00 draft: true This guide explains how to upgrade M3 from one version to another (e.g. from 0.14.0 to 0.15.0). This includes upgrading: m3dbnode m3coordinator m3query m3aggregator m3dbnode While upgrading M3DB nodes, it's important to monitor the status of bootstrapping the individual nodes. This can be monitored using the M3DB Node Details graph. Typically, the Bootstrapped graph under Background Tasks and the graphs within the CPU and Memory Utilization give a good understanding of how well bootstrapping is going. It is very important that for each replica set, only one node gets upgraded at a time. However, multiple nodes can be upgraded across replica sets. 1) Download new binary (linux example below). wget "https://github.com/m3db/m3/releases/download/v$VERSION/m3$VERSIONlinuxamd64.tar.gz" && tar xvzf m3$VERSIONlinuxamd64.tar.gz && rm m3$VERSIONlinux_amd64.tar.gz 2) Stop and upgrade one M3DB node at a time per replica set using the systemd unit. sudo systemctl stop m3dbnode sudo systemctl start m3dbnode Note: If unable to stop m3dbnode using systemctl, use pkill instead. pkill m3dbnode ./m3$VERSIONlinux_amd64/m3dbnode -f <config-name.yml> 3) Confirm m3dbnode has finished bootstrapping. 20:10:12.911218[I] updating database namespaces [{adds [default]} {updates []} {removals []}] 20:10:13.462798[I] node tchannelthrift: listening on 0.0.0.0:9000 20:10:13.463107[I] cluster tchannelthrift: listening on 0.0.0.0:9001 20:10:13.747173[I] node httpjson: listening on 0.0.0.0:9002 20:10:13.747506[I] cluster httpjson: listening on 0.0.0.0:9003 20:10:13.747763[I] bootstrapping shards for range starting ... ... 20:10:13.757834[I] bootstrap finished [{namespace metrics} {duration 10.1261ms}] 20:10:13.758001[I] bootstrapped 20:10:14.764771[I] successfully updated topology to 3 hosts 4) Repeat steps 2 and 3 until all nodes have been upgraded. Kubernetes If running M3DB on Kubernetes, upgrade by completing the following steps. Identify the version of m3dbnode to upgrade to on Quay. Replace the Docker image in the StatefulSet manifest (or m3db-operator manifest) to be the new version of m3dbnode. spec: image: quay.io/m3db/m3dbnode:$VERSION Once updated, apply the updated manifest and a rolling restart will be performed. kubectl apply -f <m3dbnode_manifest> The upgrading steps above can also be used to downgrade M3DB. However, it is important to refer to the release notes to make sure that versions are backwards compatible. m3coordinator m3coordinator can be upgraded using similar steps as m3dbnode, however, the images can be found here instead. m3query m3query can be upgraded using similar steps as m3dbnode, however, the images can be found here instead. m3aggregator m3aggregator can be upgraded using similar steps as m3dbnode, however, the images can be found here instead.
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: canary.md

Canary release is a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody. This is the easiest rollout strategy available. You just have to select a percentage of your users in your flag, and the `True` behavior will apply to them. ``` yaml linenums="1" canary-flag: true: true false: false default: false percentage: 1 ``` ``` json { "canary-flag": { "true": true, "false": false, "default": "false, "percentage": 1 } } ``` ``` toml [canary-flag] true = true false = false default = false percentage = 1.0 ```
Project: Grafana Mimir (Observability and Analysis / Observability)
File: v4.3.md

title: "Grafana Mimir Helm chart version 4.3 release notes" menuTitle: "V4.3 release notes" description: "Release notes for Grafana Mimir Helm chart version 4.3" weight: 300 Grafana Labs is excited to announce version 4.3 of the Grafana Mimir Helm chart, which is compatible with Grafana Mimir v2.7 or Grafana Enterprise Metrics (GEM) v2.7. The `mimir-distributed` Helm chart is the best way to install Mimir on Kubernetes. To learn about new features and enhancements in Grafana Mimir or GEM, see the release notes for or . The highlights that follow include the top features, enhancements, and bugfixes in this release. For a comprehensive list of changes, see the . Note: If you are upgrading from a previous major version, review the changelog entry for all the major releases since then and perform the necessary migrations. The ruler deployment max surge was changed from `0` to `50%`, and max unavailable from `1` to `0`. Notable enhancements are as follows: nginx autoscaling Support autoscaling/v2 HorizontalPodAutoscaler for nginx autoscaling starting with Kubernetes 1.23. Default pod security context Set default pod security context under `rbac.podSecurityContext` for easier install on OpenShift. Cache support for GEM's admin bucket The cache will be enabled by default when you use the small.yaml, large.yaml, capped-small.yaml or capped-large.yaml Helm values file. > Note: For more information, refer to the . : Allow override of Kubernetes version for nginx HPA. : Do not generate query-frontend-headless service if query scheduler is enabled. Fixes parity with jsonnet. : Apply `clusterLabel` to ServiceMonitors for kube-state-metrics, kubelet, and cadvisor. : Add http port in distributor headless service. Fixes parity with jsonnet. : Generate the pod security context on the pod level in graphite web deployment, instead of on container level. : Fix kube-state-metrics metricRelabelings dropping pods and deployments. : Allow for single extraArg flags in templated memcached args. : Updated Go version in Mimir and GEM images to 1.20.3 to fix CVE-2023-24538.
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: architecture.md

title: "Architecture" description: "Overall Architecture" weight: 18 The overall architecture of Crane is shown as below: Craned Craned is the core component which manage the lifecycle of CRDs and APIs. It's deployed by a `Deployment` which consists of two container: Craned: Operators for management CRDs, WebApi for Dashboard, Predictors that provide query TimeSeries API. Dashboard: Web component that built from TDesign's Starter, provide an easy-to-use UI for crane users. Fadvisor Fadvisor provides a collection of exporters which collect cloud resource pricing and billing data and ship to your monitoring system like Prometheus. Fadvisor support Multi-Cloud Pricing API by `Cloud Provider`. Metric Adapter Metric Adapter implements a `Custom Metric Apiserver`. Metric Adapter consume Crane CRDs and provide HPA Metrics by `Custom/External Metric API`. Crane Agent Crane Agent is a `DaemonSet` that runs in each node. Crane is composed of the following components: - main crane control plane. - Metric server for driving the scaling. - Ensure critical workloads SLO based on abnormally detection. - This repository defines component-level APIs for the Crane platform. - Financial advisor which collect resource prices from cloud API. - A Kubernetes scheduler which can schedule pod based on actual node load. - Kubectl plugin for crane, including recommendation and cost estimate.
Project: Zipkin (Observability and Analysis / Observability)
File: SECURITY.md

This document outlines the process for handling security concerns in OpenZipkin projects. Any vulnerability or misconfiguration detected in our should be addressed as a normal pull request. OpenZipkin is a volunteer community and does not have a dedicated security team. There may be periods where no volunteer is able to address a security concern. There is no SLA or warranty offered by volunteers. If you are a security researcher, please consider this before escalating. For security concerns that are sensitive or otherwise outside the scope of public issues, please contact zipkin-admin@googlegroups.com.
Project: Kiali (Observability and Analysis / Observability)
File: CONTRIBUTING.md

We'd love your help! Kiali is and accepts contributions via GitHub pull requests. Kiali does not require any contributor agreement to submit patches. This document outlines some of the conventions on development workflow, commit message formatting, contact points and other resources to make it easier to get your contribution accepted. We gratefully welcome improvements to documentation as well as to code. Before you make a change, please: Open a or an describing in detail the motivation of work. Regardless of the repo where the work should be done (server, UI, operator, or helm charts), all discussions and issues should be submitted to the main kiali/kiali repo using those links provided. Let the maintainers comment on the question or refine the issue. Before starting work, make sure maintainers have agreed that the work should be done and has added the issue to the backlog. When the design/approach/discussion is ready, prepare a Pull Request with the changes. If you are new to contributing to Kiali and want to pick some easier tasks to get accustomed to the code base, you can pick [issues that are marked good first issue on GitHub](https://github.com/kiali/kiali/labels/good%20first%20issue). The and the have a pretty extensive guide on building Kiali server and UI. If you want to add a new language or improve an existing one, you can check the internationalization section of the See the about getting your code in style. Once the issue has been agreed upon and developed, you can send a pull-request. The pull-request should have a detailed explanation of the changes that you are doing (i.e. include screenshots for UI changes). If you worked on a GitHub issue, please provide the link as part of the description. Pull requests will be reviewed by the team of committers and they will come up with suggestions on how to improve the pull-request. You should be prepared to take that feedback into account, add further commits into the pull-request until the pull-request is eventually merged. By contributing your code, you agree to license your contribution under the terms of the .
Project: Botkube (Observability and Analysis / Observability)
File: botkube_config_get.md

title: botkube config get Displays Botkube configuration ``` botkube config get [flags] ``` ``` botkube config get botkube config get -ojson botkube config get > config.yaml ``` ``` --cfg-exporter-image-registry string Registry for the Config Exporter job image (default "ghcr.io") --cfg-exporter-image-repo string Repository for the Config Exporter job image (default "kubeshop/botkube-config-exporter") --cfg-exporter-image-tag string Tag of the Config Exporter job image (default "v9.99.9-dev") --cfg-exporter-poll-period duration Interval used to check if Config Exporter job was finished (default 1s) --cfg-exporter-timeout duration Maximum execution time for the Config Exporter job (default 1m0s) --cloud-env-api-key string API key environment variable name specified under Deployment for cloud installation. (default "CONFIGPROVIDERAPI_KEY") --cloud-env-endpoint string Endpoint environment variable name specified under Deployment for cloud installation. (default "CONFIGPROVIDERENDPOINT") --cloud-env-id string Identifier environment variable name specified under Deployment for cloud installation. (default "CONFIGPROVIDERIDENTIFIER") -h, --help help for get -l, --label string Label used for identifying the Botkube pod (default "app=botkube") -n, --namespace string Namespace of Botkube pod (default "botkube") --omit-empty-values Omits empty keys from printed configuration (default true) -o, --output string Output format. One of: json | yaml (default "yaml") ``` ``` -v, --verbose int/string[=simple] Prints more verbose output. Allowed values: 0 - disable, 1 - simple, 2 - trace (default 0 - disable) ``` - This command consists of multiple subcommands for working with Botkube configuration
Project: Checkmk (Observability and Analysis / Observability)
File: 16049.md

key | value | date | 2024-02-19T07:41:52+00:00 version | 2.4.0b1 class | fix edition | cre component | multisite level | 1 compatible | yes The view "Service graphs of host" used to show the error message "No historic metrics recorded but performance data is available. Maybe performance data processing is disabled." even if the underlying single service graphs existed. This occured especially when using a host check command. The behavior is fixed to always rendering the service graphs in the view "Service graphs of host", if their performance data is available. Note that this change does not affect the same error message shown for the "Host graph" row of the "Status of Host" view, as the available performance data belongs to the services and not to the host.
Project: SkyWalking (Observability and Analysis / Observability)
File: h2.md

Activate H2 as storage, set storage provider to H2 In-Memory Databases by default in the distribution package. Please read `Database URL Overview` in . You can set the target to H2 in Embedded, Server and Mixed modes. Setting fragment example ```yaml storage: selector: ${SW_STORAGE:h2} h2: driver: org.h2.jdbcx.JdbcDataSource url: jdbc:h2:mem:skywalking-oap-db user: sa maxSizeOfBatchSql: ${SWSTORAGEMAXSIZEOFBATCHSQL:100} asyncBatchPersistentPoolSize: ${SWSTORAGEASYNCBATCHPERSISTENTPOOLSIZE:1} ```
Project: Checkmk (Observability and Analysis / Observability)
File: 15331.md

key | value | date | 2024-04-16T07:10:21+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | no Checkmk discovered Services like "PostgreSQL DB MAIN/accesstoshared_objects Size" but the Services only showed "Database size not available" and a WARN status. Those Services are no longer discovered.
Project: EaseAgent (Observability and Analysis / Observability)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: '' assignees: '' name: 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 or screenshots about the feature request here. Thanks for contributing !