cwielenb/CNCF-Dataset huggingface dataset:
Project: Chaos Mesh (Observability and Analysis / Chaos Engineering)
File: why-do-we-not-use-argo.md

<!-- TOC --> - - - <!-- /TOC --> It has been a long time that we decide to build up another workflow engine. I believe that we have enough reasons that push us to build a new workflow engine. But when other contributors ask me, "Why not use Argo"? I could not give them convincing words in time. That's why I decide to write this doc. Argo is an amazing workflow engine for common purpose. Argo provides "sequential/parallel execution", "conditional branches", "DAG"; and workloads like "script", "container", "resource". I think the most advantage is reducing our jobs, we do not need to re-implement another workflow engine. We could build a workflow by writing some scripts with `kubectl`. Argo supports "script", "container" and "resource" workloads, it could integrate with Chaos Mesh to apply/recover chaos experiments. But this way to apply chaos experiments is not declarative anymore, it turns to imperative. Argo is so powerful and it's impossible to ask users always for following the best practices. Users could write complex scripts for determining the situation, then `kubectl apply` or `kubectl patch` something, once a command make unexpected side-effects, it will let the whole system unstable. We define the workflow that could describe chaos experiments in the declarative, changing chaos experiments is just like "from expected status A turning into expected status B", users should not considering about "remove some chaos CR object" or "create new chaos CR object". We also allow users (only) to execute their scripts in `Task` node, it will not affect the changing of chaos experiment states. Based on our own workflow, it's easier to provide more useful features like: more detailed status perceive and retry/failover chaos experiment report better UI Actually, for example, litmus chaos is not strictly declarative chaos experiments, its `ChaosExperiments` contains scripts that how to inject chaos. During executing, a `ChaosEngine` will instantiate it into a `Job`, then running those scripts. If something unexpected happened, such as the pod was killed by OOM killer, the dirty thing is just left here without recovering anymore. In other words, it just a wrapper of `Job`, with more effective selectors and conditions. So it is suitable for Argo, it is imperative commands from start to end. In other words, we do not use Argo, which does not mean we reject Argo. We are trying to defining something that could schedule chaos, and independent with Argo. Applications based on kubernetes have an issue: it's nearly not possible to deploy different instances with different versions in one cluster. If Chaos Mesh depends on argo version X, and the user already installed argo version Y, it might be incompatible, there is no way to resolve it. Chaos Mesh has the plans for more situation not only kubernetes, just like CaaS(Chaos engineering as a Service). If one day we need to migrate workflow into a non-kubernetes cluster, I think our own workflow is easier to do.
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: tcpconnect.md

title: Gadget tcpconnect tcpconnect traces connect() system calls ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: tcpconnect namespace: gadget spec: node: ubuntu-hirsute gadget: tcpconnect runMode: Manual outputMode: Stream filter: namespace: default ``` Start tcpconnect gadget ```bash $ kubectl annotate -n gadget trace/tcpconnect \ gadget.kinvolk.io/operation=start ``` Stop tcpconnect gadget ```bash $ kubectl annotate -n gadget trace/tcpconnect \ gadget.kinvolk.io/operation=stop ``` Stream
Project: Checkmk (Observability and Analysis / Observability)
File: 14617.md

key | value | date | 2024-01-17T15:06:16+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes `check_uniserv` implementation didn't encode the `close` command resulting in an exception `TypeError: a bytes-like object is required, not 'str'` being raised. This change adds the missing encoding among some general modernization.
Project: Checkmk (Observability and Analysis / Observability)
File: 16483.md

key | value | date | 2024-02-22T13:18:29+00:00 version | 2.4.0b1 class | fix edition | cee component | ntopng_integration level | 1 compatible | no Since Werk 16479 the ntopng integration was compatible with both ntopng versions newer than 6.0 and older than 6.0. With this change the ntopng integration no longer supports version older than 6.0.
Project: Checkmk (Observability and Analysis / Observability)
File: 16470.md

key | value | date | 2024-02-01T08:01:39+00:00 version | 2.4.0b1 class | fix edition | cre component | multisite level | 1 compatible | no Previously, pagetypes (bookmarks, custom graphs, topics etc.) were falsely handled as public, rather than private. Items published only to specific groups are not affected and were handled correctly. This change may cause users to no longer see public overwrites by admins for example. Please ensure your permissions and publish states are configured correctly.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: bad-blocks.md

title: Bad blocks description: Troubleshoot queries failing with an error message indicating bad blocks. weight: 475 aliases: ../operations/troubleshooting/bad-blocks/ Queries fail with an error message containing: ``` error querying store in Querier.FindTraceByID: error using pageFinder (1, 5927cbfb-aabe-48b2-9df5-f4c3302d915f): ... ``` This might indicate that there is a bad (corrupted) block in the backend. A block can get corrupted if the ingester crashed while flushing the block to the backend. At the moment, a backend block can be fixed if either the index or bloom-filter is corrupt/deleted. To fix such a block, first download it onto a machine where you can run the `tempo-cli`. Next run the `tempo-cli`'s `gen index` / `gen bloom` commands depending on which file is corrupt/deleted. The command will create a fresh index/bloom-filter from the data file at the required location (in the block folder). To view all of the options for this command, see the . Finally, upload the generated index or bloom-filter onto the object store backend under the folder for the block. If the above step on fixing bad blocks reveals that the data file is corrupt, the only remaining solution is to delete the block, which can result in some loss of data. The mechanism to remove a block from the backend is backend-specific, but the block to remove will be at: ``` <tenant ID>/<block ID> ```
Project: Netdata (Observability and Analysis / Observability)
File: upsd_ups_last_collected_secs.md

This alert is related to the Network UPS Tools (NUT) which monitors power devices, such as uninterruptible power supplies, power distribution units, solar controllers, and server power supply units. If you receive this alert, it means that there is an issue with the data collection process and needs troubleshooting to ensure the monitoring process works correctly. Check the status of the upsd daemon: ``` $ systemctl status upsd ``` Check for obvious and common errors in the log or output. If any errors are found, resolve them accordingly. Restart the daemon if needed: ``` $ systemctl restart upsd ``` `upsd` expects the drivers to either update their status regularly or at least answer periodic queries, called pings. If a driver doesn't answer, `upsd` will declare it "stale" and no more information will be provided to the clients. If upsd complains about staleness when you start it, then either your driver or configuration files are probably broken. Be sure that the driver is actually running, and that the UPS definition in is correct. Also, make sure that you start your driver(s) before starting upsd. Data can also be marked stale if the driver can no longer communicate with the UPS. In this case, the driver should also provide diagnostic information in the syslog. If this happens, check the serial or USB cabling, or inspect the network path in the case of a SNMP UPS.
Project: Vector (Observability and Analysis / Observability)
File: what-is-observability-pipelines.md

title: What are Observability Pipelines? weight: 2 tags: ["concepts"] Datadog's Observability Pipelines are commercial observability data pipelines for collecting, processing, and routing observability data from any source to any destination in the infrastructure that you own or manage. Use Observability Pipelines to: Manage your pipelines from a control plane. You can build or edit pipelines, whether it is to route a subset of data to a new destination or introduce a new sensitive data redaction rule, and roll out these changes to your active pipelines from the Datadog UI. Monitor your pipelines to understand the health of your pipelines, identify bottlenecks and latencies, fine-tune performance, validate data delivery, and investigate your largest volume contributors. Better optimize volume and control costs by enforcing quotas, store noisy logs in an archive, and more. Scan for and redact sensitive data flowing through your pipelines.
Project: OpenLLMetry (Observability and Analysis / Observability)
File: SECURITY.md

Contact: security@traceloop.com Based on We place a high priority on the security of our systems at Traceloop. However, no matter how hard we try to make our systems secure, vulnerabilities can still exist. In the event that you discover a vulnerability, please let us know so we can address it as soon as possible. We would like to ask you to help us better protect our clients and our systems. Clickjacking on pages with no sensitive actions. Unauthenticated/logout/login CSRF. Attacks requiring MITM or physical access to a user's device. Any activity that could lead to the disruption of our service (DoS). Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS. Email spoofing Missing DNSSEC, CAA, CSP headers Lack of Secure or HTTP only flag on non-sensitive cookies Deadlinks E-mail your findings to . Do not run automated scanners on our infrastructure or dashboard. If you wish to do this, contact us and we will set up a sandbox for you. Do not take advantage of the vulnerability or problem you have discovered, for example by downloading more data than necessary to demonstrate the vulnerability or deleting or modifying other people's data, Do not reveal the problem to others until it has been resolved, Do not use attacks on physical security, social engineering, distributed denial of service, spam or applications of third parties, Do provide sufficient information to reproduce the problem, so we will be able to resolve it as quickly as possible. Usually, the IP address or the URL of the affected system and a description of the vulnerability will be sufficient, but complex vulnerabilities may require further explanation. We will respond to your report within 3 business days with our evaluation of the report and an expected resolution date, If you have followed the instructions above, we will not take any legal action against you in regard to the report, We will handle your report with strict confidentiality, and not pass on your personal details to third parties without your permission, We will keep you informed of the progress towards resolving the problem, In the public information concerning the problem reported, we will give your name as the discoverer of the problem (unless you desire otherwise), and We strive to resolve all problems as quickly as possible, and we would like to play an active role in the ultimate publication on the problem after it is resolved.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: boutique-chaos-on-load.md

Online Boutique is a cloud-first microservices demo application. Online Boutique consists of an 11-tier microservices application. The application is a web-based e-commerce app where users can browse items, add them to the cart, and purchase them. In this demo, we will perform the following actions using litmus chaos scenarios: Launch a on the frontend service of boutique application. In cpu-hog chaos experiment Run the cpu chaos on the frontend service under fortio load. Remove the forio job as part of the cleanup stage. UseCase: This demo will help us to understand how we can run a load-gen on our application and perform a chaos test on it. To achieve this, the chaos scenario first launches a Forio load job on the frontend service of boutique application, then runs a cpu-chaos experiment on the same service to check the resiliency under load. Steps: Introduce demo setup: A sample application with monitoring setup and chaos center dashboard - Select the pre-defined scenario and go through the individual steps - Run the scenario and visualise the impact of the load generator in grafana - Visualise the impact of chaos on frontend service under load - Check the chaos result and experiment logs for steady state validation -
Project: Grafana (Observability and Analysis / Observability)
File: plugin-anatomy.md

labels: products: enterprise oss title: Plugin Anatomy Plugins come in different shapes and sizes. Before we dive deeper, let's look at some of the properties that are shared by all of them. Every plugin you create will require at least two files: `plugin.json` and `src/module.ts`. When Grafana starts, it scans the plugin directory for any subdirectory that contains a `plugin.json` file. The `plugin.json` file contains information about your plugin, and tells Grafana about what capabilities and dependencies your plugin needs. While certain plugin types can have specific configuration options, let's look at the mandatory ones: `type` tells Grafana what type of plugin to expect. Grafana supports three types of plugins: `panel`, `datasource`, and `app`. `name` is what users will see in the list of plugins. If you're creating a data source, this is typically the name of the database it connects to, such as Prometheus, PostgreSQL, or Stackdriver. `id` uniquely identifies your plugin, and should start with your Grafana username, to avoid clashing with other plugins. to claim your username. To see all the available configuration settings for the `plugin.json`, refer to the . After discovering your plugin, Grafana loads the `module.ts` file, the entrypoint for your plugin. `module.ts` exposes the implementation of your plugin, which depends on the type of plugin you're building. Specifically, `module.ts` needs to expose an object that extends , and can be any of the following:
Project: Checkmk (Observability and Analysis / Observability)
File: 16530.md

key | value | date | 2024-02-26T14:48:45+00:00 version | 2.4.0b1 class | fix edition | cee component | ec level | 1 compatible | yes Event Console UPDATE command accepts a list of events instead of a single event. With this change the GUI will send a list of events to be updated to the Event Console. This allows for multiple events to be updated in a single command. Avoids the situation where some events are updated and others are not.
Project: Checkmk (Observability and Analysis / Observability)
File: 16421.md

key | value | date | 2024-04-09T11:39:57+00:00 version | 2.4.0b1 class | fix edition | cee component | checks level | 1 compatible | no This Werk affects users, who have configured the rule `Robotmk Scheduler (Windows)` during the 2.3.0 beta. The naming conventions of the check plugin `robotmk_suite` have been reworked. Plugin was renamed from `robotmksuite` to `robotmkplan`. Service label value changed from `cmk/rmk/type:suite` to `cmk/rmk/type:plan`. The service item has changed it's suffix from `Suite` to `Plan`. The metric was renamed from `robotmksuiteruntime` to `robotmkpeakattempt_runtime` The metric was renamed from `robotmkruntimetimeoutratio` to `robotmkruntimelimitratio` Users affected by this change must run re-discovery.
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: troubleshooting.md

title: Troubleshooting sidebar_label: Troubleshooting sidebar_position: 90 Here are some common issues encountered when trying to set up Flagsmith in a self hosted environment. If you are using health-checks, make sure to use `/health` as the health-check endpoint for both the API and the Front end. The most common cause of issue when setting things up in AWS with an RDS database is missing Security Group permissions between the API application and the RDS database. You need to ensure that the attached security groups for ECS/Fargate/EC2 allow access to the RDS database. and . Make sure you have a `DATABASE_URL` environment variable set within the API application. If you are running the API and the Front end as separate applications, you need to make sure that the Front end is pointing to the API. Check the , particularly `API_URL`.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-host_reset.md

category: Host apiurl: '/api/v1/host/maintain' title: "Reset host maintain by ids or hostnames" type: 'DELETE' sample_doc: 'host.html' layout: default Required ```{"ids": [1,2,3,4]}``` or ```{"hosts": ["host.a","host.b"]}``` ```Status: 200``` ```{ "message": "Through: hosts, Affect row: 2" }```
Project: Netdata (Observability and Analysis / Observability)
File: inbound_packets_dropped.md

This alert is triggered when the number of inbound dropped packets for a network interface exceeds a specified threshold during the last 10 minutes. A dropped packet means that the network device could not process the packet, hence it was discarded. Network Congestion: When the network traffic is too high, the buffer may overflow before the device can process the packets, causing some packets to be dropped. Link Layer Errors: Packets can be dropped due to errors in the link layer causing frames to be corrupted. Insufficient Resources: The network interface may fail to process incoming packets due to a lack of memory or CPU resources. Check the overall system resources Run the `vmstat` command to get a report about your system statistics. ``` vmstat 1 ``` Check if the CPU or memory usage is high. If either is near full utilization, consider upgrading system resources or managing the load more efficiently. Check network interface statistics Run the `ifconfig` command to get more information on the network interface. ``` ifconfig <INTERFACE> ``` Look for the `RX dropped` field to confirm the number of dropped packets. Monitor network traffic Use `iftop` or `nload` to monitor the network traffic in real time. If you don't have these tools, install them: ``` sudo apt install iftop nload ``` ``` iftop -i <INTERFACE> nload <INTERFACE> ``` Identify if there is unusually high traffic on the network interface. Check logs for any related errors Check the system logs for any errors related to the network interface or driver: ``` sudo dmesg | grep -i "eth0" sudo journalctl -u networking.service ``` If you find any errors, you can research the specific problem and apply the necessary fixes.
Project: Krkn (Observability and Analysis / Chaos Engineering)
File: installation.md

The following ways are supported to run Kraken: Standalone python program through Git. Containerized version using either Podman or Docker as the runtime via Kubernetes or OpenShift deployment ( unsupported ) NOTE: It is recommended to run Kraken external to the cluster ( Standalone or Containerized ) hitting the Kubernetes/OpenShift API as running it internal to the cluster might be disruptive to itself and also might not report back the results if the chaos leads to cluster's API server instability. NOTE: To run Kraken on Power (ppc64le) architecture, build and run a containerized version by following the instructions given . NOTE: Helper functions for interactions in Krkn are part of . Please feel free to reuse and expand them as you see fit when adding a new scenario or expanding the capabilities of the current supported scenarios. Pick the latest stable release to install . ``` $ git clone https://github.com/krkn-chaos/krkn.git --branch <release version> $ cd krkn ``` ``` $ python3.9 -m venv chaos $ source chaos/bin/activate $ pip3.9 install -r requirements.txt ``` NOTE: Make sure python3-devel and latest pip versions are installed on the system. The dependencies install has been tested with pip >= 21.1.3 versions. ``` $ python3.9 runkraken.py --config <configfile_location> ``` is a wrapper that allows running Krkn chaos scenarios via podman or docker runtime with scenario parameters/configuration defined as environment variables. Refer to get started. Refer on how to deploy and run Kraken as a Kubernetes/OpenShift deployment. Refer to the and especially the for details on how to configure this chart.
Project: M3 (Observability and Analysis / Observability)
File: configuring_m3db.md

title: "Configuring M3DB" menuTitle: "Configuring M3DB" weight: 10 chapter: true By default the operator will apply a configmap with basic M3DB options and settings for the coordinator to direct Prometheus reads/writes to the cluster. This template can be found . To apply custom a configuration for the M3DB cluster, one can set the `configMapName` parameter of the cluster [spec] to an existing configmap. If providing a custom config map, the `env` you specify in your must be `$NAMESPACE/$NAME`, where `$NAMESPACE` is the Kubernetes namespace your cluster is in and `$NAME` is the name of the cluster. For example, with the following cluster: ```yaml apiVersion: operator.m3db.io/v1alpha1 kind: M3DBCluster metadata: name: cluster-a namespace: production ... ``` The value of `env` in your config MUST be `production/cluster-a`. This restriction allows multiple M3DB clusters to safely share the same etcd cluster.
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-1.3.12.md

Upgrade `org.bouncycastle:bcprov-jdk15on` to `org.bouncycastle:bcprov-jdk15to18` version 1.75 () Upgrade `org.bouncycastle:bcmail-jdk15on` to `org.bouncycastle:bcmail-jdk15to18` version 1.75 () Upgrade `org.bouncycastle:bcpkix-jdk15on` to `org.bouncycastle:bcpkix-jdk15to18` version 1.75 () Upgrade `netty` from 4.1.94.Final to 4.1.96.Final () Upgrade bundled OpenJDK (July 2023 Patch releases) ()