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

The `wifioutboundpacketsdroppedratio` alert indicates that a significant number of packets were dropped on the way to transmission over the last 10 minutes. This could be due to a lack of resources or other issues with the network interface. Dropped packets refer to data packets that are discarded by a network interface instead of being transmitted through the network. This can occur for various reasons such as hardware failures, lack of resources (e.g., memory, processing power), or network congestion. Check interface statistics Use the `ifconfig` command to view information about your network interfaces, including their packet drop rates. Look for the dropped packets count in the TX (transmit) section. ```bash ifconfig <interface_name> ``` Replace `<interface_name>` with the name of the network interface you are investigating, such as `wlan0` for a wireless interface. Check system logs System logs can provide valuable information about any potential issues. Check the logs for any errors or warnings related to the network interface or driver. For example, use `dmesg` command to display kernel messages: ```bash dmesg | grep -i "<interface_name>" ``` Replace `<interface_name>` with the name of the network interface you are investigating. Check for hardware issues Inspect the network interface for any signs of hardware failure or malfunction. This may include damaged cables, loose connections, or issues with other networking equipment (e.g. switches, routers). Monitor network congestion High packet drop rates can be caused by network congestion. Monitor network usage and performance using tools such as `iftop`, `nload`, or `vnstat`. Identify and address any traffic bottlenecks or excessive usage. Update network drivers Outdated or faulty network drivers may cause packet drop issues. Check for driver updates and install any available updates following the manufacturer's instructions. Optimize network settings You can adjust network settings, like buffers or queues, to mitigate dropped packets. Consult your operating system or network device documentation for specific recommendations on adjusting these settings.
Project: Checkmk (Observability and Analysis / Observability)
File: 16307.md

key | value | date | 2024-01-02T10:33:32+00:00 version | 2.3.0b1 class | fix edition | cre component | wato level | 1 compatible | yes It was possible to unset the settings for the global option "Maximum long output size" leading to an error on activating of changes.
Project: HertzBeat (Observability and Analysis / Observability)
File: smtp.md

id: smtp title: Monitoring SMTP sidebar_label: SMTP Monitor keywords: [ open source monitoring tool, open source SMTP monitoring tool, monitoring SMTP metrics ] Collect and monitor the general performance Metrics of SMTP. ```text Determine whether the server is available through the hello command in SMTP ``` see https://datatracker.ietf.org/doc/html/rfc821#page-13 Protocol UseSMTP | 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 SMTP | | Email | Your email name, parameters for the hello command | | Timeout | Allow collection response time | | 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 | |--|-|-| | responseTime | ms | The time it takes for the SMTP server to respond to a request. | | response | | Response Status. | | smtpBanner | | Banner of SMTP server. | | heloInfo | | Response information returned by helo. |
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-alarm_eventcases_get_by_id.md

category: Alarm apiurl: '/api/v1/alarm/eventcases' title: 'Get EventCases by id' type: 'GET' sample_doc: 'alarm.html' layout: default Required Content-type: application/x-www-form-urlencoded ```eventid=s165_cef145900bf4e2a4a0db8b85762b9cdb ``` ```Status: 200``` ``` [ { "closed_at": null, "closed_note": "", "cond": "0 != 66", "current_step": 3, "endpoint": "agent2", "expression_id": 0, "func": "all(#1)", "id": "s165cef145900bf4e2a4a0db8b85762b9cdb", "metric": "cpu.idle", "note": "\u5a13\ue103\u2502\u935b\u5a45\ue11f\u9477\ue044\u5aca\u93c7\u5b58\u67ca", "priority": 0, "process_note": 56603, "process_status": "ignored", "status": "PROBLEM", "step": 300, "strategy_id": 165, "template_id": 45, "timestamp": "2017-03-23T15:51:11+08:00", "tpl_creator": "root", "update_at": "2016-06-23T05:00:00+08:00", "user_modified": 0 } ] ``` For errors responses, see the .
Project: SkyWalking (Observability and Analysis / Observability)
File: log-analyzer.md

Log analyzer of OAP server supports native log data. OAP could use Log Analysis Language to structure log content through parsing, extracting and saving logs. The analyzer also uses Meter Analysis Language Engine for further metrics calculation. ```yaml log-analyzer: selector: ${SWLOGANALYZER:default} default: lalFiles: ${SWLOGLAL_FILES:default} malFiles: ${SWLOGMAL_FILES:""} ``` Read the doc on for more on log structuring and metrics analysis. The provide the capabilities to generate new metrics from the raw log text for further calculation.
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: datadog.md

title: Datadog Integration sidebar_label: Datadog hide_title: true import ReactPlayer from 'react-player' You can integrate Flagsmith with Datadog in three ways: This integration lets you add a Flagsmith widget into your Datadog Dashboard so you can view and manage your flags without having to leave the Datadog application. The video below will walk you through the steps of adding the integration: <ReactPlayer playing controls width="100%" height="460px" url='https://getleda.wistia.com/medias/76558s9yj7' /> The second type of integration allows you to send Flag change events in Flagsmith into your Datadog event stream. Log into Datadog and go to Organization Settings > Access > API Generate a new API key Add the Datadog API key into Flagsmith (Integrations > Add Datadog Integration) Add the Datadog URL into Flagsmith as the Base URL - (This is either `https://api.datadoghq.com/` or `https://api.datadoghq.eu/`) By checking the 'Use Custom Source' option, we will send all events with the source 'Flagsmith'. Leaving this unchecked will mean events are labelled with the default 'My apps' source. Flag change events will now be sent to Datadog. You can also send Identity flag values from Flagsmith to DataDog using our .
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: loggingroute_types.md

title: LoggingRouteSpec weight: 200 generated_file: true LoggingRouteSpec defines the desired state of LoggingRoute Source identifies the logging that this policy applies to Targets refers to the list of logging resources specified by a label selector to forward logs to. Filtering of namespaces will happen based on the watchNamespaces and watchNamespaceSelector fields of the target logging resource. LoggingRouteStatus defines the actual state of the LoggingRoute Enumerate non-blocker issues the user should pay attention to Summarize the number of notices for the CLI output Enumerate problems that prohibits this route to take effect and populate the tenants field Summarize the number of problems for the CLI output Enumerate all loggings with all the destination namespaces expanded LoggingRoute (experimental) Connects a log collector with log aggregators from other logging domains and routes relevant logs based on watch namespaces
Project: Checkmk (Observability and Analysis / Observability)
File: 16356.md

key | value | date | 2024-04-17T11:05:50+00:00 version | 2.4.0b1 class | feature edition | cee component | checks level | 1 compatible | no This werk only affects users who have configured the rule Robotmk scheduler (Windows) during the 2.3.0 beta phase. The following incompatible changes have been made: The plan naming convention introduced in has been adopted in more places, both internally and user-facing. The service items of the RMK Plan and RMK Test* services have been reworked to include the name of the corresponding top-level Robot Framework suite. Previously, the scheduler terminated in case of permission issues for example with its working directory. As of this werk, the scheduler instead skips affected plans and forwards these issues to the Checkmk server, where they are reported to the user. After updating, the RMK scheduler status service will report UNKNOWN. The plan and test services will go stale. Furthermore, the Check_MK service will report that there is monitoring data missing for the plugins `robotmkplan` and `robotmktest`. To remedy these issues, users first have to re- bake and then update the Checkmk agent on affected systems. After updating the agent, users have to re-discover the services of affected Checkmk hosts.
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_average_scheduler_utilization.md

This alert is related to VerneMQ, which is an MQTT broker. The Netdata Agent calculates the average VerneMQ's scheduler utilization over the last 10 minutes. If you receive this alert, it means your VerneMQ scheduler's utilization is high, which may indicate performance issues or resource constraints. VerneMQ uses schedulers to manage its tasks and processes. In this context, scheduler utilization represents the degree to which the VerneMQ schedulers are being used. High scheduler utilization may cause delays in processing tasks, leading to performance degradation and possibly affecting the proper functioning of the MQTT broker. Verify the VerneMQ scheduler utilization To check the scheduler utilization, you can use the `vmq-admin` command like this: ``` vmq-admin metrics show | grep scheduler ``` This command will display the scheduler utilization percentage. Analyze the VerneMQ MQTT traffic To analyze the MQTT traffic, use the `vmq-admin` `session` and `client` subcommands. These can give you insights into the current subscription and client status: ``` vmq-admin session show vmq-admin client show ``` This can help you identify if there is any abnormal activity or an increase in the number of clients or subscriptions that may be affecting the scheduler's performance. Evaluate VerneMQ system resources Assess CPU and memory usage of the VerneMQ process using the `top` or `htop` commands: ``` top -p $(pgrep -f vernemq) ``` This will show you the CPU and memory usage for the VerneMQ process. If the process is consuming too many resources, it might be affecting the scheduler's utilization. Evaluate the system's available resources (CPU, memory, and I/O) using commands like `vmstat`, `free`, and `iostat`. ``` vmstat free iostat ``` These commands can help you understand if your system's resources are nearing their limits or if there are any bottlenecks affecting the overall performance. Check the VerneMQ logs for any errors or warnings. The default location for VerneMQ logs is `/var/log/vernemq`. Look for messages that may indicate issues affecting the scheduler's performance. Optimize VerneMQ performance or adjust resources If the MQTT traffic is high or has increased recently, consider scaling up your VerneMQ instance by adding more resources (CPU or memory) or by distributing the load across multiple nodes. If your system resources are limited, consider optimizing your VerneMQ configuration to improve performance. Some example options include adjusting the `maxonlinemessages`, `maxinflightmessages`, or `queuedelivermode`. If the alert persists even after evaluating and making changes to the above steps, consult the VerneMQ documentation or community for further assistance.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: '' assignees: '' Describe the bug <!-- A clear and concise description of what the bug is.--> To Reproduce Steps to reproduce the behavior: Start Tempo (SHA or version) Perform Operations (Read/Write/Others) Expected behavior <!-- A clear and concise description of what you expected to happen. --> Environment: Infrastructure: [e.g., Kubernetes, bare-metal, laptop] Deployment tool: [e.g., helm, jsonnet] Additional Context <!-- Additional relevant info which can help us debug this issue easily like Logs, Configuration etc. -->
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: bind.md

title: 'Using trace bind' weight: 20 description: > Trace the kernel functions performing socket binding. The trace bind gadget is used to stream socket binding syscalls. First, we need to create one pod for us to play with: ```bash $ kubectl run test-pod --image busybox:latest sleep inf ``` You can now use the gadget, but output will be empty: ```bash $ kubectl gadget trace bind K8S.NODE K8S.NAMESPACE K8S.POD K8S.CONTAINER PID COMM PROTO ADDR PORT OPTS IF ``` Indeed, it is waiting for socket binding to occur. So, in another terminal, `exec` the container and use `nc`: ```bash $ kubectl exec -ti test-pod -- nc -l -p 4242 -w 1 nc: timeout command terminated with exit code 1 ``` Go back to the first terminal and see: ``` K8S.NODE K8S.NAMESPACE K8S.POD K8S.CONTAINER PID COMM PROTO ADDR PORT OPTS IF minikube default test-pod test-pod 58208 nc IP :: 4242 .R... 0 ``` This line corresponds to the socket binding operation initiated by `nc`. Congratulations! You reached the end of this guide! You can now delete the pod you created: ```bash $ kubectl delete pod test-pod pod "test-pod" deleted ``` Start the gadget first ```bash $ sudo ig trace bind -c test-trace-bind K8S.CONTAINER PID COMM PROTO ADDR PORT OPTS IF ``` In another terminal, run a container that performs a bind operation ```bash $ docker run -it --rm --name test-trace-bind busybox /bin/sh -c "nc -l -p 4242" ``` The gadget will print the event on the first terminal: ```bash $ sudo ig trace bind -c test-trace-bind K8S.CONTAINER PID COMM PROTO ADDR PORT OPTS IF test-trace-bind 380299 nc TCP :: 4242 .R... 0 ``` With the following options, you can restrict the output: `--pid` only prints events where socket binding is done by the given PID. `-P/--ports` only prints events where these ports are used for socket bindings. `-i/--ignore-errors` only prints events where the bind succeeded. So, this command will print all (i.e. succeeded and failed) attempts to bind a socket on port 4242 or 4343 by PID 42: ```bash $ kubectl gadget trace bind -i=false --pid 42 -P=4242,4343 $ sudo ig trace bind -i=false --pid 42 -P=4242,4343 ```
Project: SkyWalking (Observability and Analysis / Observability)
File: dynamical-logging.md

The OAP server leverages `log4j2` to manage the logging system. `log4j2` supports changing the configuration at runtime, but you have to manually update the XML configuration file, which could be time-consuming and prone to man-made mistakes. Dynamical logging, which depends on dynamic configuration, provides us with an agile way to update all OAP `log4j` configurations through a single operation. The key of the configuration item is `core.default.log4j-xml`, and you can select any of the configuration implements to store the content of `log4j.xml`. In the booting phase, once the core module gets started, `core.default.log4j-xml` would come into the OAP log4j context. If the configuration is changed after the OAP startup, you have to wait for a while for the changes to be applied. The default value is `60` seconds, which you could change through `configuration.<configuration implement>.period` in `application.yaml`. If you remove `core.default.log4j-xml` from the configuration center or disable the configuration module, `log4j.xml` in the `config` directory would be affected. Caveat: The OAP only supports the XML configuration format. This is an example of configuring dynamical logging through a ConfigMap in a Kubernetes cluster. You may set up other configuration clusters following the same procedures. ```yaml apiVersion: v1 data: core.default.log4j-xml: |- <Configuration status="WARN"> <Appenders> <Console name="Console" target="SYSTEM_OUT"> <PatternLayout charset="UTF-8" pattern="%d - %c - %L [%t] %-5p %x - %m%n"/> </Console> </Appenders> <Loggers> <logger name="io.grpc.netty" level="INFO"/> <logger name="org.apache.skywalking.oap.server.configuration.api" level="TRACE"/> <logger name="org.apache.skywalking.oap.server.configuration.configmap" level="DEBUG"/> <Root level="WARN"> <AppenderRef ref="Console"/> </Root> </Loggers> </Configuration> kind: ConfigMap metadata: labels: app: collector release: skywalking name: skywalking-oap namespace: default ```
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_secret.Secret.md

title: "Class: Secret" linkTitle: "Secret" slug: "libk8ssecret.Secret" .Secret `any` `Secret` new Secret(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeSecret\>('secret').constructor `Static` apiEndpoint: `Object` | Name | Type | | : | : | | `scale?` | { `get`: (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> ; `put`: (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> } | | `scale.get` | (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> | | `scale.put` | (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> | _ `Static` className: `string` makeKubeObject<KubeSecret\>('secret').className `get` data(): `any` `any` _ `get` type(): `any` `any` `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeSecret\>('secret').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeSecret\>('secret').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeSecret\>('secret').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeSecret\>('secret').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeSecret\>('secret').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeSecret\>('secret').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeSecret\>('secret').useList
Project: Checkmk (Observability and Analysis / Observability)
File: 16174.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-03-07T09:48:38+00:00 level | 1 class | fix component | checks edition | cre Checkmk previously assumed that timestamps collected from MongoDB oplog are provided in ms. This wasn't the case, which led to wrong values for replication lag and last replication time being shown in the 'MongoDB Replication Lag' service.
Project: SkyWalking (Observability and Analysis / Observability)
File: browser-agent.md

is a client-side JavaScript exception and tracing library. It has these features: Provides metrics and error collection to SkyWalking backend. Lightweight. A simple JavaScript library. No browser plugin is required. Browser serves as a starting point for the entire distributed tracing system. See Client JS for more information. Note: Make sure receiver-browser is enabled. It is ON by default since version 8.2.0. ```yaml receiver-browser: selector: ${SWRECEIVERBROWSER:default} // This means activated. default: sampleRate: ${SWRECEIVERBROWSERSAMPLERATE:10000} ```
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-alarm_eventcases_list.md

category: Alarm apiurl: '/api/v1/alarm/eventcases' title: 'EventCases List' type: 'POST' sample_doc: 'alarm.html' layout: default Required ``` { "endTime": 1480521600, "limit": 10, "process_status": "ignored,unresolved", "startTime": 1466956800, "status": "PROBLEM", "endpoints": ["agent4"], "strategy_id": 46, "template_id": 126 } ``` ```Status: 200``` ``` { "closed_at": null, "closed_note": "", "cond": "48.33759590792839 > 40", "current_step": 1, "endpoint": "agent4", "expression_id": 0, "func": "all(#3)", "id": "s461ac45122afb893adc02fbd30154ac303", "metric": "cpu.iowait", "note": "CPU I/O wait\u74d2\u5470\u7e4340", "priority": 1, "process_note": 16907, "process_status": "ignored", "status": "PROBLEM", "step": 1, "strategy_id": 46, "template_id": 126, "timestamp": "2016-08-01T06:25:00+08:00", "tpl_creator": "root", "update_at": "2016-08-01T06:25:00+08:00", "user_modified": 0 } ] ``` For errors responses, see the .
Project: HertzBeat (Observability and Analysis / Observability)
File: extend-point.md

id: extend-point title: Custom Monitoring sidebar_label: Custom Monitoring HertzBeat has custom monitoring ability. You only need to configure monitoring template yml to fit a custom monitoring type. Custom monitoring currently supports , , , . And it will support more general protocols in the future. HertzBeat Dashboard -> Monitoring Templates -> New Template -> Config Monitoring Template Yml -> Save and Apply -> Add A Monitoring with The New Monitoring Type Configuration usages of the monitoring templates yml are detailed below. We define all monitoring collection types (mysql,jvm,k8s) as yml monitoring templates, and users can import these templates to support corresponding types of monitoring. Monitoring template is used to define the name of monitoring type(international), request parameter mapping, index information, collection protocol configuration information, etc. egDefine a custom monitoring type `app` named `example2` which use the HTTP protocol to collect data. Monitoring Templates -> Config New Monitoring Template Yml -> Save and Apply ```yaml category: custom app: example2 name: zh-CN: en-US: EXAMPLE WEBSITE params: field: host name: zh-CN: Host en-US: Host type: host required: true field: port name: zh-CN: en-US: Port type: number range: '[0,65535]' required: true defaultValue: 80 field: uri name: zh-CN: en-US: URI type: text limit: 200 required: false placeholder: 'Website uri path(no ip port) EG:/console' field: ssl name: zh-CN: HTTPS en-US: HTTPS type: boolean required: true field: timeout name: zh-CN: (ms) en-US: Timeout(ms) type: number required: false hide: true metrics: name: summary priority: 0 fields: field: responseTime type: 0 unit: ms field: keyword type: 0 protocol: http http: host: ^^host^^ port: ^^port^^ url: ^^uri^^ timeout: ^^timeout^^ method: GET ssl: ^^ssl^^ parseType: website ```