cwielenb/CNCF-Dataset huggingface dataset:
Project: Netdata (Observability and Analysis / Observability)
File: portcheck_connection_timeouts.md

The `portcheckconnectiontimeouts` alert calculates the average ratio of connection timeouts when trying to connect to a TCP endpoint over the last 5 minutes. If you receive this alert, it means that the monitored TCP endpoint is unreachable, potentially due to networking issues or an overloaded host/service. This alert triggers a warning state when the ratio of timeouts is between 10-40% and a critical state if the ratio is greater than 40%. Check the network connectivity Use the `ping` command to check network connectivity between your system and the monitored TCP endpoint. ``` ping <tcpendpointip> ``` If the connectivity is intermittent or not established, it indicates network issues. Reach out to your network administrator for assistance. Check the status of the monitored TCP service Identify the service running on the monitored TCP endpoint by checking the port number. Use the `netstat` command to check the service status: ``` netstat -tnlp | grep <port_number> ``` If the service is not running or unresponsive, restart the service or investigate further into the application logs for any issues. Verify the load on the TCP endpoint host Connect to the host and analyze its resource consumption (CPU, memory, disk I/O, and network bandwidth) with tools like `top`, `vmstat`, `iostat`, and `iftop`. Identify resource-consuming processes or applications and apply corrective measures (kill/restart the process, allocate more resources, etc.). Examine the firewall rules and security groups Ensure that there are no blocking rules or security groups for your incoming connections to the TCP endpoint. If required, update the rules or create new allow rules for the required ports and IP addresses. Check the Netdata configuration Review the Netdata configuration file `/etc/netdata/netdata.conf` to ensure the `portcheck` plugin settings are correctly configured for monitoring the TCP endpoint. If necessary, update and restart the Netdata agent.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: logging_types.md

title: LoggingSpec weight: 200 generated_file: true LoggingSpec defines the desired state of Logging Allow configuration of cluster resources from any namespace. Mutually exclusive with ControlNamespace restriction of Cluster resources Cluster domain name to be used when templating URLs to services . Default: "cluster.local." ConfigCheck settings that apply to both fluentd and syslog-ng Namespace for cluster wide configuration resources like ClusterFlow and ClusterOutput. This should be a protected namespace from regular users. Resources like fluentbit and fluentd will run in this namespace as well. Default flow for unmatched logs. This Flow configuration collects all logs that didn't matched any other Flow. EnableRecreateWorkloadOnImmutableFieldChange enables the operator to recreate the fluentbit daemonset and the fluentd statefulset (and possibly other resource in the future) in case there is a change in an immutable field that otherwise couldn't be managed with a simple update. GlobalOutput name to flush ERROR events to Disable configuration check before applying new fluentd configuration. Override generated config. This is a raw configuration string for troubleshooting purposes. FluentbitAgent daemonset configuration. Deprecated, will be removed with next major version Migrate to the standalone NodeAgent resource Fluentd statefulset configuration Global filters to apply on logs before any match or filter mechanism. Reference to the logging system. Each of the `loggingRef`s can manage a fluentbit daemonset and a fluentd statefulset. InlineNodeAgent Configuration Deprecated, will be removed with next major version Whether to skip invalid Flow and ClusterFlow resources Syslog-NG statefulset configuration WatchNamespaceSelector is a LabelSelector to find matching namespaces to watch as in WatchNamespaces Limit namespaces to watch Flow and Output custom resources. Labels to use for the configcheck pods on top of labels added by the operator by default. Default values can be overwritten. Select the config check strategy to use. `DryRun`: Parse and validate configuration. `StartWithTimeout`: Start with given configuration and exit after specified timeout. Default: `DryRun` Configure timeout in seconds if strategy is StartWithTimeout LoggingStatus defines the observed state of Logging Result of the config check. Under normal conditions there is a single item in the map with a bool value. Available in Logging operator version 4.5 and later. Name of the matched detached fluentd configuration object. Problems with the logging resource Count of problems for printcolumn Available in Logging operator version 4.5 and later. Name of the matched detached SyslogNG configuration object. List of namespaces that watchNamespaces + watchNamespaceSelector is resolving to. Not set means all namespaces. Logging is the Schema for the loggings API LoggingList contains a list of Logging DefaultFlowSpec is a Flow for logs that did not match any other Flow Deprecated
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: syslogng_output_types.md

title: SyslogNGOutputSpec weight: 200 generated_file: true SyslogNGOutputSpec defines the desired state of SyslogNGOutput Available in Logging operator version 4.4 and later. Available in Logging operator version 4.5 and later. Available in Logging operator version 4.4 and later. SyslogNGOutput is the Schema for the syslog-ng outputs API SyslogNGOutputList contains a list of SyslogNGOutput
Project: HertzBeat (Observability and Analysis / Observability)
File: alert_wework.md

id: alert_wework title: Alert enterprise Wechat notification sidebar_label: Alert enterprise Wechat notification keywords: [open source monitoring tool, open source alerter, open source WeWork notification] After the threshold is triggered send alarm information and notify the recipient by enterprise Wechat robot. Enterprise Wechat-> Group settings-> Group robot-> Add new robot-> Set robot name and avatar-> Copy its webhook address after adding successfully Save the key value of the WebHook address of the robot eg webHook address`https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=3adafc96-23d0-4cd5-8feb-17f6e0b5fcs4` Its robot KEY value is `3adafc96-23d0-4cd5-8feb-17f6e0b5fcs4` Alarm notification->Add new recipient ->Select enterprise Wechat robot notification method->Set enterprise Wechat robot KEY-> 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. The enterprise wechat group did not receive the robot alarm notification. Please check whether there is any triggered alarm information in the alarm center. Please check whether the robot key is configured correctly and whether the alarm strategy association is configured. Other issues can be fed back through the communication group ISSUE!
Project: Grafana Loki (Observability and Analysis / Observability)
File: pack.md

title: pack menuTitle: description: The 'pack' Promtail pipeline stage. aliases: ../../../clients/promtail/stages/pack/ weight: The `pack` stage is a transform stage which lets you embed extracted values and labels into the log line by packing the log line and labels inside a JSON object. For example, if you wanted to remove the labels `container` and `pod` but still wanted to keep their values you could use this stage to create the following output: ```json { "container": "myapp", "pod": "pod-3223f", "_entry": "original log message" } ``` The original message will be stored under the `_entry` key. This stage is useful if you have some label or other metadata you would like to keep but it doesn't make a good label (isn't useful for querying or is too high cardinality) The querying capabilities of Loki make it easy to still access this data and filter/aggregate on it at query time. ```yaml pack: labels: [<string>] [ingest_timestamp: <bool> | default = true] ``` Removing the container label and embed it into the log line (Kubernetes pods could have multiple containers) ```yaml pack: labels: container ``` This would create a log line ```json { "container": "myapp", "_entry": "original log message" } ``` Loki 2.2 also includes a new to work with the pack stage. For example: ```logql {cluster="us-central1", job="myjob"} | unpack ``` Will automatically unpack embedded labels and log line and replace the log line with the original log line automatically. Use the packed labels for filtering: ```logql {cluster="us-central1", job="myjob"} | unpack | container="myapp" ``` You can even use the `json` parser twice if your original message was json: ```logql {cluster="us-central1", job="myjob"} | unpack | container="myapp" | json | valfromoriginallogjson="foo" ``` Or any other parser ```logql {cluster="us-central1", job="myjob"} | unpack | container="myapp" | logfmt | valfromoriginallogjson="foo" ```
Project: Vector (Observability and Analysis / Observability)
File: 2020-03-04-encoding-whitelist-blacklist.md

date: "2020-04-13" title: "Whitelist and Blacklist Fields When Encoding" description: "More control over which fields are included when encoding" authors: ["binarylogic"] pr_numbers: [1915] release: "0.9.0" hideonrelease_notes: true badges: type: "new feature" domains: ["sinks"] We've added the ability to white-list and blacklist fields during the encoding process within . This is useful if you have metadata fields that you do not want to send downstream. For example, you might have an `application_id` fields that you use for partitioning, but you don't want to include it in the actual data since it would be duplicative. To use this feature see the new `encoding` options for each sink. For example, the .
Project: Grafana Loki (Observability and Analysis / Observability)
File: legacy-storage.md

title: Legacy storage menuTitle: description: Describes deprecated legacy storage options for Loki that are superseded by single store. weight: 1000 {{% admonition type="warning" %}} The concepts described on this page are considered legacy and pre-date the single store storage introduced in Loki 2.0. The usage of legacy storage for new installations is highly discouraged and documentation is meant for informational purposes in case of upgrade to a single store. {{% /admonition %}} The chunk store is Loki's long-term data store, designed to support interactive querying and sustained writing without the need for background maintenance tasks. It consists of: An index for the chunks. This index can be backed by: - A key-value (KV) store for the chunk data itself, which can be: - - {{% admonition type="note" %}} Unlike the other core components of Loki, the chunk store is not a separate service, job, or process, but rather a library embedded in the two services that need to access Loki data: the and . {{% /admonition %}} The chunk store relies on a unified interface to the "" stores (DynamoDB, Bigtable, and Cassandra) that can be used to back the chunk store index. This interface assumes that the index is a collection of entries keyed by: A hash key. This is required for all reads and writes. A range key. This is required for writes and can be omitted for reads, which can be queried by prefix or range. The interface works somewhat differently across the supported databases: DynamoDB supports range and hash keys natively. Index entries are thus modelled directly as DynamoDB entries, with the hash key as the distribution key and the range as the DynamoDB range key. For Bigtable and Cassandra, index entries are modelled as individual column values. The hash key becomes the row key and the range key becomes the column key. A set of schemas are used to map the matchers and label sets used on reads and writes to the chunk store into appropriate operations on the index. Schemas have been added as Loki has evolved, mainly in an attempt to better load balance writes and improve query performance.
Project: HertzBeat (Observability and Analysis / Observability)
File: jvm.md

id: jvm title: Monitoring JVM sidebar_label: JVM Monitor keywords: [open source monitoring tool, open source java jvm monitoring tool, monitoring jvm metrics] Collect and monitor the general performance Metrics of JVM. Protocol UseJMX Add JVM `VM options` When Start Server customIP Refer: https://docs.oracle.com/javase/1.5.0/docs/guide/management/agent.html#remote ```shell -Djava.rmi.server.hostname=customIP -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false ``` | 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 | |-|-|-| | 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: Netdata (Observability and Analysis / Observability)
File: windows_swap_in_use.md

This alert monitors the swap memory utilization on a Windows system. If you receive this alert, it means that your system's swap memory usage is nearing or has exceeded the defined thresholds (`warning` at 80-90% and `critical` at 90-98%). Swap memory is a virtual memory management technique where a portion of the disk space is used as an extension of the physical memory (RAM). When the system runs low on RAM, it moves inactive data from RAM to swap memory to free up space for active processes. While swap memory can help prevent the system from running out of memory, keep in mind that accessing data from swap memory is slower than from RAM. Determine the system's memory and swap usage. Use the Windows Task Manager to monitor the overall system performance: ``` Ctrl+Shift+Esc ``` Navigate to the Performance tab to see the used and available memory, as well as swap usage. Check per-process memory usage to find the top consumers. In the Task Manager, navigate to the Processes tab. Sort the processes by memory usage to identify the processes consuming the most memory. Optimize or close the high memory-consuming processes. Analyze the processes and determine whether they are essential. Terminate or optimize non-critical processes that consume a significant amount of memory. Ensure to double-check before closing any process to avoid unintentionally closing necessary processes. Increase the system's memory or adjust swap file settings. If your system consistently runs low on memory, consider upgrading the hardware to add more RAM or adjusting the swap memory settings to allocate more disk space. Prevent memory leaks. Memory leaks occur when an application uses memory but fails to release it when no longer needed, causing gradual memory depletion. Ensure that all software running on your system, particularly custom or in-house applications, is well-designed and tested for memory leaks.
Project: Teletrace (Observability and Analysis / Observability)
File: intro.md

This guide will give you the basic knowledge of what is distributed tracing, what are the different components used to achieve full observability into your application, how to set them up and a basic overview of the different terms that will be used throughout this documentation. As a general note, Teletrace is based on the popular project and we recommend heading to their site as well to get a more in-depth understanding of the observability landscape. We will start be covering what is in concept, what are the benefits of using distributed tracing for troubleshooting and the different tools that exists. We will go over what is OpenTelemetry instrumentation and the different ways we can instrument our code. Finally we will display a of related terms.
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: Fluentbit.md

weight: 2 title: Fluentbit setup disableToc: true menu: docs: parent: "victorialogs-data-ingestion" weight: 2 aliases: /VictoriaLogs/data-ingestion/Fluentbit.html Specify section in the `fluentbit.conf` for sending the collected logs to : ```conf [Output] Name http Match * host localhost port 9428 uri /insert/jsonline?streamfields=stream&msgfield=log&timefield=date format json_lines jsondateformat iso8601 ``` Substitute the host (`localhost`) and port (`9428`) with the real TCP address of VictoriaLogs. See for details on the query args specified in the `uri`. It is recommended verifying whether the initial setup generates the needed and uses the correct . This can be done by specifying `debug` in the `uri` and inspecting VictoriaLogs logs then: ```conf [Output] Name http Match * host localhost port 9428 uri /insert/jsonline?streamfields=stream&msgfield=log&timefield=date&debug=1 format json_lines jsondateformat iso8601 ``` If some must be skipped during data ingestion, then they can be put into `ignore_fields` . For example, the following config instructs VictoriaLogs to ignore `log.offset` and `event.original` fields in the ingested logs: ```conf [Output] Name http Match * host localhost port 9428 uri /insert/jsonline?streamfields=stream&msgfield=log&timefield=date&ignore_fields=log.offset,event.original format json_lines jsondateformat iso8601 ``` If the Fluentbit sends logs to VictoriaLogs in another datacenter, then it may be useful enabling data compression via `compress gzip` option. This usually allows saving network bandwidth and costs by up to 5 times: ```conf [Output] Name http Match * host localhost port 9428 uri /insert/jsonline?streamfields=stream&msgfield=log&timefield=date format json_lines jsondateformat iso8601 compress gzip ``` By default, the ingested logs are stored in the `(AccountID=0, ProjectID=0)` . If you need storing logs in other tenant, then specify the needed tenant via `header` options. For example, the following `fluentbit.conf` config instructs Fluentbit to store the data to `(AccountID=12, ProjectID=34)` tenant: ```conf [Output] Name http Match * host localhost port 9428 uri /insert/jsonline?streamfields=stream&msgfield=log&timefield=date format json_lines jsondateformat iso8601 header AccountID 12 header ProjectID 23 ``` See also: . . . .
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: slack.md

title: Slack Integration description: Integrate Flagsmith with Slack sidebar_label: Slack sidebar_position: 10 hide_title: true You can integrate Flagsmith with Slack. Send flag change events from Flagsmith into your Slack channels. If you don't have an account with Flagsmith already, please and create a new Project within Flagsmith. Go to your Flagsmith project, and click Integrations. Then click "Add Integration" by the Slack integration. Select the Environment you want to receive events for in Slack, then click "Authorise" You will be sent to Slack to authenticate your account. Once back in Flagsmith, select the Slack Channel you want to send events to. Whenever you create, update or delete a Flag in your selected Environments, the Flagsmith Bot will send a message into your selected Slack channel detailing the changes that were made. You can view our .
Project: Netdata (Observability and Analysis / Observability)
File: kubelet_operations_error.md

This alert indicates that there is an increase in the number of Docker or runtime operation errors in your Kubernetes cluster's kubelet. A high number of errors can affect the overall stability and performance of your cluster. Docker or runtime operation errors are errors that occur while the kubelet is managing container-related operations. These errors can be related to creating, starting, stopping, or deleting containers in your Kubernetes cluster. Check kubelet logs: You need to inspect the kubelet logs of the affected nodes to find more information about the reported errors. SSH into the affected node and use the following command to stream the kubelet logs: ``` journalctl -u kubelet -f ``` Look for any error messages or patterns that could indicate a problem. Inspect containers' logs: If an error is related to a specific container, you can inspect the logs of that container using the following command: ``` kubectl logs <container_name> -n <namespace> ``` Replace `<container_name>` and `<namespace>` with the appropriate values. Check Docker or runtime logs: On the affected node, check Docker or container runtime logs for any issues: For Docker, use: `journalctl -u docker` For containerd, use: `journalctl -u containerd` For CRI-O, use: `journalctl -u crio` Examine Kubernetes events: Run the following command to see recent events in your cluster: ``` kubectl get events ``` Look for any error messages or patterns that could indicate a kubelet or container-related problem. Verify resource allocation: Ensure that the node has enough resources available (such as CPU, memory, and disk space) for the containers running on it. You can use commands like `kubectl describe node <node_name>` or monitor your cluster resources using Netdata. Investigate other issues: If the above steps didn't reveal the cause of the errors, investigate other potential causes, such as network issues, filesystem corruption, hardware problems, or misconfigurations.