cwielenb/CNCF-Dataset huggingface dataset:
Project: OpenTelemetry (Observability and Analysis / Observability)
File: database-client-semconv.md

Get the database client semantic conventions to stability, and afterwards update existing Database instrumentation across all OpenTelemetry repositories to conform with the stable conventions. Mark the Database client semantic conventions as stable. Update existing Database client instrumentation across all OpenTelemetry repositories to conform with the stable conventions. @trask project lead / GC sponsor @lmolkova domain expert @jcocchi domain expert @sourabh1007 domain expert @alanwest prototype engineer / reviewer @jack-berg TC sponsor / prototype engineer / reviewer 2 times per week for 6 weeks starting Feb 6, 2024. The goal will be to have all proposed changes submitted as PRs by the end of the 6 weeks. Wed 9:30-10a Pacific Time Fri 8:30-9a Pacific Time (and will report status weekly in the General Semantic Convention meeting Mon 8-9a Pacific Time) Goal is to stabilize Database client semantic conventions 3 months after the working group kicks off. Once approved by TC, a project should be managed using a GitHub project board. This project board should be pre-populated with issues that cover all known deliverables, organized by timeline milestones. A (TC) member associated with the project can create the board, along with a new project-specific GitHub label to automatically associate issues and PRs with the project. The project lead and all other relevant project members should have edit access to the board. Once created, please link to the project board here.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_resourceQuota.KubeResourceQuota.md

title: "Interface: KubeResourceQuota" linkTitle: "KubeResourceQuota" slug: "libk8sresourceQuota.KubeResourceQuota" .KubeResourceQuota `KubeResourceQuota` `Optional` apiVersion: `string` . _ kind: `string` Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. In CamelCase. Cannot be updated. `see` . _ metadata: . _ spec: `spec` _ status: `status`
Project: Vector (Observability and Analysis / Observability)
File: 2020-02-11-improved-syslog-parsing.md

date: "2020-04-13" title: "Improved Syslog Parsing" description: "Best effort parsing support for Syslog" authors: ["binarylogic"] pr_numbers: [1757] release: "0.8.0" hideonrelease_notes: true badges: type: "new feature" domains: ["sources"] sources: ["syslog"] Anyone that dealt with Syslog knows that the format specification is a "goal". It's very common for formats to deviate slightly. To account for this we've updated our Syslog parsing to follow the , , and other common formats. With these changes Vector is very likely to parse a Syslog format, or anything like it. And, as always, if Vector's fails to parse your format you can always use the and the to roll your own collection parsing pipeline.
Project: Checkmk (Observability and Analysis / Observability)
File: 16457.md

key | value | date | 2024-03-12T12:19:42+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes cmk/meraki: This label is set to "yes" for all Meraki devices cmk/meraki/device_type: This label is set to the Meraki product type to which the device belongs, such as "switch" or "wireless". cmk/meraki/net_id: This label is set to the network id the Meraki device belongs to. cmk/meraki/org_id: This label is set to the organisation id the Meraki device belongs to. cmk/meraki/org_name: This label is set to the organisation name the Meraki device belongs to.
Project: Netdata (Observability and Analysis / Observability)
File: vsphere_inbound_packets_dropped_ratio.md

This alert, `vsphereinboundpacketsdroppedratio`, is triggered when there is a high ratio of dropped inbound packets for the network interface in a vSphere (VMware) environment for a virtual machine. If you receive this alert, it means that the network interface is experiencing packet loss on inbound traffic over the last 10 minutes, which can result in poor network performance and degraded application functionality. A high ratio of dropped inbound packets means that a significant percentage of the incoming network packets are not being processed by the virtual machine. This can be caused by various reasons, such as network congestion, faulty hardware, incorrect network configuration, or overwhelmed virtual machine resources. A high packet loss in a network can significantly degrade its performance and affect the proper functioning of applications relying on the network. Verify the packet loss rate Monitor the inbound dropped packets ratio using the Netdata dashboard or any other network monitoring tool you have available. Identify trends or patterns in the packet loss and try to correlate them with any specific events or changes in the infrastructure. Check the network congestion Examine your network traffic to determine if network congestion or high network utilization is causing the dropped inbound packets. If congestion is the issue, identify and resolve the bottleneck, such as by increasing bandwidth or optimizing the network configuration. Assess virtual machine resources Review the virtual machine's CPU usage, memory usage, and disk I/O. If the resources seem to be strained, consider allocating more resources or optimizing the virtual machine for better performance. Inspect the network hardware Check the physical network hardware, such as switches, routers, and network interface cards (NICs), for any failures or connectivity issues. Replace any faulty hardware if necessary. Validate network configuration Ensure that the network configuration on the virtual machine and vSphere host is correct and properly optimized for your specific environment. Monitor the vSphere environment Review the vSphere environment and look for any issues with the host, datastore, or other virtual machines that may be contributing to the high ratio of dropped inbound packets. Consult VMware documentation and support If the issue persists, refer to VMware's official documentation and knowledge base articles for further assistance, or contact VMware support for guidance.
Project: Netdata (Observability and Analysis / Observability)
File: vsphere_vm_mem_usage.md

This alert is triggered when a virtual machine's memory usage in a vSphere environment is significantly higher than normal, indicating potential performance issues or insufficient memory allocation. Check memory usage: Monitor the virtual machine's memory usage to identify potential bottlenecks or high memory consumption by applications. Inspect applications: Review applications running on the virtual machine to identify those consuming excessive memory, and determine if it's expected behavior or a memory leak. Adjust memory allocation: If the virtual machine consistently has high memory usage, consider increasing the allocated memory to improve performance. Optimize applications: Identify opportunities to optimize applications running on the virtual machine to reduce memory consumption. Monitor performance: Keep an eye on the virtual machine's performance metrics to ensure that changes in memory usage or allocation do not negatively impact performance.
Project: Vector (Observability and Analysis / Observability)
File: 2020-03-11-vector-sink-tls.md

date: "2020-04-13" title: "The Vector Source and Sink Support TLS" description: "Securely forward data between Vector instances" authors: ["binarylogic"] pr_numbers: [2025] release: "0.9.0" hideonrelease_notes: true badges: type: "new feature" domains: ["sources"] sources: ["vector"] A highly requested feature of Vector is to support the TLS protocol for the and . This is now available. Check out the `tls.*` options.
Project: Centreon (Observability and Analysis / Observability)
File: migration.md

To build a configuration file based on /etc/centreon/conf.pm, execute the following command line. If using package: ```bash $ perl /usr/local/bin/gorgoneconfiginit.pl 2019-09-30 11:00:00 - INFO - file '/etc/centreon-gorgone/config.yaml' created success ``` If using sources: ```bash $ perl ./contrib/gorgoneconfiginit.pl 2019-09-30 11:00:00 - INFO - file '/etc/centreon-gorgone/config.yaml' created success ``` As a result the following configuration file will be created at /etc/centreon-gorgone/config.yaml: ```yaml name: config.yaml description: Configuration init by gorgoneconfiginit configuration: centreon: database: db_configuration: dsn: "mysql:host=localhost;port=3306;dbname=centreon" username: "centreon" password: "centreon" db_realtime: dsn: "mysql:host=localhost;port=3306;dbname=centreon_storage" username: "centreon" password: "centreon" gorgone: gorgonecore: privkey: "/var/lib/centreon-gorgone/.keys/rsakey.priv.pem" pubkey: "/var/lib/centreon-gorgone/.keys/rsakey.pub.pem" modules: name: httpserver package: gorgone::modules::core::httpserver::hooks enable: false address: 0.0.0.0 port: 8085 ssl: false auth: enabled: false allowed_hosts: enabled: true subnets: 127.0.0.1/32 name: action package: gorgone::modules::core::action::hooks enable: true command_timeout: 30 whitelist_cmds: true allowed_cmds: ^sudo\s+(/bin/)?systemctl\s+(reload|restart)\s+(centengine|centreontrapd|cbd)\s*$ ^(sudo\s+)?(/usr/bin/)?service\s+(centengine|centreontrapd|cbd|cbd-sql)\s+(reload|restart)\s*$ ^/usr/sbin/centenginestats\s+-c\s+/etc/centreon-engine/centengine\.cfg\s*$ ^cat\s+/var/lib/centreon-engine/[a-zA-Z0-9\-]+-stats\.json\s*$ ^/usr/lib/centreon/plugins/.*$ ^/bin/perl /usr/share/centreon/bin/anomalydetection --seasonality >> /var/log/centreon/anomalydetection\.log 2>&1\s*$ ^/usr/bin/php -q /usr/share/centreon/cron/centreon-helios\.php >> /var/log/centreon-helios\.log 2>&1\s*$ ^centreon ^mkdir ^/usr/share/centreon/www/modules/centreon-autodiscovery-server/script/runsavediscovered_host ^/usr/share/centreon/bin/centreon -u \"centreon-gorgone\" -p \S+ -w -o CentreonWorker -a processQueue$ name: cron package: gorgone::modules::core::cron::hooks enable: false cron: !include cron.d/*.yaml name: proxy package: gorgone::modules::core::proxy::hooks enable: true name: legacycmd package: gorgone::modules::centreon::legacycmd::hooks enable: true cmd_file: "/var/lib/centreon/centcore.cmd" cache_dir: "/var/cache/centreon/" cachedirtrap: "/etc/snmp/centreon_traps/" remote_dir: "/var/lib/centreon/remote-data/" name: engine package: "gorgone::modules::centreon::engine::hooks" enable: true command_file: "/var/lib/centreon-engine/rw/centengine.cmd" name: pollers package: gorgone::modules::centreon::pollers::hooks enable: true name: broker package: "gorgone::modules::centreon::broker::hooks" enable: true cache_dir: "/var/cache/centreon//broker-stats/" cron: id: broker_stats timespec: "/2 *" action: BROKERSTATS parameters: timeout: 10 ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16686.md

key | value | date | 2024-04-11T10:25:58+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes This only affects the 2.3-beta versions. There where issues when rendering fractional values in some specific rulesets.
Project: Netdata (Observability and Analysis / Observability)
File: kern.ipc.sem.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/integrations/kern.ipc.sem.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/metadata.yaml" sidebar_label: "kern.ipc.sem" 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: kern.ipc.sem <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Collect information about semaphore. 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. These metrics shows counters for semaphores on host. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | system.ipc_semaphores | semaphores | semaphores | | system.ipcsemaphorearrays | arrays | arrays | The following alerts are available: | Alert name | On metric | Description | |:|:-|:| | | system.ipc_semaphores | IPC semaphore utilization | | | system.ipcsemaphorearrays | IPC semaphore arrays utilization | 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 | |:-|:--|:-|:--:| | kern.ipc.sem | Enable or disable semaphore metrics. | yes | no | </details> There are no configuration examples.
Project: Checkmk (Observability and Analysis / Observability)
File: 16581.md

key | value | date | 2024-03-08T12:39:02+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes Checkmk automatically creates host labels based on OS data sent by the agents on check\_mk section. `cmk/os_type`: Value taken from `OSType` line. No label created if line is not present. `cmk/os_platform`: Value is taken from `OSPlatform` line. If line is not present, AgentOS value is used instead `cmk/os_name`: Value taken from `OSName` line. No label created if line is not present. `cmk/os_version`: Value taken from `OSVersion` line. No label created if line is not present. The following list shows an example of the information that agents send for the labels creation. The source is noted in square brackets. AIX AgentOS: aix OSType: unix OSName: AIX OSVersion: [oslevel -s]: 7100-05-04-1914 FreeBSD AgentOS: freebsd OSType: unix OSName: [/etc/os-release (NAME)]: FreeBSD OSVersion: [/etc/os-release (VERSION\_ID)]: 13.2 HP-UX AgentOS: hpux OSType: unix OSName: HP-UX OSVersion: [uname -r | cut -d' ' -f1]: B.11.31 Linux AgentOS: linux OSType: linux OSPlatform: [/etc/os-release (ID)]: ubuntu OSName: [/etc/os-release (NAME)]: Ubuntu OSVersion: [/etc/os-release (VERSION\_ID)]: 22.04 MacOS AgentOS: macosx OSType: macos OSName: [sw\_vers -productName]: macOS OSVersion: [sw\_vers -productVersion]: 13.0 NetBSD AgentOS: netbsd OSType: unix OSName: [uname -s]: NetBSD OSVersion: [uname -r]: 9.3 OpenBSD AgentOS: openbsd OSType: unix OSName: [uname -s]: OpenBSD OSVersion: [uname -r]: 7.4 OpenVMS AgentOS: openvms OSName: OpenVMS OpenWRT AgentOS: openwrt OSType: linux OSName: [/etc/os-release (NAME)]: OpenWRT OSVersion: [/etc/os-release (VERSION\_ID)]: snapshot Solaris AgentOS: solaris OSType: unix OSName: [/etc/os-release (NAME)]: Oracle Solaris OSVersion: [/etc/os-release (VERSION\_ID)]: 11.4 Windows AgentOS: windows OSType: windows OSName: [wmi]: Microsoft Windows 10 Pro OSVersion: [wmi]: 10.0.19045 z/OS AgentOS: z/OS OSType: z/os OSName: z/OS
Project: DeepFlow (Observability and Analysis / Observability)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thank you for contributing to DeepFlow! Please read this template before submitting pull requests. Texts surrounded by `<` and `>` should be replaced accordingly. Put an `x` in `[ ]` to mark the item as checked. `[x]` --> <!-- One or more of: Agent CLI Server Message Libs Documents Workflow --> <!-- ==== Remove this line WHEN AND ONLY WHEN you're fixing a bug, follow the checklist ==== <steps here> ... <changes here> ... main [ ] Added unit test to verify the fix. [ ] Verified eBPF program runs successfully on linux 4.14.x. [ ] Verified eBPF program runs successfully on linux 4.19.x. [ ] Verified eBPF program runs successfully on linux 5.2.x. ==== Remove this line WHEN AND ONLY WHEN you're fixing a bug, follow the checklist ==== --> <!-- ==== Remove this line WHEN AND ONLY WHEN you're improving the performance, follow the checklist ==== <link here> ```text <Paste benchmark results> ```` ==== Remove this line WHEN AND ONLY WHEN you're improving the performance, follow the checklist ==== --> <!-- ==== Remove this line WHEN AND ONLY WHEN you're adding a new feature, follow the checklist ==== [ ] Added unit test. <branch name here> ==== Remove this line WHEN AND ONLY WHEN you're adding a new feature, follow the checklist ==== --> <!-- ==== Remove this line WHEN AND ONLY WHEN you're updating document or workflow, follow the checklist ==== ==== Remove this line WHEN AND ONLY WHEN you're updating document or workflow, follow the checklist ==== --> <!-- Uncomment if the PR fixes an issue Fixes #(issue-number) -->
Project: Vector (Observability and Analysis / Observability)
File: sample.md

title: Sample description: Sample events from an event stream based on supplied criteria and at a configurable rate component_kind: transform layout: component tags: ["sample", "component", "log", "trace", "transform"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Grafana Loki (Observability and Analysis / Observability)
File: cadence.md

title: Release cadence description: How our release process works weight: 1 Loki releases (this includes , , etc.) use the following naming scheme: `MAJOR`.`MINOR`.`PATCH`. `MAJOR` (roughly once a year): these releases include large new features and possible backwards-compatibility breaks. `MINOR` (roughly once a quarter): these releases include new features which generally do not break backwards-compatibility, but from time to time we might introduce minor breaking changes, and we will specify these in our upgrade docs. `PATCH` (roughly once or twice a month): these releases include bug and security fixes which do not break backwards-compatibility. {{% admonition type="note" %}} While our naming scheme resembles , at this time we do not strictly follow its guidelines to the letter. Our goal is to provide regular releases that are as stable as possible, and we take backwards-compatibility seriously. As with any software, always read the and the whenever choosing a new version of Loki to install. {{% /admonition %}} New releases are based of a which we have vetted for stability over a number of weeks. We strongly recommend keeping up-to-date with patch releases as they are released. We post updates of new releases in the `#loki` channel of our . You can find all of our releases and on . Every Monday morning, we create a new "weekly" release from the tip of the . These releases use the following naming scheme: <ul> <code>weekly-k&lt;week-number&gt;</code> where <code>&lt;week-number&gt;</code> is the number of weeks since we began this process (2020-07-06). </ul> These weekly releases are deployed across our Grafana Cloud Logs fleet of instances. We test these releases for stability by deploying them through development, pre-production, and production instances. Generally these weekly releases are considered stable enough to run, but we provide zero stability guarantees and these releases should not be run in production unless you are willing to tolerate some risk. You can find these releases on . Once your PR is merged to `main`, you can expect it to become available in the next week's . To find out which stable or weekly releases a commit is included in, use the following tool: `tools/which-release.sh` For example, was into the commit named `d434e80`. Using the tool above, we can see that is part of release 2.8 and several weekly releases: ```bash $ ./tools/which-release.sh d434e80 Commit was found in the following releases: release-2.8.x Commit was found in the following weekly builds: k136 k137 k138 k139 k140 k141 k142 ```
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-dashboard_screen_get_by_id.md

category: DashboardScreen apiurl: '/api/v1/dashboard/screen/:screen_id' title: 'Get a DashboardScreen by id' type: 'GET' sample_doc: 'dashboard.html' layout: default Required ```Status: 200``` ```{"id":961,"pid":0,"name":"laiwei-sceen1"} ``` For errors responses, see the .
Project: Checkmk (Observability and Analysis / Observability)
File: 16641.md

key | value | date | 2024-03-20T15:34:24+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes This only affects plugin developers. The size of the String input field can now be adapted to the specific purpose of the field: The developer can select between different size settings.
Project: Elastic (Observability and Analysis / Observability)
File: st_y.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Extracts the `y` coordinate from the supplied point. If the points is of type `geo_point` this is equivalent to extracting the `latitude` value. ``` ROW point = TO_GEOPOINT("POINT(42.97109629958868 14.7552534006536)") | EVAL x = STX(point), y = STY(point) ```
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: NOTICE.md

The source code developed for the LitmusChaos Project is licensed under Apache 2.0. However, the LitmusChaos project contains unmodified subcomponents from other OpenSource Projects with separate copyright notices and license terms. Your use of the source code for these subcomponents is subject to the terms and conditions as defined by those source projects. Please refer to the reports for more details
Project: Checkmk (Observability and Analysis / Observability)
File: 16802.md

key | value | date | 2024-04-24T12:38:16+00:00 version | 2.4.0b1 class | fix edition | cee component | setup level | 1 compatible | yes When attempting to save the bakery rule "Robotmk scheduler (Windows)" with invalid settings such as an empty base directory or an invalid application name, the UI page crashed with <code>TypeError: argument of type 'NoneType' is not iterable</code>.
Project: Checkmk (Observability and Analysis / Observability)
File: 16490.md

key | value | date | 2024-02-05T12:36:23+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes With this werk the last NetApp check plugins have been migrated for the new NetApp ONTAP REST API. The new migrated plugins are: NetApp snapvault NetApp qtree quota NetApp FCP