cwielenb/CNCF-Dataset huggingface dataset:
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: memory-overhead.md

title: Pyroscope memory overhead menuTitle: Memory overhead description: Learn about memory overhead for the Pyroscope client. weight: 200 Pyroscope has very low memory overhead, usually less than 50 MB per pod. Stacktraces are captured at regular intervals (~100Hz). Memory allocations and lock contention events are sampled. These stacktraces and memory allocation events are temporarily stored in memory. The stored profiling data is periodically (default is every 15 seconds) sent to the server. Memory overhead consists of: The temporary storage of profiles in memory is the primary contributor to memory overhead. Memory usage typically scales up sublinearly with the number of CPUs. The guiding principle of Pyroscope clients is to never cause the user application to crash. Profiles are uploaded using multiple threads. The default value is `5` and can be adjusted using the `Threads` variable. If the backend is down or slow, the profiler discards new profiles to prevent running out of memory. The exact overhead can vary based on the application, so direct testing is recommended. At Grafana Labs we continuously profile all of our workloads. With all profiling types enabled (CPU, alloc, goroutine, mutex, block), the observed memory overhead per pod is typically less than 50 MB. The overhead is often so minimal that it becomes challenging to accurately measure.
Project: Netdata (Observability and Analysis / Observability)
File: consul_gc_pause_time.md

This alert calculates the time spent in stop-the-world garbage collection (GC) pauses on a Consul server node within a one-minute interval. Consul is a distributed service mesh software providing service discovery, configuration, and segmentation functionality. If you receive this alert, it means that the Consul server is experiencing an increased amount of time in GC pauses, which may lead to performance degradation of your service mesh. Garbage collection (GC) in Consul is a mechanism to clean up unused memory resources and improve the overall system performance. During a GC pause, all running processes in Consul server are stopped to allow the garbage collection process to complete. If the duration of GC pauses is too high, it indicates that the Consul server might be under memory pressure, which can affect the overall performance of the system. Check the Consul server logs: Examine the Consul server's logs for any errors or warnings related to memory pressure, increased heap usage, or GC pauses. You can typically find the logs in `/var/log/consul`. Monitor Consul server metrics: Check the Consul server's memory usage, heap usage and GC pause metrics using or Netdata. This can help you identify the cause of increased GC pause time. Optimize Consul server configuration: Ensure that your Consul server is properly configured based on your system resources and workload. Review and adjust the as needed. Reduce memory pressure: If you have identified memory pressure as the root cause, consider adding more memory resources to your Consul server or adjusting the Consul server's memory limits. Update Consul server: Make sure that your Consul server is running the latest version, which can include optimizations and performance improvements.
Project: Netdata (Observability and Analysis / Observability)
File: aws.md

<!-- title: "Install Netdata on AWS" description: "The Netdata Agent runs on all popular cloud providers, but often requires additional steps and configuration for full functionality." customediturl: https://github.com/netdata/netdata/edit/master/packaging/installer/methods/aws.md sidebar_label: "AWS" learn_status: "Published" learnrelpath: "Installation/Install on specific environments" --> Netdata is fully compatible with Amazon Web Services (AWS). You can install Netdata on cloud instances to monitor the apps/services running there, or use multiple instances in a configuration. The best installation method depends on the instance's operating system, distribution, and version. For Linux instances, we recommend the . If you have issues with Netdata after installation, look to the sections below to find the issue you're experiencing, followed by the solution for your provider. If you cannot access Netdata's dashboard on your cloud instance via `http://HOST:19999`, and instead get an error page from your browser that says, "This site can't be reached" (Chrome) or "Unable to connect" (Firefox), you may need to configure your cloud provider's firewall. Cloud providers often create network-level firewalls that run separately from the instance itself. Both AWS and Google Cloud Platform calls them Virtual Private Cloud (VPC) networks. These firewalls can apply even if you've disabled firewalls on the instance itself. Because you can modify these firewalls only via the cloud provider's web interface, it's easy to overlook them when trying to configure and access Netdata's dashboard. You can often confirm a firewall issue by querying the dashboard while connected to the instance via SSH: `curl http://localhost:19999/api/v1/info`. If you see JSON output, Netdata is running properly. If you try the same `curl` command from a remote system, and it fails, it's likely that a firewall is blocking your requests. Another option is to put Netdata behind web server, which will proxy requests through standard HTTP/HTTPS ports (80/443), which are likely already open on your instance. We have a number of guides available: Sign in to the and navigate to the EC2 dashboard. Click on the Security Groups link in the navigation, beneath the Network & Security heading. Find the Security Group your instance belongs to, and either right-click on it or click the Actions button above to see a dropdown menu with Edit inbound rules. Add a new rule with the following options: ```conf Type: Custom TCP Protocol: TCP Port Range: 19999 Source: Anywhere Description: Netdata ``` You can also choose My IP as the source if you prefer. Click Save to apply your new inbound firewall rule.
Project: Grafana (Observability and Analysis / Observability)
File: bot.md

The bot is configured via and some other GitHub workflows . Comment commands: Write the word `/duplicate #<number>` anywhere in a comment and the bot will add the correct label and standard message. Write the word `/needsMoreInfo` anywhere in a comment and the bot will add the correct label and standard message. Label commands: Add label `bot/question` the bot will close with standard question message and add label `type/question` Add label `bot/duplicate` the bot will close with standard duplicate message and add label `type/duplicate` Add label `bot/needs more info` for bot to request more info (or use comment command mentioned above) Add label `bot/close feature request` for bot to close a feature request with standard message and adds label `not implemented` Add label `bot/no new info` for bot to close an issue where we asked for more info but has not received any updates in at least 14 days. Metrics are configured in and are also defined in the GitHub action. To automatically backport a PR to a release branch like v7.3.x add a label named `backport v7.3.x`. The label name should follow the pattern `backport <branch-name>`. Once merged grafanabot will automatically try to cherry-pick the PR merge commit into that branch and open a PR. You must then add the milestone to your backport PR. If there are merge conflicts the bot will write a comment on the source PR saying the cherry-pick failed. In this case you have to do the cherry pick and backport PR manually. The backport logic is written
Project: Checkmk (Observability and Analysis / Observability)
File: 16339.md

key | value | date | 2024-02-25T22:30:51+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes When the mtr section contained a line that started with `ERROR`, the parsing of the section failed. This has now been fixed. The lines starting with `ERROR` will be ignored.
Project: Netdata (Observability and Analysis / Observability)
File: boinc_upload_errors.md

This alert indicates that your BOINC node is experiencing an increase in the average number of failed uploads over the last 10 minutes. Failed uploads can affect the overall efficiency of your BOINC setup and may result in lost work and wasted computational resources. Check for a new BOINC client's version Verify if there's a new version of the BOINC client available for your system on the . If there's a new version available, download and install the recommended version. Verify BOINC project configuration Ensure that your BOINC client is properly configured to work on the projects you're participating in. Double-check your account login credentials, project URLs, and other settings in the BOINC client. Refer to the for more information on configuring your BOINC client. Check network connectivity Verify that your system has a stable network connection and there are no firewall or proxy issues that might be blocking your BOINC client from uploading files. If necessary, adjust your firewall settings or connect to a different network. Inspect BOINC client logs Consult the BOINC client logs to gain insight into the upload errors. The logs can be found in the client's data directory. Contact project support If you're still experiencing upload issues after following the steps above, consider reaching out to the support forums or mailing lists of the relevant BOINC project. The project's support team might be able to offer assistance or guidance in resolving your issue.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: spec-specification.md

It contains spec details provided at `spec` inside chaosresult. The name of chaosengine and chaosexperiment are present at `spec.engine` and `spec.experiment` respectively. ??? info "View the spec details schema" <table> <tr> <th>Field</th> <td><code>.spec.engine</code></td> </tr> <tr> <th>Description</th> <td>Flag to hold the ChaosEngine name for the experiment</td> </tr> <tr> <th>Range</th> <td>n/a (type: string)</td> </tr> <tr> <th>Notes</th> <td>The <code>.spec.engine<code> holds the engine name for the current course of the experiment.</td> </tr> </table> <table> <tr> <th>Field</th> <td><code>.spec.experiment</code></td> </tr> <tr> <th>Description</th> <td>Flag to hold the ChaosExperiment name which induces chaos.</td> </tr> <tr> <th>Range</th> <td>n/a (type: string)</td> </tr> <tr> <th>Notes</th> <td>The <code>.spec.experiment</code> holds the ChaosExperiment name for the current course of the experiment.</td> </tr> </table> view the sample chaosresult: ```yaml Name: engine-nginx-pod-delete Namespace: default Labels: app.kubernetes.io/component=experiment-job app.kubernetes.io/part-of=litmus app.kubernetes.io/version=1.13.8 chaosUID=aa0a0084-f20f-4294-a879-d6df9aba6f9b controller-uid=6943c955-0154-4542-8745-de991eb47c61 job-name=pod-delete-w4p5op name=engine-nginx-pod-delete Annotations: <none> API Version: litmuschaos.io/v1alpha1 Kind: ChaosResult Metadata: Creation Timestamp: 2021-09-29T13:28:59Z Generation: 6 Resource Version: 66788 Self Link: /apis/litmuschaos.io/v1alpha1/namespaces/default/chaosresults/engine-nginx-pod-delete UID: fe7f01c8-8118-4761-8ff9-0a87824d863f Spec: Engine: engine-nginx Experiment: pod-delete Status: Experiment Status: Fail Step: N/A Phase: Completed Probe Success Percentage: 100 Verdict: Pass History: Failed Runs: 1 Passed Runs: 1 Stopped Runs: 0 Targets: Chaos Status: targeted Kind: deployment Name: hello Events: <none> ```
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: SECURITY.md

title: Reporting security issues weight: 90 description: > Instructions to report security issues found in Inspektor Gadget As Inspektor Gadget maintainers, we take security seriously. If you discover a security issue, please bring it to our attention right away. You have two possibilities: Using the GitHub feature "Report a security vulnerability" when opening an issue. It will then create a non-public issue specific to security. Sending a mail to security@inspektor-gadget.io. If you do not know which information you need to fill out when using the first option, then the second option is the way to go. In all cases, we ask that you do not open a public issue.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-9-1-5.md

aliases: [] hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 9.1.5 <!-- Auto generated by update changelog github action --> Alerting: Sanitize invalid label/annotation names for external alertmanagers. , Alerting: Telegram: Truncate long messages to avoid send error. , DisplayProcessor: Handle reverse-ordered data when auto-showing millis. , Heatmap: Add option to reverse color scheme. , PluginLoader: Alias slate-react as @grafana/slate-react. , Search: Add substring matcher, to bring back the old dashboard search behavior. , Traces: More visible span colors. , Alerting: Fix incorrect propagation of org ID and other fields in rule provisioning endpoints. , Alerting: Resetting the notification policy tree to the default policy will also restore default contact points. , AzureMonitor: Fix custom namespaces. , AzureMonitor: Fix issue where custom metric namespaces are not included in the metric namespace list. , CloudWatch: Fix display name of metric and namespace. , Cloudwatch: Fix annotation query serialization issue. , Dashboard: Fix issue where unsaved changes warning would appear even after save, and not being able to change library panels. , Dashboard: Hide overflow content for single left pane. , Loki: Fix a bug where adding adhoc filters was not possible. , Reports: Fix handling expired state. (Enterprise)
Project: Keep (Observability and Analysis / Observability)
File: CHANGELOG.md

{% if context.history.unreleased | length > 0 %} {# UNRELEASED #} {% for type_, commits in context.history.unreleased | dictsort %} {% for commit in commits %}{% if type_ != "unknown" %} {{ commit.commit.message.rstrip() }} () {% else %} {{ commit.commit.message.rstrip() }} () {% endif %}{% endfor %}{% endfor %} {% endif %} {# RELEASED #} {% for version, release in context.history.released.items() %} {% for type_, commits in release["elements"] | dictsort %} {% for commit in commits %}{% if type_ != "unknown" %} {{ commit.commit.message.rstrip() }} () {% else %} {{ commit.commit.message.rstrip() }} () {% endif %}{% endfor %}{% endfor %}{% endfor %}
Project: HertzBeat (Observability and Analysis / Observability)
File: tomcat.md

id: tomcat title: MonitorApache Tomcat sidebar_label: Apache Tomcat keywords: [open source monitoring tool, open source tomcat monitoring tool, monitoring tomcat metrics] Collect and monitor the general performance Metrics of Apache Tomcat. Protocol UseJMX | Parameter name | Parameter help description | | -- | -- | | Monitoring Host | Monitored IPV4, IPV6 or domain name. NoteWithout protocol header (eg: https://, http://) | | Monitoring name | Identify the name of this monitoring. The name needs to be unique | | Port | Port provided by JMX | | Username | JMX connection user name, optional | | Password | JMX connection password, optional | | Collection interval | Interval time of monitor periodic data collection, unit: second, and the minimum interval that can be set is 30 seconds | | Whether to detect | Whether to detect and check the availability of monitoring before adding monitoring. Adding and modifying operations will continue only after the detection is successful | | Description remarks | For more information about identifying and describing this monitoring, users can note information here | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | name | | metrics name | | committed | kb | total size | | init | kb | init size | | max | kb | max size | | used | kb | used size | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | committed | kb | total size | | init | kb | init size | | max | kb | max size | | used | kb | used size | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | LoadedClassCount | | Loaded Class Count | | TotalLoadedClassCount | | Total Loaded Class Count | | UnloadedClassCount | | Unloaded Class Count | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | TotalStartedThreadCount | | Total Started Thread Count | | ThreadCount | | Thread Count | | PeakThreadCount | | Peak Thread Count | | DaemonThreadCount | | Daemon Thread Count | | CurrentThreadUserTime | ms | Current Thread User Time | | CurrentThreadCpuTime | ms | Current Thread Cpu Time | After building tomcat, enter the bin directory under tomcat and modify the catalina.sh file vim catalina.sh Attention Replace Hostname And Port ```aidl CATALINAOPTS="$CATALINAOPTS -Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=10.1.1.52 -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false" ```
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: kubernetes_configmaps.md

sidebar_position: 4 A ConfigMap is an API object used to store non-confidential data in key-value pairs inside kubernetes. GO Feature Flag can read directly in a configmap in your namespace. The will access flags in a Kubernetes ConfigMap via the ```shell kubectl create configmap goff --from-file=examples/retriever_configmap/flags.yaml ``` ```go linenums="1" import ( restclient "k8s.io/client-go/rest" ) config, _ := restclient.InClusterConfig() err = ffclient.Init(ffclient.Config{ PollingInterval: 3 * time.Second, Retriever: &k8sretriever.Retriever{ Path: "file-example.yaml", Namespace: "default" ConfigMapName: "my-configmap" Key: "somekey.yml" ClientConfig: &config }, }) defer ffclient.Close() ``` To configure your retriever: | Field | Description | ||-| | `Namespace` | The namespace of the ConfigMap. | | `ConfigMapName` | The name of the ConfigMap. | | `Key` | The key within the ConfigMap storing the flags. | | `ClientConfig` | The configuration object for the Kubernetes client |
Project: Netdata (Observability and Analysis / Observability)
File: dev.cpu.temperature.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/integrations/dev.cpu.temperature.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/freebsd.plugin/metadata.yaml" sidebar_label: "dev.cpu.temperature" 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: dev.cpu.temperature <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Get current CPU temperature 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. This metric show latest CPU temperature. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | cpu.temperature | a dimension per core | Celsius | There are no alerts configured by default for this integration. 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 | |:-|:--|:-|:--:| | dev.cpu.temperature | Enable or disable CPU temperature metric. | yes | no | </details> There are no configuration examples.
Project: Checkmk (Observability and Analysis / Observability)
File: 15317.md

key | value | date | 2023-12-20T09:43:06+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | no You are affected by this change if you monitor a Primekey appliance and use searches or rules that rely on the service description. In order to unify the primeky checks `primekey_fan` services description was renamed from 'Fan Primekey' to 'Primekey Fan'.
Project: Elastic (Observability and Analysis / Observability)
File: date_trunc.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Rounds down a date to the closest interval. ``` FROM employees | KEEP firstname, lastname, hire_date | EVAL yearhired = DATETRUNC(1 year, hire_date) ```
Project: Netdata (Observability and Analysis / Observability)
File: 20min_steal_cpu.md

This alarm calculates average CPU `steal` time over the last 20 minutes `steal`, in a virtual machine, is the percentage of time that particular virtual CPU has to wait for an available host CPU to run on. If this metric goes up, it means that your VM is not getting the processing power it needs. Check for CPU quota and host issues. Generally, if `steal` is high, it could mean one of the following: Another VM on the host system is hogging the CPU. System services on the host system are monopolizing the CPU (for example, system updates). The host CPUs are over-committed (you have more virtual CPUs assigned to VMs than the host system has physical CPUs) and too many VMs need CPU time simultanously. The VM itself has a CPU quota that is too low. So in the end you can increase the CPU resources of that particular VM, and if the alert persists, move the guest to a different physical server.
Project: Grafana (Observability and Analysis / Observability)
File: json-trace-file.md

description: Upload a JSON trace file to the Tempo data source keywords: grafana tempo guide tracing labels: products: cloud enterprise oss menuTitle: Upload JSON trace file title: Upload a JSON trace file weight: 400 You can upload a JSON file that contains a single trace and visualize it. If the file has multiple traces, Grafana visualizes the first trace. To download a trace or Service Graph through the inspector: Open the inspector. Navigate to the Data tab. Click Download traces or Download Service Graph. ```json { "batches": [ { "resource": { "attributes": [ { "key": "service.name", "value": { "stringValue": "db" } }, { "key": "job", "value": { "stringValue": "tns/db" } }, { "key": "opencensus.exporterversion", "value": { "stringValue": "Jaeger-Go-2.22.1" } }, { "key": "host.name", "value": { "stringValue": "63d16772b4a2" } }, { "key": "ip", "value": { "stringValue": "0.0.0.0" } }, { "key": "client-uuid", "value": { "stringValue": "39fb01637a579639" } } ] }, "instrumentationLibrarySpans": [ { "instrumentationLibrary": {}, "spans": [ { "traceId": "AAAAAAAAAABguiq7RPE+rg==", "spanId": "cmteMBAvwNA=", "parentSpanId": "OY8PIaPbma4=", "name": "HTTP GET - root", "kind": "SPANKINDSERVER", "startTimeUnixNano": "1627471657255809000", "endTimeUnixNano": "1627471657256268000", "attributes": [ { "key": "http.status_code", "value": { "intValue": "200" } }, { "key": "http.method", "value": { "stringValue": "GET" } }, { "key": "http.url", "value": { "stringValue": "/" } }, { "key": "component", "value": { "stringValue": "net/http" } } ], "status": {} } ] } ] } ] } ```