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

This is a simple guide, written while implementing support for mongodb protocol in order to make life easier for following developers. Have a look at , it defines the ProtocolPlugin interface that you will have to implement yourself, it also contains a list of implemented protocols that you will have to extend. Other files that you will have to complete are , , , and . For a quite simple example have a look at and its unit test file . Test suites are based on , that are dumps from traffic sniffing tools. For example this command listens to all traffic from a mongodb server running in a docker container and writes the result to a file: tcpdump -s 0 port 27017 -i docker0 -w tests/system/pcaps/mongodb_find.pcap The 'tests' directory contains tests written in python that run the full packetbeat program. You can add some of yours based on the pcaps files of you test dataset. You will need to add a few lines into the used in these tests.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-1-2.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 8.1.2 <!-- Auto generated by update changelog github action --> AzureMonitor: Add support for PostgreSQL and MySQL Flexible Servers. , Datasource: Change HTTP status code for failed datasource health check to 400. , Explore: Add span duration to left panel in trace viewer. , Plugins: Use file extension allowlist when serving plugin assets instead of checking for UNIX executable. , Profiling: Support binding pprof server to custom network interfaces. , Search: Make search icon keyboard navigable. , Template variables: Keyboard navigation improvements. , Tooltip: Display milliseconds (ms) within minute time range. , Alerting: Fix saving LINE contact point. , Alerting: Fix saving LINE contact point. , Annotations: Fix alerting annotation coloring. , Annotations: Fixes so alert annotations are visible in the correct Panel. , Auth: Hide SigV4 config UI and disable middleware when its config flag is disabled. , Dashboard: Prevent incorrect panel layout by comparing window width against theme breakpoints. , Elasticsearch: Fix metric names for alert queries. , Explore: Fix showing of full log context. , PanelEdit: Fix 'Actual' size by passing the correct panel size to Das. , Plugins: Fix TLS data source settings. , Variables: Fix issue with empty drop-downs on navigation. , Variables: Fix URL util converting `false` into `true`. , Toolkit: Fix matchMedia not found error. ,
Project: Netdata (Observability and Analysis / Observability)
File: vcsa_mem_health.md

The `vcsamemhealth` alert indicates the memory health status of a virtual machine within the VMware vCenter. If you receive this alert, it means that the system's memory health could be compromised, and might lead to degraded performance, serious problems, or stop functioning. Check the vCenter Server Appliance health: Log in to the vSphere Client and select the vCenter Server instance. Navigate to the Monitor tab > Health section. Check the Memory Health status, and take note of any concerning warnings or critical issues. Analyze the memory usage: Log in to the vSphere Client and select the virtual machine. Navigate to the Monitor tab > Performance section > Memory. Evaluate the memory usage trends and look for any unusual spikes or prolonged high memory usage. Identify processes consuming high memory: Log in to the affected virtual machine. Use the appropriate task manager or command, depending on the OS, to list processes and their memory usage. Terminate any unnecessary processes that are consuming high memory, but ensure that the process is not critical to system operation. Optimize the virtual machine's memory allocation: If the virtual machine consistently experiences high memory usage, consider increasing the allocated memory or optimizing applications running on the virtual machine to consume less memory. Update VMware tools: Ensuring that the VMware tools are up to date can help in better memory management and improve overall system health. Check hardware issues: If the problem persists, check hardware components such as memory sticks, processors, and data stores for any faults that could be causing the problem. Contact VMware Support: If you can't resolve the `vcsamemhealth` alert or are unable to identify the root cause, contact VMware Support for further assistance.
Project: SkyWalking (Observability and Analysis / Observability)
File: introduction.md

Warning, this module is still in the ALPHA stage. This is not stable. Pattern Recognition, Machine Learning(ML) and Artificial Intelligence(AI) are common technology to identify patterns in data. This module provides a way to integrate these technologies in a standardized way about shipping the data from OAP kernel to 3rd party. From the industry practice, Pattern Recognition, Machine Learning(ML) and Artificial Intelligence(AI) are always overestimated, they are good at many things but have to run in a clear context. The ai-pipeline module is activated by default. ```yaml ai-pipeline: selector: ${SWAIPIPELINE:default} default: uriRecognitionServerAddr: ${SWAIPIPELINEURIRECOGNITIONSERVERADDR:} uriRecognitionServerPort: ${SWAIPIPELINEURIRECOGNITIONSERVERPORT:17128} ``` .
Project: Checkmk (Observability and Analysis / Observability)
File: 14223.md

key | value | date | 2024-02-25T15:22:55+00:00 version | 2.4.0b1 class | feature edition | cee component | multisite level | 2 compatible | yes The topology visualization is a new feature that allows the visualization of complex interconnected networks. A simple example for this visualization is the parent/child topology. The new mechanism that comes with this werk allows the linking of external data with the data of the monitoring core. When it comes to the display, you simply define some starting points via the filter form. Based on these, the topology visualization then builds a mesh of incoming and outgoing connections. The type of external data might be Netstat, showing connections between the interfaces/ips/ports LLDP/CDP, showing the network neighbors There is a common data format specification for all external data. So you just can create your own data file which provides information about the relationships between hosts, services or generic objects which are not linked to the core. If you drop this file into a specific folder, the visualization will handle the rest. There is no need to write python code. Right now you can configure Objects - either linked to an entity in the core or some standalone object Icons/emblems which should be added to the object Connections between objects Line style/color of specific connections Since this is a quite visualization heavy topic and hard to explain only via text, feel free to check out the in our checkmk forum We will also publish a blog article in the coming weeks ``` Important: The visualization only works if external data is provided in a special folder. At the moment these are not created by Checkmk, but come from external MKP developments. ```
Project: Vector (Observability and Analysis / Observability)
File: 2021-08-20-rate-limits.md

date: "2021-08-20" title: "Improved defaults for sink rate limits" description: "Removing artificial restrictions by default" authors: ["jszwedko"] pr_numbers: [8472] release: "0.16.0" hideonrelease_notes: false badges: type: "announcement" domains: ["performance"] This release removes some conservative defaults for HTTP-based sink request rate limiting and concurrency. Previously, many sinks were defaulting to a limit of 5 requests / second (for example the `http` sink) with a maximum number of concurrent requests of `5`, but these limits were rather arbitrary and artificially constrained throughput. With this release, we've updated the default for most HTTP-based components to have no rate limiting and a maximum number of concurrent requests of 1024. To configure a request rate limit or maximum concurrency on a HTTP-based sink, you can set the `request` parameters like: ```toml request.concurrency = 5 # limit to 5 in-flight requests request.ratelimitnum = 10 # limit to 10 requests / second ``` If you haven't already, we recommend trying out our [adaptive concurrency controller](/blog/adaptive-request-concurrency/) to have Vector automatically determine the optimal number of in-flight requests to maximize throughput. You can do this by setting `request.concurrency = "adaptive"`. We are planning for this to be the default behavior in `v0.17.0`.
Project: Grafana Loki (Observability and Analysis / Observability)
File: EXAMPLE_README.md

The `example` plugin gathers metrics about example things. This description explains at a high level what the plugin does and provides links to where additional information can be found. Telegraf minimum version: Telegraf x.x Plugin minimum tested version: x.x This section contains the default TOML to configure the plugin. You can generate it using `telegraf --usage <plugin-name>`. ```toml [[inputs.example]] exampleoption = "examplevalue" ``` A more in depth description of an option can be provided here, but only do so if the option cannot be fully described in the sample config. Here you should add an optional description and links to where the user can get more information about the measurements. If the output is determined dynamically based on the input source, or there are more metrics than can reasonably be listed, describe how the input is mapped to the output. measurement1 tags: tag1 (optional description) tag2 fields: field1 (type, unit) field2 (float, percent) measurement2 tags: tag3 fields: field3 (integer, bytes) field4 (integer, green=1 yellow=2 red=3) field5 (string) field6 (float) field7 (boolean) This section can contain some useful InfluxDB queries that can be used to get started with the plugin or to generate dashboards. For each query listed, describe at a high level what data is returned. Get the max, mean, and min for the measurement in the last hour: ``` SELECT max(field1), mean(field1), min(field1) FROM measurement1 WHERE tag1=bar AND time > now() - 1h GROUP BY tag ``` This optional section can provide basic troubleshooting steps that a user can perform. This section shows example output in Line Protocol format. You can often use `telegraf --input-filter <plugin-name> --test` or use the `file` output to get this information. ``` measurement1,tag1=foo,tag2=bar field1=1i,field2=2.1 1453831884664956455 measurement2,tag1=foo,tag2=bar,tag3=baz field3=1i 1453831884664956455 ```
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_hpa.HPA.md

title: "Class: HPA" linkTitle: "HPA" slug: "libk8shpa.HPA" .HPA `any` `HPA` new HPA(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeHPA\>('horizontalPodAutoscaler').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<KubeHPA\>('horizontalPodAutoscaler').className `get` referenceObject(): `any` `any` _ `get` spec(): `HpaSpec` `HpaSpec` _ `get` status(): `HpaStatus` `HpaStatus` metrics(`t`): `HPAMetrics`[] | Name | Type | | : | : | | `t` | `Function` | `HPAMetrics`[] _ `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeHPA\>('horizontalPodAutoscaler').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeHPA\>('horizontalPodAutoscaler').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeHPA\>('horizontalPodAutoscaler').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeHPA\>('horizontalPodAutoscaler').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeHPA\>('horizontalPodAutoscaler').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeHPA\>('horizontalPodAutoscaler').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeHPA\>('horizontalPodAutoscaler').useList
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: launchdarkly.md

title: LaunchDarkly Importer description: Import your LaunchDarkly data into Flagsmith sidebar_label: LaunchDarkly sidebar_position: 10 You can import your Flags and Segments from LaunchDarkly into Flagsmith. :::caution Flagsmith and LaunchDarkly do have differences in their product design and underlying data model. Our importer makes sane decisions around how to migrate data but we strongly recommend you check the results of the import by hand once the import has finished. ::: :::caution Import operations will overwrite existing environments and flags in your project. ::: Create a LaunchDarkly Access Token. In LaunchDarkly: Account settings > Authorization > Access tokens. Create a new Project within Flagsmith, then go to Project Settings > Import. Add your Token generated in step 1. The import will begin immediately. For each Project imported the importer will create a new Project in Flagsmith and copy across the following Entities. All of the LaunchDarkly `Environments` within the Project will be copied into Flagsmith as `Environments` LaunchDarkly `Flags` will be copied into Flagsmith. Boolean LaunchDarkly flags are imported into Flagsmith with the appropriate boolean state, with no flag value set on the Flagsmith side. Boolean values will be taken from the `_summary -> on` field of within LaunchDarkly. Multivariate LaunchDarkly flags will be imported into Flagsmith as MultiVariate Flagsmith flag values. Multivariate values will be taken from the `variations` field of within LaunchDarkly. Values set to serve when targeting is off will be imported as control values.
Project: HertzBeat (Observability and Analysis / Observability)
File: process.md

id: process title: Monitoring Linux Process Monitoring sidebar_label: Process keywords: [Open Source Monitoring System, Operating System Process Monitoring, Process Monitoring] Collect and monitor basic information of processes on Linux systems, including CPU usage, memory usage, physical memory, IO, etc. | Parameter Name | Parameter Description | | - | - | | Target Host | The IPv4, IPv6, or domain name of the monitored endpoint. Note : Do not include the protocol header (e.g., https://, http://). | | Task Name | Identifies the name of this monitoring, ensuring uniqueness. | | Port | SSH port of the Linux system, default: 22 | | Timeout | Sets the timeout for the connection in milliseconds, default is 6000 milliseconds. | | Reuse Connection | Sets whether SSH connection is reused, default is false. When false, a new connection is created for each information retrieval. | | Username | Username for the server. | | Password | Password for the server. | | Process Name | Name or part of the name of the process to be monitored. | | Collector | Specifies which collector to use for scheduling this monitoring. | | Monitoring Interval | Interval for periodic data collection, in seconds. Minimum interval that can be set is 30 seconds. | | Tags | Used for categorizing and managing monitoring resources. | | Description | Additional notes and descriptions for identifying this monitoring. Users can add remarks here. | | Private Key | Private key required for connecting to the server. | | Metric Name | Metric Unit | Metric Description | | -- | -- | | | PID | NONE | Process ID | | User | NONE | User | | CPU | NONE | CPU Usage | | MEM | NONE | Memory Usage | | rss | NONE | Physical Memory | | cmd | NONE | Command | | Metric Name | Metric Unit | Metric Description | | -- | -- | | | PID | NONE | Process ID | | detail | NONE | Detailed metrics | Includes metrics for: Peak Virtual Memory Current Virtual Memory Usage Locked Memory Fixed Memory Peak Physical Memory Current Physical Memory Usage Data Segment Size Stack Size Code Size Shared Library Size Page Table Entry Size | Metric Name | Metric Unit | Metric Description | | -- | -- | | | PID | NONE | Process ID | | path | NONE | Execution Path | | date | NONE | Start Time | | fd_count | NONE | Number of File Descriptors Opened | | Metric Name | Metric Unit | Metric Description | | -- | -- | | | PID | NONE | Process ID | | metric | NONE | Metric Name | | value | NONE | Metric Value | Includes metrics for: rchar (Total bytes read by the process from disk or other files) wchar (Total bytes written by the process to disk or other files) syscr (Number of read operations initiated by the process) syscw (Number of write operations initiated by the process) read_bytes (Actual number of bytes read by the process from disk) write_bytes (Actual number of bytes written by the process to disk) cancelledwritebytes (Actual number of bytes cancelled by the process while writing to disk)
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: open.md

title: 'Using trace open' weight: 20 description: > Trace open system calls. The trace open gadget streams events related to files opened inside pods. Here we deploy a small demo pod "mypod": ```bash $ kubectl run --restart=Never -ti --image=busybox mypod -- sh -c 'while /bin/true ; do whoami ; sleep 3 ; done' ``` Using the trace open gadget, we can see which processes open what files. We can simply filter for the pod "mypod" and omit specifying the node, thus tracing on all nodes for a pod called "mypod": ```bash $ kubectl gadget trace open --podname mypod K8S.NODE K8S.NAMESPACE K8S.POD K8S.CONTAINER PID COMM FD ERR PATH ip-10-0-30-247 default mypod mypod 18455 whoami 3 0 /etc/passwd ip-10-0-30-247 default mypod mypod 18521 whoami 3 0 /etc/passwd ip-10-0-30-247 default mypod mypod 18525 whoami 3 0 /etc/passwd ip-10-0-30-247 default mypod mypod 18530 whoami 3 0 /etc/passwd ^ Terminating! ``` Seems the whoami command opens "/etc/passwd" to map the user ID to a user name. We can leave trace open by hitting Ctrl-C. Finally, we need to clean up our pod: ```bash $ kubectl delete pod mypod ``` Let's start the gadget in a terminal: ```bash $ sudo ig trace open -c test-trace-open RUNTIME.CONTAINERNAME PID COMM FD ERR PATH ``` Run a container that opens some files: ```bash $ docker run --name test-trace-open -it --rm busybox /bin/sh -c 'while /bin/true ; do whoami ; sleep 3 ; done' ``` The tool will show the different files opened by the container: ```bash $ sudo ig trace open -c test-trace-open RUNTIME.CONTAINERNAME PID COMM FD ERR PATH test-trace-open 630417 whoami 3 0 /etc/passwd test-trace-open 630954 whoami 3 0 /etc/passwd ``` If you want to get full paths in from the tool, you can run it with the `--full-path` flag. This will add the column `FULLPATH` that contains the absolute path of the file with symlinks resolved. ```bash $ sudo ./ig trace open -c test-trace-open-fullpath --full-path RUNTIME.CONTAINERNAME PID COMM FD ERR PATH FULLPATH test-trace-open-fullpath 1330356 cat 3 0 /etc/passwd /etc/passwd test-trace-open-fullpath 1330401 cat 3 0 ../etc/mtab /proc/22/mounts ``` You can also filter by prefix paths using `--prefixes`. It will then only report events where opened files matched one of the given prefixes. ```bash RUNTIME.CONTAINERNAME PID COMM FD ERR PATH test-trace-open-fullpath 64069 touch 3 0 /tmp/foo/quux.txt test-trace-open-fullpath 64034 bash 3 0 /tmp/bar.txt ``` Note that this filtering occurs in eBPF.
Project: Nagios (Observability and Analysis / Observability)
File: README.md

Nagios 4.x ========== ](https://travis-ci.org/NagiosEnterprises/nagioscore) Nagios is a host/service/network monitoring program written in C and released under the GNU General Public License, version 2. CGI programs are included to allow you to view the current status, history, etc via a web interface if you so desire. Visit the Nagios homepage at https://www.nagios.org for documentation, new releases, bug reports, information on discussion forums, and more. -- Monitoring of network services (via SMTP, POP3, HTTP, PING, etc). Monitoring of host resources (processor load, disk usage, etc.). A plugin interface to allow for user-developed service monitoring methods. Ability to define network host hierarchy using "parent" hosts, allowing detection of and distinction between hosts that are down and those that are unreachable. Notifications when problems occur and get resolved (via email, pager, or user-defined method). Ability to define event handlers for proactive problem resolution. Automatic log file rotation/archiving. Optional web interface for viewing current network status, notification and problem history, log file, etc. Changes See the for a summary of important changes and fixes, or the for more detail. Download -- Latest releases can be downloaded from https://www.nagios.org/download/ Installation are available to help you get Nagios up and monitoring. Documentation & Support -- Contributing The Nagios source code is hosted on GitHub: https://github.com/NagiosEnterprises/nagioscore Do you have an idea or feature request to make Nagios better? Bugs can be reported by . If you have identified a security related issue in Nagios, please contact security@nagios.com. Patches and GitHub pull requests are welcome. Pull requests on GitHub link commits in version control to review and discussion of the changes, helping to show how and why changes were made, in addition to who was involved. Created by Ethan Galstad, the success of Nagios has been due to the fantastic community members that support it and provide bug reports, patches, and great ideas. See the for some of the many who have contributed since 1999.