cwielenb/CNCF-Dataset huggingface dataset:
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-2-5.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 8.2.5 <!-- Auto generated by update changelog github action --> Alerting: Fix a bug where the metric in the evaluation string was not correctly populated. , Alerting: Fix no data behaviour in Legacy Alerting for alert rules using the AND operator. , CloudMonitoring: Ignore min and max aggregation in MQL queries. , Dashboards: 'Copy' is no longer added to new dashboard titles. , DataProxy: Fix overriding response body when response is a WebSocket upgrade. , Elasticsearch: Use field configured in query editor as field for date_histogram aggregations. , Explore: Fix running queries without a datasource property set. , InfluxDB: Fix numeric aliases in queries. , Plugins: Ensure consistent plugin settings list response. , Tempo: Fix validation of float durations. , Tracing: Correct tags for each span are shown. , In Grafana 8.2.5 and later, this change fixes a bug in the evaluation of alert rules when using the AND operator to compare two or more conditions. In Grafana 8.2.4 and earlier such alert rules would evaluate to `OK` if at least one, but not all, conditions returned no data. This change fixes that bug such that in Grafana 8.2.5 these alert rules now evaluate to `No Data`. If an alert should evaluate to `OK` when one or all conditions return `No Data` then this can be done via changing `If no data or all values are null` to `OK`. However, this will not preserve the old behaviour in 8.2.4 where an alert will be `OK` if at least one, but not all, conditions return no data and then `No Data` if all conditions return `No Data`. Issue
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_apiProxy.RequestParams.md

title: "Interface: RequestParams" linkTitle: "RequestParams" slug: "libk8sapiProxy.RequestParams" .RequestParams Options for the request. `RequestInit` `RequestParams` `Optional` autoLogoutOnAuthError: `boolean` Whether to automatically log out the user if there is an authentication error. _ `Optional` cluster: ``null`` \| `string` Cluster context name. _ `Optional` isJSON: `boolean` Is the request expected to receive JSON data? _ `Optional` timeout: `number` Number of milliseconds to wait for a response.
Project: Vector (Observability and Analysis / Observability)
File: 2020-11-19-prometheus-remote-integrations.md

date: "2020-11-19" title: "Support for the Prometheus remote write protocol" description: "Interoperability with the Prometheus ecosystem." authors: ["jamtur01"] pr_numbers: [4856, 5144] release: "0.11.0" hideonrelease_notes: false badges: type: "new feature" domains: ["metrics", "sources"] We're big fans of Prometheus at Timber, and as an extension of our Kubernetes integration we wanted to better understand how Vector could assist Prometheus operators. As noted in the , it is our intent to be the only tool needed to collect and process all Kubernetes observability data, and working with Prometheus is core to our metrics strategy. As a result, 0.11.0 includes two new components that assist with a variety of Prometheus use cases: A new A new Using the new , Prometheus operators can route a stream of Prometheus data to the archiving solution of their choice. For this use case we recommend object stores for their cheap and durable qualities: ```toml title="vector.toml" [sources.prometheus] type = "prometheusremotewrite" [transforms.convert] type = "metrictolog" inputs = ["prometheus"] [sinks.backup] type = "aws_s3" inputs = ["convert"] ``` Swap `awss3` with `gcpcloud_storage` or other object stores. For large setups it's common to couple Prometheus with another solution designed for long term storage and querying. This separates the concerns of fast short term querying and long-term low cost archiving. With the new , users can only retain near-term data in Prometheus and store long term metrics in databases like , , and . Not using Prometheus? It's very common to use Prometheus as a central proxy for exporting all metrics data. This is especially relevant in ecosystems like Kubernetes where Prometheus is tightly integrated. To get started, setup the new and send your metrics to , , , , and : ```toml title="vector.toml" [sources.prometheus] type = "prometheusremotewrite" [sinks.datadog] type = "datadog_metrics" inputs = ["prometheus"] ```
Project: Grafana (Observability and Analysis / Observability)
File: value-mappings-options.md

title: Value mappings options comments: | This file is used in the following visualizations: bar chart, bar gauge, candlestick, canvas, gauge, geomap, histogram, pie chart, stat, state timeline, status history, table, time series, trend Value mapping is a technique you can use to change how data appears in a visualization. For each value mapping, set the following options: Condition - Choose what's mapped to the display text and (optionally) color: Value - Specific values Range - Numerical ranges Regex - Regular expressions Special - Special values like `Null`, `NaN` (not a number), or boolean values like `true` and `false` Display text Color (Optional) Icon (Canvas only) To learn more, refer to .
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_socket_errors.md

This alert is related to the VerneMQ MQTT broker, and it triggers when there is a high number of socket errors in the last minute. Socket errors can occur due to various reasons, such as network connectivity issues or resource contention on the system running the VerneMQ broker. Socket errors are issues related to network communication between the VerneMQ broker and its clients. They usually occur when there are problems establishing or maintaining a stable network connection between the server and clients. Examples of socket errors include connection timeouts, connection resets, unreachable hosts, and other network-related problems. Check the VerneMQ logs for more information: VerneMQ logs can give you a better understanding of the cause of the socket errors. You can find the logs at `/var/log/vernemq/console.log` or `/var/log/vernemq/error.log`. Look for any errors or warning messages that might be related to the socket errors. Monitor the system's resources: Use the `top`, `vmstat`, `iostat`, or `netstat` commands to monitor your system's resource usage, such as CPU, RAM, disk I/O, and network activity. Check if there are any resource bottlenecks or excessive usage that might be causing the socket errors. Check network connectivity: Verify that there are no issues with the network connectivity between the VerneMQ broker and its clients. Use tools such as `ping`, `traceroute`, or `mtr` to check the connectivity and latency of the network. Make sure the VerneMQ broker is running: Ensure that the VerneMQ broker process is running and listening for connections. You can use the `ps` command to check if the `vernemq` process is running, and the `netstat` command to verify that it's listening on the expected ports. Inspect client configurations and logs: It's possible that the root cause of the socket errors is related to the MQTT clients. Check their configurations and logs for any signs of issues or misconfigurations that could be causing socket errors when connecting to the VerneMQ broker.
Project: Checkmk (Observability and Analysis / Observability)
File: 16312.md

key | value | compatible | yes version | 2.3.0b1 date | 2024-01-23T14:21:12+00:00 level | 1 class | fix component | multisite edition | cre If you used the "Properties" option within the "Dashboard" page menu in dashboards and chose "Save & go to list" after editing the dashboard, you have seen an error like "This page was not found. Sorry.".
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_pubrec_invalid_error.md

This alert is triggered when the Netdata Agent monitors an unexpected increase in the number of VerneMQ v3 MQTT `PUBREC` packets received during the last minute. VerneMQ is an MQTT broker that is essential for message distribution in IoT applications. MQTT v3 is one of the protocol versions used by the MQTT brokers. `PUBREC` is a control packet in the MQTT protocol that acknowledges receipt of a `PUBLISH` packet. This packet is used during Quality of Service (QoS) level 2 message delivery, ensuring that the message is received exactly once. An invalid `PUBREC` packet means that VerneMQ has received a `PUBREC` packet that contains incorrect, unexpected, or duplicate data. Check VerneMQ logs Investigate the VerneMQ logs to see if there are any error messages or warnings related to the processing of `PUBREC` packets. The logs can be found in `/var/log/vernemq/console.log` or `/usr/local/var/log/vernemq/console.log`. Look for any entries with specific error messages mentioning `PUBREC`. Check MQTT Clients Monitor the MQTT clients that are connected to the VerneMQ broker to identify which clients are sending invalid `PUBREC` packets. Check the logs or monitoring systems of those clients to understand the root cause of the problem. They might be experiencing issues or bugs causing them to send incorrect `PUBREC` packets. Check the MQTT topics Monitor the MQTT topics with high levels of QoS 2 message delivery and determine if a specific topic is causing the spike in invalid `PUBREC` packets. Upgrade or fix MQTT Clients If the issue arises from specific client implementations, consider upgrading the MQTT client libraries, fixing any configuration issues or reporting the bug to the appropriate development teams. Review VerneMQ configuration Verify that the VerneMQ broker configuration is set up correctly and that MQTT v3 protocol is enabled. If necessary, adjust the configuration to better handle the volume of QoS 2 messages being processed.
Project: Teletrace (Observability and Analysis / Observability)
File: pull_request_template.md

<!-- Thanks for sending a pull request! Before submitting: Read our CONTRIBUTING.md guide Rebase your PR if it gets out of sync with main --> Fixes #<issue number> [ ] Tests updated [ ] Documentation added [ ] `CHANGELOG.md` updated - the order of entries should be `[CHANGE]`, `[FEATURE]`, `[ENHANCEMENT]`, `[BUGFIX]`
Project: Promscale (Observability and Analysis / Observability)
File: PromscaleIngestHighLatency.md

Promscale data ingestion is taking more time than expected Ingestion performance will be poor Go to grafana dashboard about Promscale and check the Network latency panel in Database row. If latency is high, go to . Go to grafana dashboard about Promscale and check Evictions panel in Cache row. If you see high eviction rate, it means that Promscale caches are too small and you need to adjust it (go to for mitigation steps) Run query `select datname, count(applicationname) from pgstatactivity where applicationname like '%promscale%' group by datname;`. This will give you the total number of Postgres connections taken by Promscale per database. This should be roughly equal to the number of CPU cores on the database machine. Go to for mitigation steps. Verify CPU and memory resource consumption of the timescale DB. Go to for mitigation steps. Allocate more resources to the database. Tune the database. Refer to to do so. Check Promscale on `remote_write` configuration for Prometheus server Adjust alert threshold according to your infrastructure Increase the writer connections count. This can be done in Promscale via `-db.num-writer-connections` flag If step 1 does not work, increase `-db.connections-max` The Evictions panel in Promscale dashboard will give the exact cache which is causing the slow down Increase the cache size. See the `cache` based flags
Project: Netdata (Observability and Analysis / Observability)
File: 1m_internal_errors.md

This alert indicates that there has been an increase in the number of HTTP 5XX server errors in the last minute. These errors typically indicate a problem with the server's ability to process requests, such as misconfigurations, overloaded resources, or other server-side issues. Inspect server logs: Check the server error logs for any error messages, warnings, or unusual patterns. For Apache and Nginx, the error logs are usually found under `/var/log/{apache2, nginx}/error.log`. Analyze the logs to identify potential issues with the server, such as misconfigurations or resource limitations. Check .htaccess file: If you're using Apache, examine the `.htaccess` file for any misconfigurations or incorrect settings. Ensure that the directives in the file are valid and properly formatted. If necessary, temporarily disable the `.htaccess` file to see if it resolves the issue. Review server resources: Monitor the server's CPU, RAM, and disk usage to determine if the server is experiencing resource limitations. High resource usage can lead to server errors, as the server may be unable to handle incoming requests. Consider upgrading your server resources or optimizing the server for better performance. Examine server software: Check for any issues with the server software, such as outdated versions, security vulnerabilities, or software bugs. Update your server software to the latest version and apply any necessary patches to resolve potential issues. Monitor third-party services: If your server relies on third-party services or APIs, verify that these services are functioning correctly. Server errors may occur if your server is unable to communicate with these services or if they are experiencing downtime. Test server functionality: Use tools such as `curl` or web browser developer tools to send HTTP requests to your server and examine the responses. This can help you identify specific issues with the server, such as incorrect response headers or missing resources.
Project: Checkmk (Observability and Analysis / Observability)
File: 16343.md

key | value | date | 2024-03-27T14:51:09+00:00 version | 2.3.0b4 class | feature edition | cee component | wato level | 1 compatible | no Users who have configured the 'Load environment variable from file' field in the Robotmk Scheduler rule are affected by this incompatible werk. Any rules that contain the value for this field will be automatically migrated during the update and the value will be removed from the rules. Originally, this field was designed to be fully compatible with Robots that could be used within Robocorp's cloud environment. However, as Robocorp shifted its focus from Robot Framework to Python developers, the need for the VS Code extensions provided by Robocorp became redundant. The language server for Robot Framework would no longer be maintained, and the "RobotCode" extension would no longer serve Robot Framework users. In addition, both extensions had a rather confusing interface and didn't work well together. Now the RobotCode extension is the only necessary extension for VS Code, and it works very well. The env.json file generated from this field was used exclusively by the Robocorp extension. This approach allowed local initiation and debugging of automations with the exact set of environment variables configured, mirroring those set later in the Cloud UI. For the above reasons, we decided to remove this field.
Project: Logstash (Observability and Analysis / Observability)
File: ROADMAP.md

is a data collection engine that is developed directly on Github. The roadmap is defined by the core themes of performance, resiliency, and manageability, along with the overall plugin ecosystem. User requirements are the main driving force behind our development efforts. If a user has a bad time, its a bug! All submitted , suggestions, or ideas are greatly encouraged and appreciated. With an open development model, the core roadmap can generally be distilled in Github. Long term roadmap features can be viewed with the "" label. The features and bug fixes targeted for an upcoming release can be viewed with the specific release label, e.g. "". Please note that feature timing and priorities are susceptible to change and therefore not guaranteed. The ecosystem enables the innovation of additional integrations and processing capabilities for the core engine. Plugins in this organization are either maintained by Elastic or the community. Community maintained plugins have a special banner in the documentation page, e.g. . Many awesome humans have taken the roadmap into their own hands by becoming community maintainers. If youre actively working with specific community plugins and would like to get more involved, feel free to reach out in this . For a list of latest changes across Logstash and its plugins, see the .
Project: Netdata (Observability and Analysis / Observability)
File: web_log_10m_response_time.md

This alert calculates the average `HTTP response time` of your web server over the last 10 minutes. If you receive this alert, it means that the `latency` of your web server has increased, and might be affecting the user experience. `HTTP response time` is a measure of the time it takes for your web server to process a request and deliver the corresponding response to the client. A high response time can lead to slow loading pages, indicating that your server is struggling to handle the requests or there are issues with the network. Check the server load: A high server load can cause increased latency. Check the server load using tools like `top`, `htop`, or `glances`. If server load is high, consider optimizing your server, offloading some services to a separate server, or scaling up your infrastructure. ``` top ``` Analyze the web server logs: Look for patterns or specific requests that may be causing the increased latency. This can be achieved by parsing logs and correlating the response time with requests. For example, for Apache logs: ``` sudo cat /var/log/apache2/access.log | awk '{print $NF " " $0}' | sort -nr | head -n 10 ``` For Nginx logs: ``` sudo cat /var/log/nginx/access.log | awk '{print $NF " " $0}' | sort -nr | head -n 10 ``` Network issues: Check if there are any issues with the network connecting your server to the clients, such as high latency, packet loss or a high number of dropped packets. You can use the `traceroute` command to diagnose any network-related issues. ``` traceroute example.com ``` Review your server's configuration: Check your web server's configuration for any issues, misconfigurations, or suboptimal settings that may be causing the high response time. Monitoring and profiling: Use application monitoring tools like New Relic, AppDynamics, or Dynatrace to get detailed insights about the response time and locate any bottlenecks or problematic requests.
Project: SkyWalking (Observability and Analysis / Observability)
File: dynamic-config-consul.md

is also supported as a Dynamic Configuration Center (DCC). To use it, please configure it as follows: ```yaml configuration: selector: ${SW_CONFIGURATION:consul} consul: hostAndPorts: ${SWCONFIGCONSULHOSTAND_PORTS:1.2.3.4:8500} period: ${SWCONFIGCONSUL_PERIOD:1} aclToken: ${SWCONFIGCONSULACLTOKEN:""} ``` Single configs in Consul are key/value pairs: | Key | Value | |--|--| | configKey | configValue | e.g. The config is: ``` {agent-analyzer.default.slowDBAccessThreshold}:{default:200,mongodb:50} ``` The config in Consul is: | Key | Value | |--|--| | agent-analyzer.default.slowDBAccessThreshold | default:200,mongodb:50 | | ... | ... | Group config in Consul are key/value pairs as well, but according to the level keys organized by `/`. | Key | Value | |--|--| | configKey/subItemkey1 | subItemValue1 | | configKey/subItemkey2 | subItemValue2 | | ... | ... | If we use Consul UI, we can see keys organized like a folder: ``` configKey -- subItemkey1 -- subItemkey2 ... ``` e.g. The config is: ``` {core.default.endpoint-name-grouping-openapi}:|{customerAPI-v1}:{value of customerAPI-v1} |{productAPI-v1}:{value of productAPI-v1} |{productAPI-v2}:{value of productAPI-v2} ``` The config in Consul is: | Key | Value | |--|--| | core.default.endpoint-name-grouping-openapi/customerAPI-v1 | value of customerAPI-v1 | | core.default.endpoint-name-grouping-openapi/productAPI-v1 | value of productAPI-v1 | | core.default.endpoint-name-grouping-openapi/productAPI-v2 | value of productAPI-v2 |
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: lenskart.md

is one of the premium eyewear companies with a presence in the retail sector. has a lot of flagship products some of them like BluO and airflex which are very popular among customers. also has subsidiary retail eyewear companies like and . is not only a retail shop but has an omnichannel business model which serves customer from online and offline stores spread not only across India but also expanding gloablly. not only serves fashion products to customer but also power eyeglasses and contact lenses which are custom made for every customer. This makes it a very niche product as well as an company serving essentials commodities for it's customer. Delivery and ease of ordering from online and offline stores is what we take very seriously. Any downtime could cost not only business but also could impact delivery of his/her eyeglasses or contact lenses. As an engineering team who is always accepting challenges , we started looking at chaos engineering very seriously once we also faced some major downtimes in our platform due to system failure or DDOS attacks. It didn't take us time to realize that just running shop on the cloud was not good enough we have to be prepared for chaotic situations, not just that, we also have to simulate it and find weak points in our architecture. So, we first started with manual and scripted chaos, but the problem was that they were hard to reproduce and involved a lot of effort to plan and execute them. Then we started exploring if we could have a framework which could help us maintain our chaos experiments in form of templates. After looking at a couple of tools we narrowed down on Litmus. We started using Litmus from our devops kubernetes cluster , where we first started to test stateful service like redis cluster or elasticsearch. We then gradually started testing our own application services using Litmus. We have gradually moved from our integration environments to pre-production. We are regularly maturing our hypothesis and writing relevant experiments for these services. Currently, we haven't integrated these experiments into our CI/CD pipelines but in the future we have plans to run these experiments with every release. We are quite new to Litmus framework but what we have really gained from Litmus is templating of our chaos experiments and able to maintain them in our CVS. This has really helped us with the reproducibility of the experiments. It has opened new opportunities for us where we can write our own custom experiments which might be very specific targetting our in-house and public services. We have started ranking the experiments and adding them to our experiment suite so that we could now measure the reasiliency of our services. This would also help us in future to be more targeted in our resiliency journey.