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

This module aims to retreive alerts from Microsoft SCOM and store them in Centreon DSM slots. | Directive | Description | Default value | | :- | :- | :- | | dsmclient_bin | Path to the Centreon DSM client | `/usr/share/centreon/bin/`dsmclient.pl| | centcore_cmd | Path to centcore command file | `/var/lib/centreon/centcore.cmd` | | checkcontainerstime | Time in seconds between two containers synchronisation | `3600` | ```yaml name: scom package: "gorgone::modules::plugins::scom::hooks" enable: false checkcontainerstime: 3600 dsmclient_bin: /usr/share/centreon/bin/dsmclient.pl centcore_cmd: /var/lib/centreon/centcore.cmd ``` Add an entry in the containers table with the following attributes per SCOM server: | Directive | Description | | : | :- | | name | Name of the SCOM configuration entrie | | api_version | SCOM API version | | url | URL of the SCOM API | | username | Username to connect to SCOM API | | password | Username's password | | httpauth | API authentication type | | resync_time | Time in seconds between two SCOM/Centreon synchronisations | | dsmhost | Name of the Centreon host to link alerts to | | dsmslot | Name of the Centreon DSM slots to link alerts to | | dsmmacro | Name of the Centreon DSM macro to fill | | dsmalertmessage | Output template for Centreon DSM service when there is an alert | | dsmrecoverymessage | Output template for Centreon DSM service when alert is recovered | | curlopts | Options table for Curl library | ```yaml containers: name: SCOM_prod api_version: 2016 url: "http://scomserver/api/" username: user password: pass httpauth: basic resync_time: 300 dsmhost: ADH3 dsmslot: Scom-% dsmmacro: ALARM_ID dsmalertmessage: "%{monitoringobjectdisplayname} %{name}" dsmrecoverymessage: slot ok curlopts: CURLOPTSSLVERIFYPEER: 0 ``` | Event | Description | | :- | :- | | SCOMREADY | Internal event to notify the core | | SCOMRESYNC | Synchronise SCOM and Centreon realtime | | Endpoint | Method | | :- | :- | | /plugins/scom/resync | `GET` | | Header | Value | | :- | :- | | Accept | application/json | ```bash curl --request GET "https://hostname:8443/api/plugins/scom/resync" \ --header "Accept: application/json" ```
Project: Promscale (Observability and Analysis / Observability)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: '' assignees: '' Is your feature request related to a problem? Please describe. Describe the solution you'd like. <A clear and concise description of what you want to happen.> Describe alternatives you've considered <A clear and concise description of any alternative solutions or features you've considered.> How would this feature help you* <Describe use-cases and the impact that this feature offers you> Additional context <Add any other context or screenshots about the feature request here.>
Project: Vector (Observability and Analysis / Observability)
File: 2023-02-08-7496-vrl-return.md

Add return expression to the Vector Remap Language. #7496 None. Adding a return expression to VRL. The `return` can optionally take an expression as an argument and the result of that expression will be returned. Adding new keywords for similar purposes such as `drop`. Defining semantics of keywords that are usually used for other purposes in other languages such as `break`. Implementation of `return` expressions inside closures. Aborting with changing the input cannot be easily done. VRL code is often unnecessarily indented because of lack of early returns. A `return` expression causes the VRL program to terminate, keeping any modifications made to the event. A `return` expression must be always followed by another expression, whose value will be used as the emitted event. The keyword cannot be used inside a closure. Trying to do that will result in a compilation error. Implementation will be similar to the current `abort` keyword when `droponabort` is set to `false`. The only difference is that the returned value will be taken from the provided expression and not from original input. `droponabort` will have no effect on return calls and configuration such as `droponreturn` will not be added. It will be possible to write VRL with less indentation making it more readable. `return` is already a reserved word so it can be used without introducing a breaking change. The `return` keyword will be given a semantic meaning that will have to be supported going forward. Most languages have a way to make early returns. There was no prior attempted implementation of returns in VRL to my knowledge. New keywords that are not currently a reserved keyword can be added to the language. This would, however, constitute a breaking change. This feature can also be rejected as it does not add any functionality that cannot be currently expressed. Incremental steps to execute this change. These will be converted to issues after the RFC is approved: [ ] Submit a PR with implementation of returns. Adding a `drop` keyword for explicit drop as an alternative to pre-configured `abort` for full control over passing the events to output unchanged, passing them changed, or routing them to the dropped output. Adding `return` to closures.
Project: Spring Cloud Sleuth (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 Please provide details of the problem, including the version of Spring Cloud that you are using. Sample If possible, please provide a test case or a minimal Maven sample written in Java that reproduces the problem. This makes it much easier for us to diagnose the problem and to verify that we have fixed it.
Project: Vector (Observability and Analysis / Observability)
File: 2020-05-13-add-regexset-support-to-regex.md

date: "2020-07-13" title: "RegexSet support to `regex` transform" description: "Efficiently run multiple regexes in the same transform!" authors: ["hoverbear"] hideonrelease_notes: false pr_numbers: [2493] release: "0.10.0" badges: type: "enhancement" domains: ["transforms"] transforms: ["regex_parser"] Contributor taught the how to handle multiple regexes at a time efficiently! Make the following changes in your `vector.toml` file: In order to avoid a deprecation warning you should update any `regex_parser` components to use the new syntax: ```diff title="vector.toml" [transforms.example] type = "regex_parser" regex = "..." patterns = [ "...", # Any new regexes you might want! ] ``` You should also review your pipelines for instances where you have a `regexparser -> [... ->] regexparser` step, you may be able to collapse these now and shave a few a nanoseconds off your events.
Project: Netdata (Observability and Analysis / Observability)
File: vm.loadavg.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/integrations/vm.loadavg.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/metadata.yaml" sidebar_label: "vm.loadavg" learn_status: "Published" learnrelpath: "Collecting Metrics/FreeBSD" most_popular: False message: "DO NOT EDIT THIS FILE DIRECTLY, IT IS GENERATED BY THE COLLECTOR'S metadata.yaml FILE" endmeta--> <img src="https://netdata.cloud/img/freebsd.svg" width="150"/> Plugin: freebsd.plugin Module: vm.loadavg <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> System Load Average The plugin calls `sysctl` function to collect necessary data. This collector is supported on all platforms. This collector supports collecting metrics from multiple instances of this integration, including remote instances. This integration doesn't support auto-detection. The default configuration for this integration does not impose any limits on data collection. The default configuration for this integration is not expected to impose a significant performance impact on the system. Metrics grouped by scope. The scope defines the instance that the metric belongs to. An instance is uniquely identified by a set of labels. Monitoring for number of threads running or waiting. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | system.load | load1, load5, load15 | load | The following alerts are available: | Alert name | On metric | Description | |:|:-|:| | | system.load | number of active CPU cores in the system | | | system.load | system fifteen-minute load average | | | system.load | system five-minute load average | | | system.load | system one-minute load average | No action required. The configuration file name for this integration is `netdata.conf`. Configuration for this specific integration is located in the `[plugin:freebsd]` section within that file. The file format is a modified INI syntax. The general structure is: ```ini [section1] option1 = some value option2 = some other value [section2] option3 = some third value ``` You can edit the configuration file using the `edit-config` script from the Netdata . ```bash cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata sudo ./edit-config netdata.conf ``` <details><summary>Config options</summary> | Name | Description | Default | Required | |:-|:--|:-|:--:| | vm.loadavg | Enable or disable load average metric. | yes | no | </details> There are no configuration examples.
Project: Centreon (Observability and Analysis / Observability)
File: engine.md

This module aims to provide a bridge to communicate with Centreon Engine daemon. | Directive | Description | Default value | | :-- | :-- | :- | | command_file | Path to the Centreon Engine command file pipe | `/var/lib/centreon-engine/rw/centengine.cmd` | ```yaml name: engine package: "gorgone::modules::centreon::engine::hooks" enable: true command_file: "/var/lib/centreon-engine/rw/centengine.cmd" ``` | Event | Description | | : | : | | ENGINEREADY | Internal event to notify the core | | ENGINECOMMAND | Send a Centreon external command to Centreon Engine daemon command file pipe | | Endpoint | Method | | :-- | :-- | | /centreon/engine/command | `POST` | | Header | Value | | :-- | : | | Accept | application/json | | Content-Type | application/json | | Key | Value | | :-- | :-- | | command_file | Path to the Centreon Engine command file pipe | | commands | Array of external commands (old-style format) | ```json { "command_file": "<command file path>", "commands": [ "<external command>" ] } ``` ```bash curl --request POST "https://hostname:8443/api/centreon/engine/command" \ --header "Accept: application/json" \ --header "Content-Type: application/json" \ --data "{ \"command_file\": \"/var/lib/centreon-engine/rw/centengine.cmd\", \"commands\": [ \"[653284380] SCHEDULESVCCHECK;host1;service1;653284380\" ] }" ```
Project: Netdata (Observability and Analysis / Observability)
File: 1min_netdev_backlog_exceeded.md

The linux kernel contains queues where packets are stored after reception from a network interface controller before being processed by the next protocol stack. There is one netdev backlog queue per CPU core. netdevmaxbacklog defines the maximum number of packets that can enter the queue. Queues fill up when an interface receives packets faster than kernel can process them. The default netdevmaxbacklog value should be 1000. However this may not be enough in cases such as: Multiple interfaces operating at 1Gbps, or even a single interface at 10Gbps. Lower powered systems process very large amounts of network traffic. Netdata monitors the average number of dropped packets in the last minute due to exceeding the netdev backlog queue. Increase the netdevmaxbacklog value Check your current value: ``` root@netdata~ # sysctl net.core.netdevmaxbacklog net.core.netdevmaxbacklog = 1000 ``` Try to increase it by a factor of 2. ``` root@netdata~ # sysctl -w net.core.netdevmaxbacklog=2000 ``` Verify the change and test with the same workload that triggered the alarm originally. ``` root@netdata~ # sysctl net.core.netdevmaxbacklog net.core.netdevmaxbacklog = 2000 ``` If this change works for your system, you could make it permanently. Bump this `net.core.netdevmaxbacklog=2000` entry under `/etc/sysctl.conf`. Reload the sysctl settings. ``` root@netdata~ # sysctl -p ```
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: biolatency.md

title: Gadget biolatency The biolatency gadget traces block device I/O (disk I/O), and records the distribution of I/O latency (time), giving this as a histogram when it is stopped. ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: biolatency namespace: gadget spec: node: minikube gadget: biolatency runMode: Manual outputMode: Status ``` Start biolatency ```bash $ kubectl annotate -n gadget trace/biolatency \ gadget.kinvolk.io/operation=start ``` Stop biolatency and store results ```bash $ kubectl annotate -n gadget trace/biolatency \ gadget.kinvolk.io/operation=stop ``` Status
Project: Vector (Observability and Analysis / Observability)
File: 2020-01-03-merge-existing-tcp-and-udp-sources-into-a-single-socket-source.md

date: "2020-07-13" title: "Merge existing `tcp` and `udp` sources into a single `socket` source" description: "We've simplified our socket based sources into a single `socket` source" authors: ["binarylogic"] pr_numbers: [1485] release: "0.7.0" hideonrelease_notes: false badges: type: "breaking change" domain: ["sources"] sources: ["tcp", "udp"] The `tcp` and `udp` sources no longer exist and have been merged into a new `socket` type. Migration is straight forward, simply change the `type` to `socket` and add the field `mode` to match the socket type (`tcp` or `udp`): ```diff title="vector.toml" [sources.mytcpsource] type = "tcp" type = "socket" address = "0.0.0.0:9000" mode = "tcp" ```
Project: Netdata (Observability and Analysis / Observability)
File: 10min_disk_backlog.md

This alert presents the average backlog size of the disk raising this alarm over the last 10 minutes. This alert is escalated to warning when the metric exceeds the size of 5000. Backlog is an indication of the duration of pending disk operations. On every I/O event the system is multiplying the time spent doing I/O since the last update of this field with the number of pending operations. While not accurate, this metric can provide an indication of the expected completion time of the operations in progress.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: mqtt.md

title: MQTT weight: 200 generated_file: true Sends messages from a local network to an MQTT broker. For details on the available options of the output, see the . {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: SyslogNGOutput metadata: name: mqtt namespace: default spec: mqtt: address: tcp://mosquitto:1883 topic: test/demo {{</ highlight >}} Address of the destination host fallback-topic is used when syslog-ng cannot post a message to the originally defined topic (which can include invalid characters coming from templates). qos stands for quality of service and can take three values in the MQTT world. Its default value is 0, where there is no guarantee that the message is ever delivered. Template where you can configure the message template sent to the MQTT broker. By default, the template is: `$ISODATE $HOST $MSGHDR$MSG` Topic defines in which topic syslog-ng stores the log message. You can also use templates here, and use, for example, the $HOST macro in the topic name hierarchy.
Project: SkyWalking (Observability and Analysis / Observability)
File: zipkin-trace.md

The Zipkin receiver makes the OAP server work as an alternative Zipkin server implementation for collecting traces. It supports Zipkin v1/v2 formats through the HTTP collector and Kafka collector. NOTICE, Zipkin trace would not be analyzed like SkyWalking native trace format. Use the following config to activate it. Set `enableHttpCollector` to enable HTTP collector and `enableKafkaCollector` to enable Kafka collector. ```yaml receiver-zipkin: selector: ${SWRECEIVERZIPKIN:default} default: searchableTracesTags: ${SWZIPKINSEARCHABLETAGKEYS:http.method} sampleRate: ${SWZIPKINSAMPLE_RATE:10000} enableHttpCollector: ${SWZIPKINHTTPCOLLECTORENABLED:true} restHost: ${SWRECEIVERZIPKINRESTHOST:0.0.0.0} restPort: ${SWRECEIVERZIPKINRESTPORT:9411} restContextPath: ${SWRECEIVERZIPKINRESTCONTEXT_PATH:/} restMaxThreads: ${SWRECEIVERZIPKINRESTMAX_THREADS:200} restIdleTimeOut: ${SWRECEIVERZIPKINRESTIDLE_TIMEOUT:30000} restAcceptQueueSize: ${SWRECEIVERZIPKINRESTQUEUE_SIZE:0} enableKafkaCollector: ${SWZIPKINKAFKACOLLECTORENABLED:true} kafkaBootstrapServers: ${SWZIPKINKAFKA_SERVERS:localhost:9092} kafkaGroupId: ${SWZIPKINKAFKAGroupId:zipkin} kafkaTopic: ${SWZIPKINKAFKA_TOPIC:zipkin} kafkaConsumerConfig: ${SWZIPKINKAFKACONSUMERCONFIG:"{\"auto.offset.reset\":\"earliest\",\"enable.auto.commit\":true}"} kafkaConsumers: ${SWZIPKINKAFKA_CONSUMERS:1} kafkaHandlerThreadPoolSize: ${SWZIPKINKAFKAHANDLERTHREADPOOLSIZE:-1} kafkaHandlerThreadPoolQueueSize: ${SWZIPKINKAFKAHANDLERTHREADPOOLQUEUE_SIZE:-1} ``` The Zipkin receiver makes the OAP server work as an alternative Zipkin server implementation for query traces. It implemented `ZipkinQueryApiV2` through the HTTP service, supporting Zipkin-lens UI. Use the following config to activate it. ```yaml query-zipkin: selector: ${SWQUERYZIPKIN:default} default: restHost: ${SWQUERYZIPKINRESTHOST:0.0.0.0} restPort: ${SWQUERYZIPKINRESTPORT:9412} restContextPath: ${SWQUERYZIPKINRESTCONTEXT_PATH:/zipkin} restMaxThreads: ${SWQUERYZIPKINRESTMAX_THREADS:200} restIdleTimeOut: ${SWQUERYZIPKINRESTIDLE_TIMEOUT:30000} restAcceptQueueSize: ${SWQUERYZIPKINRESTQUEUE_SIZE:0} lookback: ${SWQUERYZIPKIN_LOOKBACK:86400000} namesMaxAge: ${SWQUERYZIPKINNAMESMAX_AGE:300} uiQueryLimit: ${SWQUERYZIPKINUIQUERY_LIMIT:10} uiDefaultLookback: ${SWQUERYZIPKINUIDEFAULT_LOOKBACK:900000} ``` Lens UI is Zipkin native UI. SkyWalking webapp has bundled it in the binary distribution. `{webapp IP}:{webapp port}/zipkin` is exposed and accessible for the browser. Meanwhile, `Iframe` UI component could be used to host Zipkin Lens UI on the SkyWalking booster UI dashboard.(link=/zipkin) Zipkin Lens UI source codes could be found .
Project: Vector (Observability and Analysis / Observability)
File: 2021-11-18-implicit-namespacing.md

date: "2021-11-18" title: "Automatic namespacing for configuration files" description: "New automatic namespacing functionality to better organize your Vector configuration files" authors: ["barieom"] pr_numbers: [9378] release: "0.18.0" hideonrelease_notes: false badges: type: new feature We've released automatic namespacing for configuration files, which simplifies namespace configuration for your pipelines. As Vector continues to evolve, releasing more configuration-heavy functionality such as an aggregator role and pipelines features, there's often a proliferation in the amount of configuration necessary to run Vector. The ability to organize Vector across multiple files was also lacking in any concrete recommendations for collaboration and navigation; Vector users may have dozens of Vector configuration files, from multiple source files to countless sink files, in a single directory. Let's look at how we can refactor an existing set of Vector configuration files. Assuming Vector is loaded using the configuration via `--config-dir /etc/vector`: ```text /etc/vector/ file001.toml file002.toml file003.toml ... file022.toml file023.toml ``` We can update this using Vector's new automatic namespacing to organize the configuration into separate files based on Vector's configuration directory structure. This makes it easy for users like you to split up your configuration files and collaborate with others on their team. When using `--config-dir` to provide Vector's configuration, it will look for subdirectories with the component types (e.g. `transforms`, or `sources`) and automatically infer that the files in these directories refer to that type of component. Further, Vector will use filenames of the configuration files as their component ID. The end result is that you have to specify less configuration as Vector can infer the component type and id from the directory structure. Using the above example, now with automatic namespacing, you can update this to look like: ```text /etc/vector/ sources/ file001.toml ... file005.toml transforms/ file006.toml ... file016.toml sinks/ file017.toml file022.toml ``` The configuration files become simplified from: ``` toml [sinks.foo] type = "anything" ``` to: ``` toml type = "anything" ``` This can similarly be applied to the newly added and as well. If you any feedback for us, let us know on our [Discord chat] or on [Twitter].
Project: SkyWalking (Observability and Analysis / Observability)
File: server-agents.md

Server agents in various languages provide auto-instrumentation or/and manual-instrumentation(APIs-based) mechanisms to integrate with target services. They support collecting traces, logs, metrics, and events using SkyWalking's native format and maximize the analysis capabilities of the SkyWalking OAP server. . Learn how to install the Java agent in your service without affecting your code. . Learn how to install the Lua agent in Nginx + LUA module or OpenResty. . Learn how to install the Lua agent in Kong. . Learn how to install the Python Agent in a Python service without affecting your code. . Learn how to install the NodeJS Agent in a NodeJS service. . Learn how to integrate the Rust agent with a rust service. . Learn how to install the PHP agent in your service without affecting your code. . Learn how to integrate the Go agent with a golang service. The following agents and SDKs are compatible with SkyWalking's data formats and network protocols but are maintained by third parties. See their project repositories for guides and releases. . See .NET Core agent project documentation for more details. . See cpp2sky project documentation for more details.