cwielenb/CNCF-Dataset huggingface dataset:
Project: SkyWalking (Observability and Analysis / Observability)
File: jvm-protocol.md

Notice, SkyWalking has provided general available for all kinds of metrics. This API is still supported for forward compatibility only. SkyWalking community would not accept new language specific metric APIs anymore. Uplink the JVM metrics, including PermSize, HeapSize, CPU, Memory, etc., every second. ```protobuf syntax = "proto3"; package skywalking.v3; option javamultiplefiles = true; option java_package = "org.apache.skywalking.apm.network.language.agent.v3"; option csharp_namespace = "SkyWalking.NetworkProtocol.V3"; option go_package = "skywalking.apache.org/repo/goapi/collect/language/agent/v3"; import "common/Common.proto"; import "common/Command.proto"; // Define the JVM metrics report service. service JVMMetricReportService { rpc collect (JVMMetricCollection) returns (Commands) { } } message JVMMetricCollection { repeated JVMMetric metrics = 1; string service = 2; string serviceInstance = 3; } message JVMMetric { int64 time = 1; CPU cpu = 2; repeated Memory memory = 3; repeated MemoryPool memoryPool = 4; repeated GC gc = 5; Thread thread = 6; Class clazz = 7; } message Memory { bool isHeap = 1; int64 init = 2; int64 max = 3; int64 used = 4; int64 committed = 5; } message MemoryPool { PoolType type = 1; int64 init = 2; int64 max = 3; int64 used = 4; int64 committed = 5; } enum PoolType { CODECACHEUSAGE = 0; NEWGEN_USAGE = 1; OLDGEN_USAGE = 2; SURVIVOR_USAGE = 3; PERMGEN_USAGE = 4; METASPACE_USAGE = 5; ZHEAP_USAGE = 6; COMPRESSEDCLASSSPACE_USAGE = 7; CODEHEAPNONNMETHODS_USAGE = 8; CODEHEAPPROFILEDNMETHODS_USAGE = 9; CODEHEAPNONPROFILEDNMETHODSUSAGE = 10; } message GC { GCPhase phase = 1; int64 count = 2; int64 time = 3; } enum GCPhase { NEW = 0; OLD = 1; NORMAL = 2; // The type of GC doesn't have new and old phases, like Z Garbage Collector (ZGC) } // See: https://docs.oracle.com/javase/8/docs/api/java/lang/management/ThreadMXBean.html message Thread { int64 liveCount = 1; int64 daemonCount = 2; int64 peakCount = 3; int64 runnableStateThreadCount = 4; int64 blockedStateThreadCount = 5; int64 waitingStateThreadCount = 6; int64 timedWaitingStateThreadCount = 7; } // See: https://docs.oracle.com/javase/8/docs/api/java/lang/management/ClassLoadingMXBean.html message Class { int64 loadedClassCount = 1; int64 totalUnloadedClassCount = 2; int64 totalLoadedClassCount = 3; } ```
Project: Beats (Observability and Analysis / Observability)
File: question.md

name: Question about: Who, what, when, where, and how? Hey, stop right there! We use GitHub to track feature requests and bug reports. Please do not submit issues for questions about how to use features of Beat, how to set Beats up, best practices, or development related help. However, we do want to help! Head on over to our official Beats forums and ask your questions there. In additional to awesome, knowledgeable community contributors, core Beats developers are on the forums every single day to help you out. The forums are here: https://discuss.elastic.co/c/beats We can't stop you from opening an issue here, but it will likely linger without a response for days or weeks before it is closed and we ask you to join us on the forums instead. Save yourself the time, and ask on the forums today.
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_netsplits.md

This alert indicates that your VerneMQ cluster has experienced a netsplit (split-brain) situation within the last minute. This can lead to inconsistencies in the cluster, and you need to troubleshoot the problem to maintain proper cluster operation. In distributed systems, a netsplit occurs when a cluster of nodes loses connectivity to one or more nodes due to a network failure, leaving the cluster to operate in a degraded state. In the context of VerneMQ, a netsplit can lead to inconsistencies in the subscription data and retained messages. Confirm the alert issue Review the VerneMQ logs to check for any signs of network partitioning or netsplits. Check connectivity between nodes Ensure that the network connectivity between your cluster nodes is restored. You can use tools like `ping` and `traceroute` to verify network connectivity. Inspect node status Use the `vmq-admin cluster show` command to inspect the current status of the nodes in the VerneMQ cluster, and check for any disconnected nodes: ``` vmq-admin cluster show ``` Reestablish connections and heal partitions If a node is disconnected, reconnect it using the `vmq-admin cluster join` command: ``` vmq-admin cluster join discovery-node=IPADDRESSOFANOTHERNODE ``` As soon as the partition is healed, and connectivity is reestablished, the VerneMQ nodes will replicate the latest changes made to the subscription data. Ensure node connectivity remains active Monitor the cluster and network to maintain consistent connectivity between the nodes. Set up monitoring tools and consider using an auto-healing or auto-scaling framework to help maintain node connectivity.
Project: Graylog (Observability and Analysis / Observability)
File: SourceCodeEditor.md

Light-themed editor: ```js import createReactClass from 'create-react-class'; const MarkdownSourceEditor = createReactClass({ getInitialState() { return { code: `## Markdown text This is an example of a source text editor The code we write is written in Markdown `, }; }, handleChange(nextValue) { this.setState({ code: nextValue }); }, render() { const { code } = this.state; return ( <div> <SourceCodeEditor id="editor-1" mode="markdown" theme="light" value={code} onChange={this.handleChange} /> <p>Preview:</p> <pre>{code}</pre> </div> ); }, }); <MarkdownSourceEditor /> ``` Read-only dark-themed editor: ```js import createReactClass from 'create-react-class'; const TextSourceEditor = createReactClass({ getInitialState() { return { code: `function foobar() { console.log('this is some source code!'); } `, }; }, handleChange(nextValue) { this.setState({ code: nextValue }); }, render() { const { code } = this.state; const annotations = [ { row: 1, column: -1, text: 'oh noes!', type: 'error' }, { row: 2, column: -1, text: 'easy!', type: 'warning' }, { row: 3, column: -1, text: 'info!', type: 'info' }, ]; return ( <SourceCodeEditor id="editor-2" annotations={annotations} resizable={false} readOnly theme="dark" value={code} /> ); }, }); <TextSourceEditor /> ``` Non-resizable editor without toolbar and with custom height and width: ```js import createReactClass from 'create-react-class'; const JsonSourceEditor = createReactClass({ getInitialState() { return { code: `{ "key": "value", "foo": [ "bar", "baz" ] } `, }; }, handleChange(nextValue) { this.setState({ code: nextValue }); }, render() { const { code } = this.state; return ( <SourceCodeEditor id="editor-2" height={100} mode="json" onChange={this.handleChange} resizable={false} toolbar={false} width={400} value={code} /> ); }, }); <JsonSourceEditor /> ```
Project: Grafana (Observability and Analysis / Observability)
File: deprecation-policy.md

We do our best to limit breaking changes and the deprecation of features to major releases. We always do our best not to introduce breaking changes in order to make upgrading Grafana as easy and reliable as possible. However, at times we have to introduce a breaking change by changing behavior or by removing a feature. To minimize the negative effects of removing a feature we require a deprecation plan that includes: Determine usage levels of the feature. Find alternative solutions and possible migration paths. Announce deprecation of the feature. Migrate users if possible Give users time to adjust to the deprecation. Disable the feature by default. Remove the feature from the code base. Depending on the size and importance of the feature this can be a design doc or an issue. We want this to be written communication for all parties so we know it's intentional and that did a reasonable attempt to avoid breaking changes unless needed. The size of the feature also means different notice times between Depreciation and disabling as well as disabling and removal. The actual duration will depend on releases of Grafana and the table below should be used as a guide. Grafana employees can find more details in our internal docs. | Size | Duration | Example | | | - | - | | Large | 1-2 years | Classic alerting, scripted dashboards, AngularJS | | Medium | 6 months | Supported Database for Grafana's backend | | Small | 1-3 months | Refresh OAuth accesstoken automatically using the refreshtoken | | Name | Announcement Date | Disabling date | Removal Date | Description | Status | | | -- | -- | | -- | - | | | 2023-05-15 | October 2023 | | MySQL 5.7 is being deprecated in October 2023 and Grafana's policy is to test against the officially supported version. | Planned |
Project: Krkn (Observability and Analysis / Chaos Engineering)
File: MAINTAINERS.md

This document contains a list of maintainers in this repo. | Maintainer | GitHub ID | Email | || | -- | | Ravi Elluri | | nelluri@redhat.com | | Pradeep Surisetty | | psuriset@redhat.com | | Paige Rubendall | | prubenda@redhat.com | | Tullio Sebastiani | | tsebasti@redhat.com |
Project: M3 (Observability and Analysis / Observability)
File: requirements.md

title: "Requirements" menuTitle: "Requirements" weight: 10 chapter: true The M3DB operator current targets Kubernetes 1.11 and 1.12. Given the operator's current production use cases at Uber, we typically target the two most recent minor Kubernetes versions supported by GKE. We welcome community contributions to support more recent versions while meeting the aforementioned GKE targets! The M3DB operator is intended to be used with Kubernetes clusters that span at least 3 zones within a region to create highly available clusters and maintain quorum in the event of region failures. Instructions for creating regional clusters on GKE can be found . M3DB stores its cluster topology and all other runtime metadata in . For testing / non-production use cases, we provide simple manifests for running etcd on Kubernetes in our [example manifests][etcd-example]: one for running ephemeral etcd containers and one for running etcd using basic persistent volumes. If using the `etcd-pd` yaml manifest, we recommend a modification to use a `StorageClass` equivalent to your cloud provider's fastest remote disk (such as `pd-ssd` on GCP). For production use cases, we recommend running etcd (in order of preference): External to your Kubernetes cluster to avoid circular dependencies. Using the .
Project: Netdata (Observability and Analysis / Observability)
File: kern.cp_time.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/integrations/kern.cp_time.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/metadata.yaml" sidebarlabel: "kern.cptime" 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.cp_time <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Total CPU utilization 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. These metrics show CPU usage statistics. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | system.cpu | nice, system, user, interrupt, idle | percentage | This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | cpu.cpu | nice, system, user, interrupt, idle | percentage | The following alerts are available: | Alert name | On metric | Description | |:|:-|:| | | system.cpu | average CPU utilization over the last 10 minutes (excluding iowait, nice and steal) | | | system.cpu | average CPU iowait time over the last 10 minutes | | | system.cpu | average CPU steal time over the last 20 minutes | | | system.cpu | average CPU utilization over the last 10 minutes (excluding nice) | No action required. The configuration file name for this integration is `netdata.conf`. 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 ``` The netdata main configuration file. <details><summary>Config options</summary> | Name | Description | Default | Required | |:-|:--|:-|:--:| | kern.cp_time | Enable or disable Total CPU usage. | yes | no | </details> There are no configuration examples.
Project: Checkmk (Observability and Analysis / Observability)
File: 16168.md

key | value | date | 2024-01-05T13:30:46+00:00 version | 2.3.0b1 class | feature edition | cre component | checks level | 1 compatible | yes Additional FortiAuthenticator devices with SysObjectID starting with ".1.3.6.1.4.1.12356.113" are now detected.
Project: SkyWalking (Observability and Analysis / Observability)
File: EnhanceRequireObjectCache-Cast-Exception.md

When you start your application with the `skywalking` agent, you may find this exception in your agent log which means that `EnhanceRequireObjectCache` cannot be casted to `EnhanceRequireObjectCache`. For example: ```java ERROR 2018-05-07 21:31:24 InstMethodsInter : class[class org.springframework.web.method.HandlerMethod] after method[getBean] intercept failure java.lang.ClassCastException: org.apache.skywalking.apm.plugin.spring.mvc.commons.EnhanceRequireObjectCache cannot be cast to org.apache.skywalking.apm.plugin.spring.mvc.commons.EnhanceRequireObjectCache at org.apache.skywalking.apm.plugin.spring.mvc.commons.interceptor.GetBeanInterceptor.afterMethod(GetBeanInterceptor.java:45) at org.apache.skywalking.apm.agent.core.plugin.interceptor.enhance.InstMethodsInter.intercept(InstMethodsInter.java:105) at org.springframework.web.method.HandlerMethod.getBean(HandlerMethod.java) at org.springframework.web.servlet.handler.AbstractHandlerMethodExceptionResolver.shouldApplyTo(AbstractHandlerMethodExceptionResolver.java:47) at org.springframework.web.servlet.handler.AbstractHandlerExceptionResolver.resolveException(AbstractHandlerExceptionResolver.java:131) at org.springframework.web.servlet.handler.HandlerExceptionResolverComposite.resolveException(HandlerExceptionResolverComposite.java:76) ... ``` This exception may be caused by `hot deployment` tools (`spring-boot-devtool`) or otherwise, which changes the `classloader` in runtime. This error does not occur under the production environment, since developer tools are automatically disabled: See . If you would like to debug in your development environment as usual, you should temporarily remove such `hot deployment` package in your lib path.
Project: Netdata (Observability and Analysis / Observability)
File: mysql_galera_cluster_size_max_2m.md

This alert calculates the maximum size of the MySQL Galera cluster over a 2-minute period, starting from one minute ago. If you receive this alert, it means that there has been a significant change in the cluster size, which might affect the database's performance, stability, and data consistency. MySQL Galera Cluster is a synchronous multi-master cluster for MySQL, built on the Galera replication plugin. It provides high-availability and improved performance for MySQL databases by synchronizing data across multiple nodes. The cluster size refers to the number of nodes participating in a MySQL Galera Cluster. An optimal cluster size ensures that the database can handle more significant workloads, handle node failures, and perform automatic failovers. Determine the current cluster size Connect to any node in the cluster and run the following SQL query: ``` SHOW STATUS LIKE 'wsrepclustersize'; ``` The query will display the current number of nodes in the cluster. Identify the cause of the cluster size change Check the MySQL and Galera logs on all nodes to identify any issues, such as network connectivity issues, node crashes, or hardware problems. Review the logs for events such as joining or leaving of the cluster nodes. Look for patterns that could lead to instability (e.g., frequent node join & leave events). Resolve the issue Fix any identified problems causing the cluster size change. This may involve monitoring and resolving any network issues, restarting failed nodes, or replacing faulty hardware. If necessary, plan and execute a controlled reconfiguration of the Galera cluster to maintain the optimal cluster size.
Project: OpenTelemetry (Observability and Analysis / Observability)
File: repository-settings.md

This document describes any changes that have been made to the settings for this repository beyond the [OpenTelemetry default repository settings](../docs/how-to-configure-new-repository.md#repository-settings). Allow auto-merge Required number of approvals before merging: `2` Require conversation resolution before merging: :heavycheckmark: Allow deletions: :heavycheckmark:
Project: Netdata (Observability and Analysis / Observability)
File: non-uniform_memory_access.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/integrations/non-uniformmemoryaccess.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/metadata.yaml" sidebar_label: "Non-Uniform Memory Access" learn_status: "Published" learnrelpath: "Collecting Metrics/Linux Systems/Memory" 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/linuxserver.svg" width="150"/> Plugin: proc.plugin Module: /sys/devices/system/node <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Information about NUMA (Non-Uniform Memory Access) nodes on the system. NUMA is a method of configuring a cluster of microprocessor in a multiprocessing system so that they can share memory locally, improving performance and the ability of the system to be expanded. NUMA is used in a symmetric multiprocessing (SMP) system. In a NUMA system, processors, memory, and I/O devices are grouped together into cells, also known as nodes. Each node has its own memory and set of I/O devices, and one or more processors. While a processor can access memory in any of the nodes, it does so faster when accessing memory within its own node. The collector provides statistics on memory allocations for processes running on the NUMA nodes, revealing the efficiency of memory allocations in multi-node systems. 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. Labels: | Label | Description | |:--|:-| | numa_node | TBD | Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | mem.numa_nodes | hit, miss, local, foreign, interleave, other | events/s | There are no alerts configured by default for this integration. No action required. There is no configuration file. There are no configuration options. There are no configuration examples.
Project: Chaos Mesh (Observability and Analysis / Chaos Engineering)
File: bug-report.md

name: "\U0001F41B Bug Report" about: Something NOT works as expected, and I could provide the Minimal Reproducible Example. What version of Kubernetes are you using? <!-- You can run `kubectl version` --> What version of Chaos Mesh are you using? <!-- You can run `kubectl exec -n chaos-mesh {chaos-controller-manager-pod-name} -- /usr/local/bin/chaos-controller-manager -version` --> What did you do? / Minimal Reproducible Example <!-- If possible, provide a recipe for reproducing the error. How you installed chaos-mesh. --> What did you expect to see? What did you see instead? Output of chaosctl <!-- If it is related to networkchaos, stresschaos or iochaos, chaosctl would help maintainers better find the bug. --> <!-- See pkg/chaosctl/README.md for detail -->
Project: SkyWalking (Observability and Analysis / Observability)
File: backend-overview.md

SkyWalking OAP and UI provides dozens of features to support observability analysis for your services, cloud infrastructure, open-source components, and more. Besides those out-of-box features for monitoring, users could leverage the powerful and flexible analysis language to build their own analysis and visualization. There are 3 powerful and native language engines designed to analyze observability data from the above areas. processes native traces and service mesh data to build metrics of entity and topology map. is responsible for metrics calculation for native meter data, and adopts a stable and widely used metrics system, such as Prometheus and OpenTelemetry. focuses on analyzing log contents to format and label them, and extract metrics from them to feed Meter Analysis Language for further analysis. SkyWalking community is willing to accept your monitoring extension powered by these languages, if the monitoring targets are public and general usable.
Project: SkyWalking (Observability and Analysis / Observability)
File: filelog-native.md

Application's logs are important data for troubleshooting, usually they are persistent through local or network file system. SkyWalking provides ways to collect logs from those files by leveraging popular open-source tools. You can use , and to collect logs, and then transport the logs to SkyWalking OAP through Kafka or HTTP protocol, with the formats or . Filebeat supports using Kafka to transport logs. Open and enable configs `enableNativeJsonLog`. Take the following Filebeat config YAML as an example to set up Filebeat: Fluentd supports using Kafka to transport logs. Open and enable configs `enableNativeJsonLog`. Take the following fluentd config file as an example to set up Fluentd: Fluent-bit sends logs to OAP directly through HTTP(rest port). Point the output address to `restHost`:`restPort` of `receiver-sharing-server` or `core`(if `receiver-sharing-server` is inactivated) Take the following fluent-bit config files as an example to set up Fluent-bit:
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: syslogng_types.md

title: SyslogNGSpec weight: 200 generated_file: true SyslogNGSpec defines the desired state of SyslogNG Available in Logging operator version 4.5 and later. Set the maximum number of connections for the source. For details, see . Available in Logging operator version 4.5 and later. Parses date automatically from the timestamp registered by the container runtime. Note: `jsonKeyPrefix` and `jsonKeyDelim` are respected. Available in Logging operator version 4.5 and later. Create . Available in Logging operator version 4.5 and later. Parses date automatically from the timestamp registered by the container runtime. Note: `jsonKeyPrefix` and `jsonKeyDelim` are respected. It is disabled by default, but if enabled, then the default settings parse the timestamp written by the container runtime and parsed by Fluent Bit using the `cri` or the `docker` parser. Default: "%FT%T.%f%z" Default(depending on JSONKeyPrefix): "${json.time}" SyslogNGTLS defines the TLS configs See the . See the . Deprecated. Use stats/freq from 4.1+ Deprecated. Use stats/level from 4.1+