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

The `exportingmetricssent` alert is triggered when the Netdata Agent fails to send all metrics to the configured external database server. This could be due to the exporting destination being down, unreachable, or short-term network availability problems. To troubleshoot this alert, follow these steps: Verify the exporting destination status: Make sure the external database server is up and running. Check if there are any issues with the server, such as high CPU usage, low memory, or a full disk. Check the network connection between the Netdata Agent and the external database server: Use tools like `ping` or `traceroute` to test the connection. Check for any firewall rules that may be blocking the connection. Increase the `buffer on failures` in `exporting.conf`: Open the `exporting.conf` file, which is typically located at `/etc/netdata/exporting.conf`. Increase the value of the `buffer on failures` setting to allow for more metrics to be stored when network/connectivity issues occur. For example, if the current setting is `10000`, try increasing it to `20000` or higher, depending on your server's available memory. ``` [exporting:global] buffer on failures = 20000 ``` Save and exit the file. Restart the Netdata Agent to apply the changes. Review the Netdata Agent logs: Check for any error messages or warnings related to the exporting engine in the Netdata Agent logs (`/var/log/netdata/error.log`). Use the information from the logs to troubleshoot any issues you find. Ensure your configuration settings are correct: Double-check your exporting configuration settings (located in `/etc/netdata/exporting.conf`) to ensure they match the requirements of your external database server.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: "" labels: "" assignees: "" A clear and concise description of what the bug is. Steps to reproduce the behavior: Start Mimir (SHA or version) Perform Operations(Read/Write/Others) A clear and concise description of what you expected to happen. Infrastructure: [e.g., Kubernetes, bare-metal, laptop] Deployment tool: [e.g., helm, jsonnet] <!-- Additional relevant info which can help us debug this issue easily like Logs, Configuration etc. -->
Project: Teletrace (Observability and Analysis / Observability)
File: support.md

We are happy to provide support in all of our channels of communication, to get in touch with the core team and the community we recommend joining our slack workspace or via email at . {.md-button .md-button--primary} Make sure to read through the section. Look through our . . Feel free to open support tickets in or to reach us through Slack, make sure to use polite and inclusive language, and to describe the issue with enough details for us to help.
Project: Krkn (Observability and Analysis / Chaos Engineering)
File: time_scenarios.md

Using this type of scenario configuration, one is able to change the time and/or date of the system for pods or nodes. Configuration Options: action: skewtime or skewdate. object_type: pod or node. namespace: namespace of the pods you want to skew. Needs to be set if setting a specific pod name. label_selector: Label on the nodes or pods you want to skew. container_name: Container name in pod you want to reset time on. If left blank it will randomly select one. object_name: List of the names of pods or nodes you want to skew. Refer to config file. ``` time_scenarios: action: skew_time object_type: pod object_name: apiserver-868595fcbb-6qnsc apiserver-868595fcbb-mb9j5 namespace: openshift-apiserver container_name: openshift-apiserver action: skew_date object_type: node label_selector: node-role.kubernetes.io/worker ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16178.md

key | value | date | 2024-03-20T08:49:31+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes With version 2.3.0b1, the macros in the 'Expected DNS answers' field of 'Check DNS service' were no longer replaced. This change reintroduces macro replacement.
Project: Thanos (Observability and Analysis / Observability)
File: PULL_REQUEST_TEMPLATE.md

<!-- Keep PR title verbose enough and add prefix telling about what components it touches e.g "query:" or ".*:" --> <!-- Don't forget about CHANGELOG! Changelog entry format: Thanos <Component> ... <PR-id> Id of your pull request. <PR-URL> URL of your PR such as https://github.com/thanos-io/thanos/pull/<PR-id> <Component> Component affected by your changes such as Query, Store, Receive. --> [ ] I added CHANGELOG entry for this change. [ ] Change is not relevant to the end user. <!-- Enumerate changes you made --> <!-- How you tested it? How do you know it works? -->
Project: Checkmk (Observability and Analysis / Observability)
File: 16038.md

key | value | date | 2024-01-04T08:28:52+00:00 version | 2.3.0b1 class | fix edition | cee component | multisite level | 1 compatible | yes The SLA tooltip would always show UNKN (0%) even if the state was UNKN. The corresponding value was aggregated as a PEND state. Now the UNKN state is displayed correctly.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: CHANGES.md

bump protobuf dep to v1.33 () () v2/callctx:* fix SetHeader race by cloning header map () () add XGoogFieldMaskHeader constant () () v2/callctx:* add new callctx package () () v2:* add BuildHeaders and InsertMetadataIntoOutgoingContext to header () () v2:* add GoVersion package variable () () v2:* handle space in non-devel go version () () update dependencies () () v2:* drop cloud lro test dep () (), refs apierror:* add method to return HTTP status code conditionally () (), refs add ref to usage with clients () (), refs v2:* add WithTimeout option () () v2/apierror:* return Unknown GRPCStatus when err source is HTTP () (), refs update google.golang.org/api to latest () () v2/apierror:* add apierror.FromWrappingError () () v2:* copy DetermineContentType functionality () () v2:* resolve bad genproto pseudoversion in go.mod () () add ExtractProtoMessage to apierror () () v2:* add OnHTTPCodes CallOption () () v2/apierror:* use errors.As in FromError () () v2:* bump release-please processing () ()
Project: Grafana (Observability and Analysis / Observability)
File: create-plugin.md

labels: products: enterprise oss title: Create Plugin Tooling for modern web development can be tricky to wrap your head around. While you certainly can write your own webpack configuration, for this guide, you'll be using grafana create-plugin tool Grafana is a CLI application that simplifies Grafana plugin development, so that you can focus on code. The tool scaffolds a starter plugin and all the required configuration for you. In the plugin directory, create a plugin from template using create-plugin. When prompted for the kind of plugin, select `datasource`: ``` npx @grafana/create-plugin@latest ``` Change directory to your newly created plugin: ``` cd my-plugin ``` Install the dependencies: ``` yarn install ``` Build the plugin: ``` yarn dev ``` Restart the Grafana server for Grafana to discover your plugin. Open Grafana and go to Connections -> Connect Data. Make sure that your data source is there. By default, Grafana logs whenever it discovers a plugin: ``` INFO[01-01|12:00:00] Plugin registered logger=plugin.loader pluginID=my-plugin ```
Project: Graylog (Observability and Analysis / Observability)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at <lennart@graylog.com>. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_pubcomp_unexpected.md

This alert is related to VerneMQ, a high-performance MQTT message broker. It monitors the number of unexpected PUBCOMP (publish complete) packets received in the last minute. If you receive this alert, it means there's an issue with the MQTT message flow between clients and the broker, which might lead to data inconsistencies. In MQTT, the PUBCOMP packet is used when QoS (Quality of Service) 2 is applied. It's the fourth and final packet in the four-packet flow to ensure that messages are delivered exactly once. An unexpected PUBCOMP packet means that the client or the broker received a PUBCOMP packet that it didn't expect in the message flow, which can cause issues in processing the message correctly. Inspect the VerneMQ logs: Check the VerneMQ logs for any error messages or unusual activity that could indicate a problem with the message flow. By default, VerneMQ logs are located in `/var/log/vernemq/`, but this might be different for your system. ``` sudo tail -f /var/log/vernemq/console.log sudo tail -f /var/log/vernemq/error.log ``` Identify problematic clients: Inspect the MQTT client logs to identify which clients are causing the unexpected PUBCOMP packets. Some MQTT client libraries provide logging features, while others might require debugging or setting a higher log level. Check QoS settings: Ensure that the clients and the MQTT broker have the same QoS settings to avoid inconsistencies in the four-packet flow. Monitor the VerneMQ metrics: Use Netdata or other monitoring tools to keep an eye on MQTT message flows and observe any anomalies that require further investigation. Update client libraries and VerneMQ: Ensure that all MQTT client libraries and the VerneMQ server are up-to-date to avoid any incompatibilities or bugs that could lead to unexpected behavior.
Project: Grafana (Observability and Analysis / Observability)
File: legend-options-2.md

title: Legend mode and legend placement comments: | There are two legend shared files to cover the most common combinations of options. Using two shared files ensures that content remains consistent across visualizations that share the same options and users don't have to figure out which options apply to a specific visualization when reading that content. This file is used in the following visualizations: state timeline, status history When the legend option is enabled it can show either the value mappings or the threshold brackets. To show the value mappings in the legend, it's important that the Color scheme as referenced in is set to Single color or Classic palette. To see the threshold brackets in the legend set the Color scheme to From thresholds. For more information about the legend, refer to . Toggle the switch to turn the legend on or off. Use these settings to define how the legend appears in your visualization. List - Displays the legend as a list. This is a default display mode of the legend. Table - Displays the legend as a table. Choose where to display the legend. Bottom - Below the graph. Right - To the right of the graph. Control how wide the legend is when placed on the right side of the visualization. This option is only displayed if you set the legend placement to Right.
Project: HertzBeat (Observability and Analysis / Observability)
File: springboot3.md

id: springboot3 Title: Monitoring SpringBoot 3.0 sidebar_label: SpringBoot 3.0 keywords: [open source monitoring tool, open source monitoring tool, monitoring springboot3 metrics] Collect and monitor the general performance metrics exposed by the SpringBoot 3.0 actuator. If you want to monitor information in 'SpringBoot' with this monitoring type, you need to integrate your SpringBoot application and enable the SpringBoot Actuator. 1Add POM .XML dependencies: ```xml <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> ``` Modify the YML configuration exposure metric interface: ```yaml management: endpoints: web: exposure: include: '*' enabled-by-default: on ``` Note: If your project also introduces authentication related dependencies, such as springboot security, the interfaces exposed by SpringBoot Actor may be intercepted. In this case, you need to manually release these interfaces. Taking springboot security as an example, you should add the following code to the Security Configuration class: ```java public class SecurityConfig extends WebSecurityConfigurerAdapter{ @Override protected void configure(HttpSecurity httpSecurity) throws Exception{ httpSecurity // Configure the interfaces to be released -- .antMatchers("/actuator/").permitAll() .antMatchers("/metrics/").permitAll() .antMatchers("/trace").permitAll() .antMatchers("/heapdump").permitAll() // ... // For other interfaces, please refer to: https://blog.csdn.net/JHIII/article/details/126601858 -- } } ``` | Parameter Name | Parameter Description | |-|-| | Monitor Host | The monitored peer's IPV4, IPV6, or domain name. Note: Do not include protocol headers (eg: https://, http://). | | Task Name | Identifies the name of this monitor, ensuring uniqueness is necessary. | | Port | The port provided by the application service, default is 8080. | | Enable SSL | Whether to access the website via HTTPS. Note: Enabling HTTPS generally requires changing the default port to 443. | | Collector | Specifies which collector to use for scheduling data collection for this monitor. | | Monitoring Period | Interval for periodically collecting data, in seconds, with a minimum interval of 30 seconds. | | Bind Tags | Tags for categorizing and managing monitored resources. | | Description | Additional identification and description for this monitor, where users can add remarks. | | Metric Name | Unit | Metric Description | |--||--| | responseTime | ms | Response time | | Metric Name | Unit | Metric Description | |-||-| | state | None | Thread state | | size | None | Number of threads for this state | | Metric Name | Unit | Metric Description | |-||--| | space | None | Memory space name | | mem_used | MB | Memory usage for this space | | Metric Name | Unit | Metric Description | |-||| | status | None | Service health status: UP, Down |
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: tcptracer.md

title: Gadget tcptracer Trace tcp connect, accept and close ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: tcptracer namespace: gadget spec: node: ubuntu-hirsute gadget: tcptracer runMode: Manual outputMode: Stream filter: namespace: default ``` Start tcptracer gadget ```bash $ kubectl annotate -n gadget trace/tcptracer \ gadget.kinvolk.io/operation=start ``` Stop tcptracer gadget ```bash $ kubectl annotate -n gadget trace/tcptracer \ gadget.kinvolk.io/operation=stop ``` Stream
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-1.3.8.md

Upgrade Netty to 4.1.86.Final () Upgrade zookeeper dependency in hdfs-fixture () Upgrade `woodstox-core` to 6.4.0 () Upgrade `tika` from 2.4.0 to 2.5.0 () Upgrade `jettison` from 1.5.0 to 1.5.3 Upgrade `protobuf-java` to 3.21.9 () Upgrade hadoop-minicluster to 3.3.4 () Upgrade aws-java-sdk to 1.12.270 () Upgrade reactor-netty-http to 1.0.24 in repository-azure () Upgrade jetty-http, kotlin-stdlib and snakeyaml ()
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: ADOPTERS.md

This is a list of production adopters of Logging Operator: | Company | Industry | | : | :- | | | Drupal site hosting as a service | | | Retail | | | Digital communications technology | | | Software Development/Consultancy | | | Video streaming, Adtech | | | Video streaming and satellite broadcasting. | | | Kubernetes management tool. D2IQ's logging offering is based on the Logging Operator https://docs.d2iq.com/dkp/2.5/logging | | | Optimizing your IT assets from on-premises to the cloud | | | Organizations worldwide trust Fulcrum to help them capture and share reliable data about any field activity, much faster than paper or other digital solutions. | | | E-commerce | | | KubeGems observability/logging is powerd by Banzai Cloud Logging operator | | | AWS Premier Consulting Partner for professional cloud computing services https://liquidreply.net/monitor-your-multi-cluster-environments | | | The Norwegian Labour and Welfare Administration (NAV) uses the Logging Operator in the NAIS application platform | | | Data Recovery Services | | | Kubernetes management tool. RKEs default logging solution is based on the Logging Operator https://ranchermanager.docs.rancher.com/v2.5/pages-for-subheaders/logging |
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-9-1-3.md

aliases: [] hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 9.1.3 <!-- Auto generated by update changelog github action --> API: Do not expose user input in datasource error responses. , Alerting: Write and Delete multiple alert instances. , Library Panel: Allow to delete them when deprecated. , Plugins Catalog: Allow to filter plugins using special characters. , Alerting: Fix UI bug when setting custom notification policy group by. , AppRootPage: Fix issue navigating between two app plugin pages. , Correlations: Use correct fallback handlers. , FIX: RBAC prevents deleting empty snapshots (#54385). , LibraryElements: Fix inability to delete library panels under MySQL. , Metrics: fix `grafanadatabaseconn*` metrics, and add new `gosqlstats*` metrics as eventual replacement. , TestData DB: Fix node graph not showing when the `Data type` field is set to `random`. , The `grafanadatabaseconn*` metrics are deprecated, and will be removed in a future version of Grafana. Use the `gosqlstats*` metrics instead. Issue
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_endpoints.KubeEndpointAddress.md

title: "Interface: KubeEndpointAddress" linkTitle: "KubeEndpointAddress" slug: "libk8sendpoints.KubeEndpointAddress" .KubeEndpointAddress hostname: `string` _ ip: `string` _ `Optional` nodeName: `string` _ `Optional` targetRef: `Pick`<, ``"kind"`` \| ``"apiVersion"``\> & `Pick`<, ``"name"`` \| ``"namespace"`` \| ``"resourceVersion"`` \| ``"uid"``\> & { `fieldPath`: `string` }
Project: Flipt (Observability and Analysis / Feature Flagging)
File: CHANGELOG.md

This format is based on and this project adheres to . Add Kubernetes authentication provider (#2703) Add JWT authentication provider (#2620) `rpc/flipt`: add reference to read request protocols (#2570) `sdk/go`: update rpc/flipt to 1.31.0 `sdk/go`: update rpc/flipt to 1.25.0 `sdk/go`: update rpc/flipt to 1.24.0 new evaluation routes (#1824) `sdk/go`: Datetime constraint type (#1602) `sdk/go`: Add optional description to constraints (#1581) `sdk/go`: regenerate clients to include new namespaces features `sdk/go`: add details regarding the HTTP transport (#1435) protojson to use DiscardUnknown option for backwards compatibility (#1453) Upgraded `rpc/flipt` to `v1.19.3` Upgraded `errors` to `v1.19.3` A new Go SDK for Flipt.
Project: Headlamp (Observability and Analysis / Observability)
File: how-to.md

title: How to create a Plugin linktitle: How-to This section will walk you through a basic plugin development. If you are using Typescript for developing the plugin, the `@kinvolk/headlamp-plugin` package does ship some type declarations in `@kinvolk/headlamp-plugin/types`. Please notice that the whole external plugin mechanics are still in an early development phase and thus only the actual type declarations (and not the corresponding code) is shipped in this package at the moment. The following example will show a basic plugin declaration and registration in a file that should match the `src/index.tsx` structure explained in the section. ```tsx import { registerAppBarAction } from '@kinvolk/headlamp-plugin/lib'; registerAppBarAction(<span>Hello Kubernetes</span>); ``` Let's create a plugin that just gets the number of pods in the cluster and displays that information in the top bar (i.e. registers an "app bar action"). ```tsx import { K8s, registerAppBarAction } from '@kinvolk/headlamp-plugin/lib'; import { Typography } from '@mui/material'; function PodCounter() { const [pods, error] = K8s.ResourceClasses.Pod.useList(); const msg = pods === null ? 'Loading' : pods.length.toString(); return ( <Typography color="textPrimary" sx={{fontStyle: 'italic'}}> {!error ? `# Pods: ${msg}` : 'Uh, pods!?'} </Typography> ); } registerAppBarAction(<PodCounter />); ``` Here is the result, running Headlamp with this plugin and using with a Minikube cluster: Please refer to the section for learning about the different functionality that is available to plugins by the registry.