cwielenb/CNCF-Dataset huggingface dataset:
Project: Vector (Observability and Analysis / Observability)
File: 2020-12-23-internal-logs-source.md

date: "2020-12-23" title: "The `internal_logs` source" description: "A new source for observing Vector itself" authors: ["lucperkins"] pr_numbers: [] release: "0.12.0" hideonrelease_notes: false badges: type: "new feature" sources: ["internal_logs"] Vector has a new source that you can use to process log events produced by Vector itself. Here's an example Vector log message: ```json { "*": null, "message": "Vector has started.", "metadata": { "kind": "event", "level": "TRACE", "modulepath": "vector::internalevents::heartbeat", "target": "vector" }, "timestamp": "2020-10-10T17:07:36+00:00" } ``` `internal_logs` is a helpful accompaniment to the source, which exports Vector's own metrics and modify and ship them however you wish. Here's an example Vector configuration that ships Vector's logs to Splunk and allows its internal metrics to be scraped by [Prometheus]: ```toml [sources.vector_logs] type = "internal_logs" [sources.vector_metrics] type = "internal_metrics" [sinks.splunk] type = "splunk_hec" inputs = ["vector_logs"] endpoint = "https://my-account.splunkcloud.com" token = "${SPLUNKHECTOKEN}" encoding.codec = "json" [sinks.prometheus] type = "prometheus" inputs = ["vector_metrics"] address = "0.0.0.0:9090" ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16549.md

key | value | date | 2024-03-01T08:43:58+00:00 version | 2.4.0b1 class | fix edition | cee component | agents level | 1 compatible | no On some Solaris 10 systems, an agent update did crash with error message ``` /var/sadm/pkg/check-mk-agent/install/postremove: syntax error at line 19: `(' unexpected pkgrm: ERROR: postremove script did not complete successfully ``` If you ran into this error, to make the update perform again, please delete the file `/var/sadm/pkg/check-mk-agent/install/postremove` on affected systems. Technical background:\ The postremove script used the subshell evaluation syntax `$(...)` that is incompatible to the standard `bin/sh` shell found on some Solaris 10 systems.
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: process.md

title: 'Using snapshot process' weight: 20 description: > Gather information about running processes. The snapshot process gadget gathers information about running processes. Let's start this demo by creating a namespace: ```bash $ kubectl create ns demo namespace/demo created ``` There is not any running process in the `demo` namespace now: ```bash $ kubectl gadget snapshot process -n demo K8S.NODE K8S.NAMESPACE K8S.POD K8S.CONTAINER COMM PID UID GID ``` Create a pod on the `demo` namespace using the `nginx` image: ```bash $ kubectl -n demo run mypod --image=nginx pod/mypod created $ kubectl wait -n demo --for=condition=ready pod/mypod pod/mypod condition met ``` After the pod is running, we can try to get the list of running processes again: ```bash $ kubectl gadget snapshot process -n demo K8S.NODE K8S.NAMESPACE K8S.POD K8S.CONTAINER COMM PID UID GID ubuntu-hirsute demo mypod mypod nginx 411928 0 0 ubuntu-hirsute demo mypod mypod nginx 411964 101 101 ubuntu-hirsute demo mypod mypod nginx 411965 101 101 ubuntu-hirsute demo mypod mypod nginx 411966 101 101 ubuntu-hirsute demo mypod mypod nginx 411967 101 101 ubuntu-hirsute demo mypod mypod nginx 411968 101 101 ubuntu-hirsute demo mypod mypod nginx 411969 101 101 ubuntu-hirsute demo mypod mypod nginx 411970 101 101 ubuntu-hirsute demo mypod mypod nginx 411971 101 101 ``` We can see the different `nginx` process started within the container. Execute an instance of `sleep` on the pod: ```bash $ kubectl -n demo exec mypod -- /bin/sh -c "sleep 1000 &" ``` Now there is an additional `sleep` processes running in `mypod`: ```bash $ kubectl gadget snapshot process -n demo K8S.NODE K8S.NAMESPACE K8S.POD K8S.CONTAINER COMM PID UID GID ubuntu-hirsute demo mypod mypod nginx 411928 0 0 ubuntu-hirsute demo mypod mypod nginx 411964 101 101 ubuntu-hirsute demo mypod mypod nginx 411965 101 101 ubuntu-hirsute demo mypod mypod nginx 411966 101 101 ubuntu-hirsute demo mypod mypod nginx 411967 101 101 ubuntu-hirsute demo mypod mypod nginx 411968 101 101 ubuntu-hirsute demo mypod mypod nginx 411969 101 101 ubuntu-hirsute demo mypod mypod nginx 411970 101 101 ubuntu-hirsute demo mypod mypod nginx 411971 101 101 ubuntu-hirsute demo mypod mypod sleep 412550 0 0 ``` Delete the demo test namespace: ```bash $ kubectl delete ns demo namespace "demo" deleted ``` Create a container that runs sleep inside: ```bash $ docker run --name test-snapshot-process -it --rm busybox /bin/sh -c 'sleep 100' ``` Run the snapshot process gadget, it'll print all process in the container: ```bash $ sudo ig snapshot process -c test-snapshot-process RUNTIME.CONTAINERNAME COMM PID UID GID test-snapshot-process sh 329491 0 0 ```
Project: Netdata (Observability and Analysis / Observability)
File: 1m_tcp_accept_queue_drops.md

This alert presents the average number of dropped packets in the TCP accept queue over the last sixty seconds. If it is raised, then the system is dropping incoming TCP connections. This could also be an indication of accepted queue overflow, low memory, security issues, no route to a destination, etc. This alert gets raised to warning when the value is greater than 1 and less than 5. If the number of queue drops over the last minute exceeds 5, then the alert gets raised to critical. The accept queue holds fully established TCP connections waiting to be handled by the listening application. It overflows when the server application fails to accept new connections at the rate they are coming in. Check for queue overflows. If you receive this alert, then you can cross-check its results with the `1mtcpacceptqueueoverflows` alert. If that alert is also in a warning or critical state, then the system is experiencing accept queue overflowing. To fix that you can do the following: Open the /etc/sysctl.conf file and look for the entry " net.ipv4.tcpmaxsyn_backlog". The `tcpmaxsynbacklog` is the maximal number of remembered connection requests (SYNRECV), which have not received an acknowledgment from connecting client. If the entry does not exist, then append the following default entry to the file; `net.ipv4.tcpmaxsyn_backlog=1280`. Otherwise, adjust the limit to suit your needs. Save your changes and run: ``` sysctl -p ``` Note: Netdata strongly suggests knowing exactly what values you need before making system changes.
Project: Netdata (Observability and Analysis / Observability)
File: portcheck_connection_fails.md

This alert indicates that too many connections are failing to a specific TCP endpoint in the last 5 minutes. It suggests that the monitored service on that endpoint is most likely down, unreachable, or access is being denied by firewall/security rules. Check the service Investigate if the service at the endpoint (specific IP and port) is running as expected. Inspect service logs for issues, error messages, or indications of a shutdown event. Test the endpoint Try to establish a connection to the flagged endpoint using tools like `telnet`, `curl`, or `nc`. These tools provide real-time feedback that can help identify problems with the endpoint: Example using `telnet`: ``` telnet IPADDRESS PORTNUMBER ``` Examine firewall and security group rules Verify if there are any recent changes or newly added firewall/security group rules that might be causing the connectivity issues. Look for any rules that could be blocking the monitored port specifically or the IP range. Inspect network connectivity Check the network connectivity between the Netdata Agent and the monitored endpoint. Ensure there are no intermittent network failures or high latency affecting the communication between the two. Examine the alert configuration Validate the alert configuration in the `netdata.conf` file to confirm that the alert thresholds and monitored percentage of failed connections are set appropriately. Check resource utilization High resource utilization might affect the availability of the monitored endpoint. Check if the system hosting the service has enough resources available (CPU, memory, and storage) to serve incoming requests.
Project: Tracetest (Observability and Analysis / Observability)
File: tracetest_server_install.md

Install a new Tracetest server Install a new Tracetest server ``` tracetest server install [flags] ``` ``` -f, --force Overwrite existing files -h, --help help for install --kubernetes-context string Kubernetes context used to install Tracetest. It will be only used if 'run-environment' is set as 'kubernetes'. --mode (with-demo|just-tracetest) Indicate the type of demo environment to be installed with Tracetest. It can be 'with-demo' or 'just-tracetest'. (default none) --run-environment (docker|kubernetes) Type of environment were Tracetest will be installed. It can be 'docker' or 'kubernetes'. (default none) ``` ``` -c, --config string config file will be used by the CLI (default "config.yml") -o, --output string output format [pretty|json|yaml] -s, --server-url string server url -v, --verbose display debug information ``` - Manage your tracetest server
Project: Elastic (Observability and Analysis / Observability)
File: to_double.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Converts an input value to a double value. If the input parameter is of a date type, its value will be interpreted as milliseconds since the Unix epoch, converted to double. Boolean true will be converted to double 1.0, false to 0.0. ``` ROW str1 = "5.20128E11", str2 = "foo" | EVAL dbl = TODOUBLE("520128000000"), dbl1 = TODOUBLE(str1), dbl2 = TO_DOUBLE(str2) ```
Project: Netdata (Observability and Analysis / Observability)
File: hdfs_stale_nodes.md

The `hdfsstalenodes` alert is triggered when there is at least one stale DataNode in the Hadoop Distributed File System (HDFS) due to missed heartbeats. A stale DataNode is one that has not been reachable for `dfs.namenode.stale.datanode.interval` (default is 30 seconds). Stale DataNodes are avoided and marked as the last possible target for a read or write operation. Identify the stale node(s) Run the following command to generate a report on the state of the HDFS cluster: ``` hadoop dfsadmin -report ``` Inspect the output and look for any stale DataNodes. Check the DataNode logs and system services status Connect to the identified stale DataNode and check the log of the DataNode for any issues. Also, check the status of the system services. ``` systemctl status hadoop ``` If required, restart the HDFS service: ``` systemctl restart hadoop ``` Monitor the HDFS cluster After resolving issues identified in the logs or restarting the service, continue to monitor the HDFS cluster to ensure the problem is resolved. Re-run the `hadoop dfsadmin -report` command to check if the stale DataNode status has been cleared. Ensure redundant data storage To protect against data loss or unavailability, HDFS stores data in multiple nodes, providing fault tolerance. Make sure that the replication factor for your HDFS cluster is set correctly, typically with a factor of 3, so that data is stored on three different nodes. A higher replication factor will increase data redundancy and reliability. Review HDFS cluster configuration Examine the HDFS cluster's configuration settings to ensure that they are appropriate for your specific use case and hardware setup. Identifying performance bottlenecks, such as slow or unreliable network connections, can help avoid stale DataNodes in the future.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_cluster.AuthRequestResourceAttrs.md

title: "Interface: AuthRequestResourceAttrs" linkTitle: "AuthRequestResourceAttrs" slug: "libk8scluster.AuthRequestResourceAttrs" .AuthRequestResourceAttrs `Optional` group: `string` _ `Optional` name: `string` _ `Optional` namespace: `string` _ `Optional` resource: `string` _ `Optional` subresource: `string` _ `Optional` verb: `string` _ `Optional` version: `string`
Project: Netdata (Observability and Analysis / Observability)
File: mysql_replication_lag.md

This alert presents the number of seconds that the replica is behind the master. Receiving this means that the replication SQL thread is far behind processing the source binary log. A constantly high value (or an increasing one) indicates that the replica is unable to handle events from the source in a timely fashion. This alert is raised into warning when the metric exceeds 10 seconds. If the number of seconds that the replica is behind the master exceeds 30 seconds then the alert is raised into critical. Query optimization and "logslowslave_statements" To minimize slave `SQL_THREAD` lag, focus on query optimization. The following logs will help you identify the problem: Enable to see queries executed by slave that take more than . To get more information about query performance, set the configuration option to `full`. You can also read the Percona blog for a nice write-up about. [Replication in MySQL]( https://www.digitalocean.com/community/tutorials/how-to-set-up-replication-in-mysql) [MySQL Replication Slave Lag]( https://www.percona.com/blog/2014/05/02/how-to-identify-and-cure-mysql-replication-slave-lag/) [logslowslave_statements]( https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#sysvarlogslowslavestatements) [longquerytime]( https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvarlongquery_time) [logslowverbosity]( https://www.percona.com/doc/percona-server/5.1/diagnostics/slowextended.html?id=percona-server:features:slowextended51&redirect=2#logslow_verbosity)
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: slack.md

sidebar_position: 1 The Slack notifier allows you to get notification on your favorite slack channel when an instance of `go-feature-flag` is detecting changes in the configuration file. <center><img src="/docs/notifier/slack_notification.png" /></center> First, you need to create an incoming webhook on your slack instance. You can follow this Copy your webhook URL. It should look like: `https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX`. In your init method add a slack notifier ```go linenums="1" hl_lines="5" ffclient.Config{ // ... Notifiers: []notifier.Notifier{ &slacknotifier.Notifier{ SlackWebhookURL: "https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX", }, // ... }, } ``` | Field | Description | ||| |`SlackWebhookURL` | The complete URL of your incoming webhook configured in Slack. |
Project: Flipt (Observability and Analysis / Feature Flagging)
File: RELEASE.md

This document describes the release process for Flipt. The release process is managed by the and is triggered by pushing a tag to the repository that matches the pattern `v*` (e.g. `v1.0.0`). Flipt is currently released as a single binary for Linux (arm64 and amd64) and macOS (arm64). The release process builds the binary for each platform and uploads them to the . We also publish a Docker image for each release to and . We use GitHub Actions and to build and publish Flipt releases. We support three main types of releases: Stable releases (e.g. `v1.0.0`) Snapshot releases (e.g. `v1.0.0-snapshot`) Nightly releases (e.g. `v1.0.0-nightly`) The process for each looks roughly the same using GitHub Actions and GoReleaser Pro, but there are some differences in how the release is tagged and how the release is published. Create a new branch from `main` named `release/vX.Y.Z` (e.g. `release/v1.0.0`). Update the CHANGELOG.md with the release notes for the new version. (We have a `mage` task to help with this in the `build` directory.) Commit the changes and push the branch to GitHub. Create a pull request from the release branch to `main`. Once the pull request is merged, create a new tag on `main` with the version number (e.g. `v1.0.0`). Push the tag to GitHub. CI will build and publish the release to GitHub and Docker Hub. Snapshot releases are created on-demand and are used to test the build and release process for stable releases. To create a snapshot release, we run the workflow manually from the GitHub Actions UI. The snapshot release does not create an actual release, it simply builds the binaries and uploads them as artifacts to the workflow run. The artifacts can then be downloaded and tested. Nightly releases are created automatically every night at 23:30 UTC via the . The nightly release also does not create an actual release. Unlike the snapshot release, the nightly release does not upload the binaries as artifacts. Instead, the nightly release builds a Docker image and pushes it to Docker Hub and GitHub Container Registry (Linux arm and x64 only). The Docker image is tagged with the version number (e.g. `v1.0.0-nightly`). Currently the nightly release only builds the Docker image for Linux. We do not build a nightly release for macOS.
Project: SkyWalking (Observability and Analysis / Observability)
File: instance-properties.md

Service Instance Properties Service instance contains more information than just a name. In order for the agent to report service instance status, use `ManagementService#reportInstanceProperties` service to provide a string-key/string-value pair list as the parameter. The `language` of target instance must be provided as the minimum requirement. Service Ping Service instance should keep alive with the backend. The agent should set a scheduler using `ManagementService#keepAlive` service every minute. ```protobuf syntax = "proto3"; package skywalking.v3; option javamultiplefiles = true; option java_package = "org.apache.skywalking.apm.network.management.v3"; option csharp_namespace = "SkyWalking.NetworkProtocol.V3"; option go_package = "skywalking.apache.org/repo/goapi/collect/management/v3"; import "common/Common.proto"; import "common/Command.proto"; // Define the service reporting the extra information of the instance. service ManagementService { // Report custom properties of a service instance. rpc reportInstanceProperties (InstanceProperties) returns (Commands) { } // Keep the instance alive in the backend analysis. // Only recommend to do separate keepAlive report when no trace and metrics needs to be reported. // Otherwise, it is duplicated. rpc keepAlive (InstancePingPkg) returns (Commands) { } } message InstanceProperties { string service = 1; string serviceInstance = 2; repeated KeyStringValuePair properties = 3; // Instance belong layer name which define in the backend, general is default. string layer = 4; } message InstancePingPkg { string service = 1; string serviceInstance = 2; // Instance belong layer name which define in the backend, general is default. string layer = 3; } ``` Report service instance properties POST http://localhost:12800/v3/management/reportProperties Input: ```json { "service": "User Service Name", "serviceInstance": "User Service Instance Name", "properties": [ { "key": "language", "value": "Lua" } ] } ``` Output JSON Array: ```json {} ``` Service instance ping POST http://localhost:12800/v3/management/keepAlive Input: ```json { "service": "User Service Name", "serviceInstance": "User Service Instance Name" } ``` OutPut: ```json {} ```
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: spring-boot-experiments-tunables.md

It contains the Spring Boot specific experiment tunables. It contains number of requests are to be attacked, n value means each nth request will be affected. It can be tuned by `CM_LEVEL` ENV. Use the following example to tune this: ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: spring-boot-chaos namespace: default spec: appinfo: appns: 'default' applabel: 'app=spring-boot' appkind: 'deployment' engineState: 'active' chaosServiceAccount: spring-boot-app-kill-sa experiments: name: spring-boot-app-kill spec: components: env: name: CM_PORT value: '8080' name: CM_LEVEL value: '1' ``` It contains comma seperated list of fully qualified packages(class and/or method names), which limits watched packages/classes/methods. It can be tuned by `CMWATCHEDCUSTOM_SERVICES` ENV. Use the following example to tune this: ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: spring-boot-chaos namespace: default spec: appinfo: appns: 'default' applabel: 'app=spring-boot' appkind: 'deployment' engineState: 'active' chaosServiceAccount: spring-boot-app-kill-sa experiments: name: spring-boot-app-kill spec: components: env: name: CM_PORT value: '8080' name: CMWATCHEDCUSTOM_SERVICES value: 'com.example.chaosdemo.controller.HelloController.sayHello,com.example.chaosdemo.service.HelloService' ``` It contains comma separated list of watchers from the following watchers list [controller, restController, service, repository, component, webClient]. It can be tuned by `CM_WATCHERS` ENV. Use the following example to tune this: ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: spring-boot-chaos namespace: default spec: appinfo: appns: 'default' applabel: 'app=spring-boot' appkind: 'deployment' engineState: 'active' chaosServiceAccount: spring-boot-app-kill-sa experiments: name: spring-boot-app-kill spec: components: env: name: CM_PORT value: '8080' name: CM_WATCHERS value: 'restController' ```
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-7-5-7.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 7.5.7 <!-- Auto generated by update changelog github action --> Dockerfile: Fixes missing --no-cache. , Annotations: Prevent orphaned annotation tags cleanup when no annotations were cleaned. , Quota: Do not count folders towards dashboard quota. ,
Project: HertzBeat (Observability and Analysis / Observability)
File: alert_dingtalk.md

id: alert_dingtalk title: Alert DingDing robot notification sidebar_label: Alert DingDing robot notification keywords: [open source monitoring tool, open source alerter, open source DingDing robot notification] After the threshold is triggered send alarm information and notify the recipient by DingDing robot. DingDing desktop client-> Group settings-> Intelligent group assistant-> Add new robot-select custom-> Set robot name and avatar-> NoteSet custom keywords: HertzBeat ->Copy its webhook address after adding successfully Note When adding a robot, its custom keywords need to be set in the security setting block: HertzBeat. Other security settings or the IP segment don't need to be filled in. Save access_token value of the WebHook address of the robot eg webHook address`https://oapi.dingtalk.com/robot/send?access_token=43aac28a236e001285ed84e473f8eabee70f63c7a70287acb0e0f8b65fade64f` Its robot access_token value is `43aac28a236e001285ed84e473f8eabee70f63c7a70287acb0e0f8b65fade64f` Alarm notification->Add new recipient ->Select DingDing robot notification method->Set DingDing robot ACCESS_TOKEN-> Confirm Configure the associated alarm notification strategy Add new notification strategy-> Associate the recipient just set-> Confirm Note Adding a new recipient does not mean that it is effective to receive alarm information. It is also necessary to configure the associated alarm notification strategy, that is, to specify which messages are sent to which recipients. DingDing group did not receive the robot alarm notification. Please check whether there is any triggered alarm information in the alarm center. Please check whether DingDing robot is configured with security custom keywords HertzBeat. Please check whether the robot ACCESS_TOKEN is configured correctly and whether the alarm strategy association is configured. Other issues can be fed back through the communication group ISSUE!