cwielenb/CNCF-Dataset huggingface dataset:
Project: PowerfulSeal (Observability and Analysis / Chaos Engineering)
File: cloud-provider-requirements.md

layout: default title: Cloud Provider nav_order: 2 description: "" permalink: /cloud-provider-requirements parent: Setup {: .no_toc } {: .no_toc .text-delta } TOC {:toc} The credentials to connect to Azure may be specified in one of two ways: Supply the full path to an Azure credentials file in the environment variable `AZUREAUTHLOCATION`. This is the easiest method. The credentials file can be generated via `az aks get-credentials -n <cluster name> -g <resource group> -a -f <destination credentials file>` Supply the individual credentials in the environment variables: `AZURESUBSCRIPTIONID`, `AZURECLIENTID`, `AZURECLIENTSECRET`, `AZURETENANTID` The credentials to connect to AWS are specified the same as for the The easiest way to use PowerfulSeal, is to download and source the OpenRC file you can get from Horizon. It should ask you for your password, and it should set all the `OS_*` variables for you. Alternatively, you can set them yourself. Both approaches are detailed in . Google Cloud SDK and kubectl are required The GCP cloud driver supports managed (GKE) and custom Kubernetes clusters running on top of Google Cloud Compute. For setting up ```PowerfulSeal```, the first step is configuring gcloud SDK (as ```PowerfulSeal``` will work with your configured and ) and pointing kubectl to your cluster. Both can be configured easily following tutorial (For GKE!). In case you don't want to use the default project/region of gcloud SDK, you can point ```PowerfulSeal``` to the correct one (in json) with ```--gcp-config-file``` argument. For being able to run node related commands, credentials have to be specified in one of these : Service account (Recommended): a Google account that is associated with your GCP project, as opposed to a specific user. ```PowerfulSeal``` uses the environment variable and is pretty straightforward to set up using tutorial. User account: Not recommended as you can reach easily reach a "quota exceeded" or "API not enabled" error. ```PowerfulSeal``` uses auto-discovery and to get it working just follow . Having configuration ready and ssh connection to the node instances working, you can start playing with ```PowerfulSeal``` with this example: ```powerfulseal interactive --gcp --ssh-allow-missing-host-keys --ssh-path-to-private-key ~/.ssh/googlecomputeengine --remote-user myuser``` Note: In case of running inside Pyenv and getting ```python2 command not found``` error when running gcloud (and you want to run ```PowerfulSeal``` with Python 3+), might be useful, as gcloud requires Python2. Note: With GCP, running ```gcloud compute config-ssh``` makes SSHing to node instances easier by adding an alias for each instance to the user SSH configuration (~/.ssh/config) file and then being able to use the generated file with ```--ssh-path-to-private-key``` argument.
Project: OpenLLMetry (Observability and Analysis / Observability)
File: README.md

<a href="https://pypi.org/project/opentelemetry-instrumentation-pinecone/"> <img src="https://badge.fury.io/py/opentelemetry-instrumentation-pinecone.svg"> </a> This library allows tracing client-side calls to Pinecone vector DB sent with the official . ```bash pip install opentelemetry-instrumentation-pinecone ``` ```python from opentelemetry.instrumentation.pinecone import PineconeInstrumentor PineconeInstrumentor().instrument() ```
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_pubcomp_received_reason_unsuccessful.md

This alert indicates that the VerneMQ broker has received an increased number of unsuccessful MQTT v5 PUBCOMP (Publish Complete) packets in the last minute. The PUBCOMP packet is the fourth and final packet in the QoS 2 publish flow. It means that there are issues in the MQTT message delivery process at Quality of Service (QoS) level 2, which could lead to message loss or duplicated messages. An unsuccessful PUBCOMP occurs when the recipient of a PUBLISH message (subscriber) acknowledges reception but encounters a problem while processing the message. The PUBCOMP packet contains a Reason Code, indicating the outcome of processing the PUBLISH message. In a successful case, the code would be 0x00 (Success); otherwise, it would be one of the following: 0x80 (Unspecified Error), 0x83 (Implementation Specific Error), 0x87 (Not Authorized), 0xD0 (Packet Identifier in Use), or 0xD2 (Packet Identifier Not Found). Check the VerneMQ error logs: VerneMQ logs can provide valuable information on encountered errors or any misconfiguration that leads to unsuccessful PUBCOMP messages. Generally, their location is `/var/log/vernemq/console.log`, `/var/log/vernemq/error.log`, and `/var/log/vernemq/crash.log`. Review MQTT clients' logs: Inspect the logs of the MQTT clients that are publishing or subscribing to the messages on the VerneMQ broker. This may help you identify specific clients causing the problem or any pattern associated with unsuccessful PUBCOMP messages. Verify the Quality of Service (QoS) level: Check if the QoS level for PUBCOMP packets is set to 2, as required. If necessary, adjust the settings for the MQTT clients to match the expected QoS level. Investigate authorization and access control: If the Reason Code is related to authorization (0x87), verify that the MQTT clients involved have the correct permissions to publish and subscribe to the topics in question. Make sure that the VerneMQ Access Control List (ACL) or external authentication mechanisms are correctly configured. Monitor network connectivity: Unsuccessful PUBCOMP messages could be due to network issues between the MQTT clients and the VerneMQ broker. Monitor and analyze network latency or packet loss between clients and the VerneMQ server to identify any potential issues.
Project: Netdata (Observability and Analysis / Observability)
File: docker_container_unhealthy.md

This alert, `dockercontainerunhealthy`, is triggered when the health status of a Docker container is marked as unhealthy. If you receive this alert, it means that one of your Docker containers is not functioning properly, which can affect the services or applications running inside the container. The container health status is a Docker feature that allows you to define custom health checks to verify the proper functioning of your containers. If a container has a health check defined, Docker will execute it at regular intervals to monitor the container's health. If the health check fails a specific number of times in a row, Docker will mark the container as unhealthy, and this alert will be triggered. Identify the affected container: Find the container name in the alert's info field: `${label:container_name} docker container health status is unhealthy`. Use this container name in the following steps. Check the logs of the affected container: Use the `docker logs` command to view the logs of the unhealthy container. This may provide information on what caused the container to become unhealthy. ``` docker logs <container_name> ``` Inspect the container's health check configuration: Use the `docker inspect` command to view the health check settings for the affected container. Look for any misconfigurations that could lead to the container being marked as unhealthy. ``` docker inspect <container_name> --format='{{json .Config.Healthcheck}}' ``` Check the container's health status history: Use the `docker inspect` command again to review the health check history for the affected container. ``` docker inspect <container_name> --format='{{json .State.Health}}' ``` Investigate and fix container issues: Based on the information gathered from the previous steps, investigate and fix any issues with the container's service, configuration, or resources. You might need to restart the container or reconfigure its health check settings. ``` docker restart <container_name> ```
Project: Beats (Observability and Analysis / Observability)
File: NOTES.md

TODO: Check if truncation checks work es expected Test local folder on host, mounted by all Questions: Should we use Data volumes or Data volume containers? https://docs.docker.com/engine/tutorials/dockervolumes/ Problems On volume per container: How do we add voumes dynamically to a container? Inodes are always reused on volumes -> typical on docker volumes as nothing else happens
Project: Checkmk (Observability and Analysis / Observability)
File: 16499.md

key | value | date | 2024-02-12T12:20:21+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Prior to this werk, the snmp detect condition was too restrictive which excluded subsequently new devices. Those new devices had another oid section following the initial condition. This werk makes the detect condition more lenient to allow discovery of those devices.
Project: Checkmk (Observability and Analysis / Observability)
File: 16588.md

key | value | date | 2024-04-17T09:19:29+00:00 version | 2.4.0b1 class | fix edition | cre component | wato level | 1 compatible | yes This Werk solves a problem with importing events that take more than one day. Before this Werk, only the first day of the event was imported. Now all days involved are imported.
Project: Checkmk (Observability and Analysis / Observability)
File: 16619.md

key | value | date | 2024-03-11T12:46:16+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | no Rulespec/ruleset names now have to be valid that are not . This also applies to choice identifiers in FormSpecs. The validation occurs during instantiation and will raise a `ValueError` when a violation is found.
Project: Grafana Loki (Observability and Analysis / Observability)
File: CHANGES.md

Migrated to godep, as depman is not longer supported Introduced golang vendoring feature Fixed issue related to reopen deleted file Fix inotify watcher leak; remove `Cleanup` (#51) Don't return partial lines (PR #40) Use stable version of fsnotify (#46) Fix tail for Windows (PR #36) Improved rate limiting using leaky bucket (PR #29) Fix odd line splitting (PR #30) LimitRate now discards read buffer (PR #28) allow reading of longer lines if MaxLineSize is unset (PR #24) updated deps.json to latest fsnotify (441bbc86b1) added `Config.Logger` to suppress library logging add Cleanup to remove leaky inotify watches (PR #20) redesigned Location field (PR #12) add tail.Tell (PR #14) Rate limiting (PR #10) Detect file deletions/renames in polling file watcher (PR #1) Detect file truncation Fix potential race condition when reopening the file (issue 5) Fix potential blocking of `tail.Stop` (issue 4) Fix uncleaned up ChangeEvents goroutines after calling tail.Stop Support Follow=false Initial open source release
Project: Weave Scope (Observability and Analysis / Observability)
File: VENDORED_CODE.md

Weave Scope is licensed under the . Some vendored code is under different licenses though, all of them ship the entire license text they are under. https://github.com/weaveworks/go-checkpoint https://github.com/weaveworks/go-cleanhttp https://github.com/certifi/gocertifi can be found in the ./vendor/ directory, is under MPL-2.0. Pulled in by dependencies are https://github.com/hashicorp/go-version (MPL-2.0) https://github.com/hashicorp/golang-lru (MPL-2.0) One file pulled in by a dependency is under CDDL: ./vendor/github.com/howeyc/gopass/terminal_solaris.go The docs of a dependency that's pulled in by a dependency are under CC-BY 4.0: ./vendor/github.com/docker/go-units/ is under LGPL-3, that's why we ship the license text in this repository.
Project: K8sGPT (Observability and Analysis / Observability)
File: pull_request_template.md

<!-- Thanks for creating this pull request Please make sure that the pull request is limited to one type (docs, feature, etc.) and keep it as small as possible. You can open multiple prs instead of opening a huge one. --> <!-- If this pull request closes an issue, please mention the issue number below --> Closes # <!-- Issue # here --> <!-- Add a brief description of the pr --> <!-- Make sure your pr passes the CI checks and do check the following fields as needed - --> [ ] My pull request adheres to the code style of this project [ ] My code requires changes to the documentation [ ] I have updated the documentation as required [ ] All the tests have passed <!-- Any additional information like breaking changes, dependencies added, screenshots, comparisons between new and old behavior, etc. -->
Project: HertzBeat (Observability and Analysis / Observability)
File: jetty.md

id: jetty title: Monitoring Jetty Web Server sidebar_label: Jetty Web Server keywords: [open source monitoring tool, open source jetty web server monitoring tool, monitoring jetty metrics] Collect and monitor general performance metrics of Jetty application server Usage protocol: JMX You need to enable the `JMX` service in the JVM application. HertzBeat uses the JMX protocol to collect metrics for the JVM. Start the JMX JMX-REMOTE module in Jetty ```shell java -jar $JETTY_HOME/start.jar --add-module=jmx java -jar $JETTY_HOME/start.jar --add-module=jmx-remote ``` Successful command execution will create `${JETTY_BASE}/start.d/jmx-remote.ini` configuration file Edit the `${JETTY_BASE}/start.d/jmx-remote.ini` configuration file to modify the JMX IP port and other parameters. `localhost` needs to be modified to expose the IP ```text -Djava.rmi.server.hostname=localhost ``` Restart Jetty Server. | Parameter name | Parameter help description | ||| | Monitoring Host | Monitored IPV4, IPV6 or domain name. NoteWithout protocol header (eg: https://, http://) | | Monitoring name | Identify the name of this monitoring. The name needs to be unique | | Port | Port provided by JMX | | Username | JMX connection user name, optional | | Password | JMX connection password, optional | | Collection interval | Interval time of monitor periodic data collection, unit: second, and the minimum interval that can be set is 30 seconds | | Whether to detect | Whether to detect and check the availability of monitoring before adding monitoring. Adding and modifying operations will continue only after the detection is successful | | Description remarks | For more information about identifying and describing this monitoring, users can note information here | | Metric name | Metric unit | Metric help description | |-|-|-| | name | | metrics name | | committed | kb | total size | | init | kb | init size | | max | kb | max size | | used | kb | used size | | Metric name | Metric unit | Metric help description | |--|-|--| | LoadedClassCount | | Loaded Class Count | | TotalLoadedClassCount | | Total Loaded Class Count | | UnloadedClassCount | | Unloaded Class Count | | Metric name | Metric unit | Metric help description | |-|-|-| | TotalStartedThreadCount | | Total Started Thread Count | | ThreadCount | | Thread Count | | PeakThreadCount | | Peak Thread Count | | DaemonThreadCount | | Daemon Thread Count | | CurrentThreadUserTime | ms | Current Thread User Time | | CurrentThreadCpuTime | ms | Current Thread Cpu Time |
Project: HertzBeat (Observability and Analysis / Observability)
File: kafka.md

id: kafka title: MonitorApache Kafka sidebar_label: Apache Kafka keywords: [open source monitoring tool, open source apache kafka monitoring tool, monitoring apache kafka metrics] Collect and monitor the general performance Metrics of Apache Kafka. Protocol UseJMX Install Kafka Modify `kafka-server-start.sh` Append content in kafka-server-start.sh, Attention Replace Port And IP. ```shell export JMX_PORT=9999; export KAFKAJMXOPTS="-Djava.rmi.server.hostname=ip -Dcom.sun.management.jmxremote.rmi.port=9999 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"; exec $basedir/kafka-run-class.sh $EXTRAARGS kafka.Kafka "$@" ``` | Parameter name | Parameter help description | | -- | -- | | Monitoring Host | Monitored IPV4, IPV6 or domain name. NoteWithout protocol header (eg: https://, http://) | | Monitoring name | Identify the name of this monitoring. The name needs to be unique | | Port | Port provided by JMX | | Username | JMX connection user name, optional | | Password | JMX connection password, optional | | Collection interval | Interval time of monitor periodic data collection, unit: second, and the minimum interval that can be set is 30 seconds | | Whether to detect | Whether to detect and check the availability of monitoring before adding monitoring. Adding and modifying operations will continue only after the detection is successful | | Description remarks | For more information about identifying and describing this monitoring, users can note information here | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | Version | | Kafka Version | | StartTimeMs | ms | Start Time | | CommitId | | Version Commit ID | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | name | | metrics name | | committed | kb | total size | | init | kb | init size | | max | kb | max size | | used | kb | used size | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | Value | | server active controller count | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | Value | | broker partition count | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | Value | | broker leader count | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | EventType | | event type | | RateUnit | | rate unit | | Count | | percent count | | OneMinuteRate | % | One Minute Rate | | FiveMinuteRate | % | Five Minute Rate | | MeanRate | % | Mean Rate | | FifteenMinuteRate | % | Fifteen Minute Rate |
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: akridata.md

is a startup building a platform for edge to core AI data pipelines relevant to various domains like autonomous vehicles, oil & gas etc. To execute pod chaos experiments in Kubernetes clusters on AWS & Azure cloud Litmus is being used as part of the QA cycles to catch bugs & verify resiliency. We needed a clean way to introduce anomolies in the system to figure out its behaviour, Litmus was the one that was clean and easy to use
Project: SkyWalking (Observability and Analysis / Observability)
File: backend-expose.md

SkyWalking has default activated gRPC/HTTP servers in the core module, which serve for both internal communication and external data report or query. In some advanced scenarios, such as security requirements, specific gRPC/HTTP servers should be exposed for external requests. ```yaml receiver-sharing-server: selector: ${SWRECEIVERSHARING_SERVER:default} default: restHost: ${SWRECEIVERSHARINGRESTHOST:0.0.0.0} restPort: ${SWRECEIVERSHARINGRESTPORT:0} restContextPath: ${SWRECEIVERSHARINGRESTCONTEXT_PATH:/} restMaxThreads: ${SWRECEIVERSHARINGRESTMAX_THREADS:200} restIdleTimeOut: ${SWRECEIVERSHARINGRESTIDLE_TIMEOUT:30000} restAcceptQueueSize: ${SWRECEIVERSHARINGRESTQUEUE_SIZE:0} httpMaxRequestHeaderSize: ${SWRECEIVERSHARINGHTTPMAXREQUESTHEADER_SIZE:8192} gRPCHost: ${SWRECEIVERGRPC_HOST:0.0.0.0} gRPCPort: ${SWRECEIVERGRPC_PORT:0} maxConcurrentCallsPerConnection: ${SWRECEIVERGRPCMAXCONCURRENT_CALL:0} maxMessageSize: ${SWRECEIVERGRPCMAXMESSAGE_SIZE:0} gRPCThreadPoolSize: ${SWRECEIVERGRPCTHREADPOOL_SIZE:0} gRPCSslEnabled: ${SWRECEIVERGRPCSSLENABLED:false} gRPCSslKeyPath: ${SWRECEIVERGRPCSSLKEY_PATH:""} gRPCSslCertChainPath: ${SWRECEIVERGRPCSSLCERTCHAINPATH:""} gRPCSslTrustedCAsPath: ${SWRECEIVERGRPCSSLTRUSTEDCASPATH:""} authentication: ${SW_AUTHENTICATION:""} ``` Set `restPort`(HTTP) and `gRPCPort`(gRPC) to a legal port(greater than 0), would initialize new gRPC/HTTP servers for external requests with other relative settings. In this case, `core/gRPC` and `core/rest` could be served for cluster internal communication only.
Project: Netdata (Observability and Analysis / Observability)
File: btrfs_metadata.md

The `btrfs_metadata` alert calculates the percentage of used Btrfs metadata space for a Btrfs filesystem. If you receive this alert, it indicates that your Btrfs filesystem's metadata space is being utilized at a high rate. Warning: Data is valuable. Before performing any actions, make sure to take necessary backup steps. Netdata is not responsible for any loss or corruption of data, database, or software. Add more physical space Determine which disk you want to add and in which path: ``` root@netdata~ # btrfs device add -f /dev/<new_disk> <path> ``` If you get an error that the drive is already mounted, you might have to unmount: ``` root@netdata~ # btrfs device add -f /dev/<new_disk> <path> ``` Check the newly added disk: ``` root@netdata~ # btrfs filesystem show ``` Balance the system to make use of the new drive: ``` root@netdata~ # btrfs filesystem balance <path> ``` Delete snapshots List the snapshots for a specific path: ``` root@netdata~ # sudo btrfs subvolume list -s <path> ``` Delete an unnecessary snapshot: ``` root@netdata~ # btrfs subvolume delete <path>/@some_dir-snapshot-test ``` Enable a compression mechanism Apply compression to existing files by modifying the `fstab` configuration file (or during the `mount` procedure) with the `compress=alg` option. Replace `alg` with `zlib`, `lzo`, `zstd`, or `no` (for no compression). For example, to re-compress the `/mount/point` path with `zstd` compression: ``` root@netdata # btrfs filesystem defragment -r -v -czstd /mount/point ``` Enable a deduplication mechanism Deduplication tools like duperemove, bees, and dduper can help identify blocks of data sharing common sequences and combine extents via copy-on-write semantics. Ensure you check the status of these 3rd party tools before using them. - Perform a balance Balance data/metadata/system-data in empty or near-empty chunks for Btrfs filesystems with multiple disks, allowing space to be reassigned: ``` root@netdata # btrfs balance start -musage=50 -dusage=10 -susage=5 /mount/point ```