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

This alert calculates the average number of TCP resets (`OutRsts`) sent by the host over the last minute. If you receive this alert, it means that your system is experiencing an unusually high rate of TCP resets, which might signal connection issues or potential attacks. A TCP reset (or RST packet) is a signal used in the Transmission Control Protocol (TCP) to abruptly close an active connection between two devices. It can be sent by either the client or server to inform the other party that they should consider the connection terminated. When there's a high rate of TCP resets sent by a host, it generally indicates problems in communication with other devices or services. This could be due to network latency, misconfigured firewalls, or aggressive timeouts causing connections to break. In some cases, it could also signal a potential Denial of Service (DoS) attack, where an attacker sends multiple resets to disrupt a service or network. Check the network performance Investigate if there are any network latency issues or congestion in your system. You can use tools like `ping`, `traceroute`, or `mtr` to check the network quality and connectivity to other hosts. Analyze packet captures for communication issues Use a packet capture tool like `tcpdump` or `Wireshark` to capture and analyze network traffic during the period of high resets. Look for patterns or specific connections that are frequently terminated with a reset. This could help pinpoint misconfigured services, firewalls, or devices causing the issue. Check firewall settings Ensure that your firewall settings are properly configured to allow necessary connections and not aggressively closing them. Look for rules related to connection timeouts, max connections, and SYN flood protection to see if they might be causing the resets. Review system logs for errors Check system and application logs for any error messages or events that correlate to the time of the alert. This might give you more information about the cause of the issue. Monitor for potential attacks If the above steps don't help determine the cause, consider monitoring your network and system for potential DoS attacks. Implement security measures such as rate-limiting and access control to protect your services and network from malicious traffic.
Project: Graylog (Observability and Analysis / Observability)
File: FormControl.md

```js import { FormGroup, ControlLabel, HelpBlock } from 'components/bootstrap'; class FormExample extends React.Component { constructor(props, context) { super(props, context); this.handleChange = this.handleChange.bind(this); this.state = { value: '' }; } getValidationState() { const length = this.state.value.length; if (length > 10) return 'success'; if (length > 5) return 'warning'; if (length > 0) return 'error'; return null; } handleChange(e) { this.setState({ value: e.target.value }); } render() { return ( <form> <FormGroup controlId="formBasicText" validationState={this.getValidationState()} > <ControlLabel>Working example with validation</ControlLabel> <FormControl type="text" value={this.state.value} placeholder="Enter text" onChange={this.handleChange} /> <FormControl.Feedback /> <HelpBlock>Validation is based on string length.</HelpBlock> </FormGroup> </form> ); } } <FormExample /> ```
Project: OpenFeature (Observability and Analysis / Feature Flagging)
File: appendix-c-ofrep.md

id: appendix-c title: "Appendix C: OpenFeature Remote Evaluation Protocol" description: A unified protocol for feature flagging sidebar_position: 5 OpenFeature Remote Evaluation Protocol (OFREP) is a unified feature flag evaluation protocol that adheres to the OpenFeature semantics. You can find proposals, discussions and the progress at the dedicated repository. There is a dedicated for this initiative that focuses on: Feature flag evaluation protocol Telemetry enrichment of the evaluations Reference implementations of the protocol If you are interested in this initiative, you can join the Slack channel on the workspace.
Project: Centreon (Observability and Analysis / Observability)
File: README.md

Postman collections must be stored in `collections/<feature_name>` Additional subdirectories can be added (ex: `collections/authentication/password_policy`) Multiple collections, which are suffixed by `.postman_collection.json`, can be added in the created directories. An environment file, which is suffixed by `.postman_environment.json`, must be added at the same level as the postman collection. A docker environment file `.env` can be added at the same level as the postman collection. The main usage is to set the following environment variables : `CENTREON_DATASET=0` # avoid creating sample resources (hosts, services...) `MYSQL_IMAGE=bitnami/mysql:8.3` # use mysql instead of mariadb A script `setup.sh` can be added at the same level as the postman collection. It is run on the host machine once the web container is started and healthy (before the postman collection is run). Usage example: `docker compose -f $(dirname $0)/../../../../../.github/docker/docker-compose.yml cp $(dirname $0)/images/myimage.png web:/usr/share/centreon/www/img/media/myimage.png` to copy image in web container A script `setup-web.sh` can be added at the same level as the postman collection. It is run in the web container once it is started and healthy (before the postman collection is run). Usage example: `sed -i 's@"dashboard": 0@"dashboard": 3@' /usr/share/centreon/config/features.json` to update dashboard feature flags
Project: Netdata (Observability and Analysis / Observability)
File: cockroachdb_unavailable_ranges.md

This alert indicates that there are unavailable ranges in your CockroachDB cluster. Unavailable ranges occur when a majority of a range's replicas are on nodes that are unavailable. This can cause the entire range to be unable to process queries. Check for dead or unavailable nodes Use the `./cockroach node status` command to list the status of all nodes in your cluster. Look for nodes that are marked as dead or unavailable and try to bring them back online. ``` ./cockroach node status --certs-dir=<yourcertdirectory> ``` Inspect the logs CockroachDB logs can provide valuable information about issues that may be affecting your cluster. Check the logs for errors or warnings related to unavailable ranges using `grep`: ``` grep -i 'unavailable range' /path/to/cockroachdb/logs ``` Check replication factor Make sure your cluster's replication factor is set to an appropriate value. A higher replication factor can help tolerate node failures and prevent unavailable ranges. You can check the replication factor by running the following SQL query: ``` SHOW CLUSTER SETTING kv.range_replicas; ``` To set the replication factor, run the following SQL command: ``` SET CLUSTER SETTING kv.rangereplicas=<desiredreplication_factor>; ``` Investigate and resolve network issues Network issues can cause nodes to become unavailable and lead to unavailable ranges. Check the status of your network and any firewalls, load balancers, or other network components that may be affecting connectivity between nodes. Monitor and manage hardware resources Insufficient hardware resources, such as CPU, memory, or disk space, can cause nodes to become unavailable. Monitor your nodes' resource usage and ensure that they have adequate resources to handle the workload. Consider rebalancing the cluster Rebalancing the cluster can help distribute the load more evenly across nodes and reduce the number of unavailable ranges. See the for more information on manual rebalancing.
Project: SkyWalking (Observability and Analysis / Observability)
File: backend-init-mode.md

The SkyWalking backend supports multiple storage implementors. Most of them would automatically initialize the storage, such as Elastic Search or Database, when the backend starts up first. But there may be some unexpected events that may occur with the storage, such as `When multiple Elastic Search indexes are created concurrently, these backend instances would startup at the same time.`, When there is a change, the APIs of Elastic Search would be blocked without reporting any exception. This often happens on container management platforms, such as k8s. This is where you need the Init mode startup. Only a single instance should run in the Init mode before other instances start up. And this instance will exit graciously after all initialization steps are done. Use `oapServiceInit.sh`/`oapServiceInit.bat` to start up backend. You should see the following logs: 2018-11-09 23:04:39,465 - org.apache.skywalking.oap.server.starter.OAPServerStartUp -2214 [main] INFO [] - OAP starts up in init mode successfully, exit now... Initialization in this mode would be included in our Kubernetes scripts and Helm.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: --feature-request.md

name: "\U0001F680Feature request" about: Suggest an idea for this project title: '' labels: '' assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: Trickster (Observability and Analysis / Observability)
File: LICENSE.md

Copyright (c) 2014-2015, Philip Hofer Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-5-0-beta1.md

hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 8.5.0-beta1 <!-- Auto generated by update changelog github action --> Add config option to enable/disable reporting. (Enterprise) Alerting: Accurately set value for prom-compatible APIs. , Alerting: Provisioning API - Notification Policies. , Analytics: Enable grafana and plugin update checks to be operated independently. , Azure Monitor: Add support for multiple template variables in resource picker. , Caching: Add separate TTL for resources cache. (Enterprise) Caching: add support for TLS configuration for Redis Cluster. (Enterprise) NewsPanel: Remove Use Proxy option and update documentation with recommendations. , OAuth: Sync GitHub OAuth user name to Grafana if it's set. , Plugins: Fix Default Nav URL for dashboard includes. , When user is using Github OAuth, GitHub login is showed as both Grafana login and name. Now the GitHub name is showed as Grafana name, and GitHub login is showed as Grafana Login. Issue The meaning of the default data source has now changed from being a persisted property in a panel. Before when you selected the default data source for a panel and later changed the default data source to another data source it would change all panels who were configured to use the default data source. From now on the default data source is just the default for new panels and changing the default will not impact any currently saved dashboards. Issue
Project: Checkmk (Observability and Analysis / Observability)
File: 16689.md

key | value | date | 2024-04-17T06:27:51+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | no This werk only affects users and maintainers of custom check plugins developed against the API that was replaced in Checkmk 2.0.0. The old API for the plugins residing in `local/share/check_mk/checks` will no longer be stable in Checkmk version 2.3. Plugins not maintained by Checkmk will almost certainly be incompatible and therefore ignored. Compatible plugins will be considered, but the notion of what constitutes a compatible plugin may change any time. As of Checkmk version 2.2 plugins in that folder generated a warning on the commandline and resulted in an <i>"Analyze Configuration"</i> test issueing a WARNING. We now escalate this to CRITICAL. Incompatible plugins are reported during `omd update`. If you maintian such plugins, please migrate them to the new API before upgrading to Checkmk 2.3. You can find a blog post on how to migrate these plugins . A comprehensive guide on how to write plugins is found . Please also refer to the APIs documentation found in your site (Help -> Check plugin API reference). Commandline call plugins for special agents and active checks in this folder will still work, but we provide a new API for those as well now (see ). They will stop working in Checkmk 2.4.
Project: M3 (Observability and Analysis / Observability)
File: issue_template.md

General issues are any non-performance related issues (data integrity, ease of use, error messages, configuration, documentation, etc). Please provide the following information along with a description of the issue that you're experiencing: What service is experiencing the issue? (M3Coordinator, M3DB, M3Aggregator, etc) What is the configuration of the service? Please include any YAML files, as well as namespace / placement configuration (with any sensitive information anonymized if necessary). How are you using the service? For example, are you performing read/writes to the service via Prometheus, or are you using a custom script? Is there a reliable way to reproduce the behavior? If so, please provide detailed instructions. If the issue is performance related, please provide the following information along with a description of the issue that you're experiencing: What service is experiencing the performance issue? (M3Coordinator, M3DB, M3Aggregator, etc) Approximately how many datapoints per second is the service handling? What is the approximate series cardinality that the series is handling in a given time window? I.E How many unique time series are being measured? What is the hardware configuration (number CPU cores, amount of RAM, disk size and types, etc) that the service is running on? Is the service the only process running on the host or is it colocated with other software? What is the configuration of the service? Please include any YAML files, as well as namespace / placement configuration (with any sensitive information anonymized if necessary). How are you using the service? For example, are you performing read/writes to the service via Prometheus, or are you using a custom script? In addition to the above information, CPU and heap profiles are always greatly appreciated. CPU and heap profiles are critical to helping us debug performance issues. All our services run with the server enabled by default. Instructions for obtaining CPU / heap profiles for various services are below, please attach these profiles to the issue whenever possible. CPU `curl <HOSTNAME>:<PORT(default 7201)>/debug/pprof/profile?seconds=5 > m3coordcpu.out` Heap `curl <HOSTNAME>:<PORT(default 7201)>/debug/pprof/heap > m3coordheap.out` CPU `curl <HOSTNAME>:<PORT(default 9004)>/debug/pprof/profile?seconds=5 > m3dbcpu.out` Heap `curl <HOSTNAME>:<PORT(default 9004)>/debug/pprof/heap -> m3dbheap.out` If the service experiencing performance issues is M3DB and you're monitoring it using Prometheus, any screenshots you could provide using dashboard would be helpful.
Project: Grafana (Observability and Analysis / Observability)
File: SECURITY.md

This product is in scope for our Bug Bounty Program. To submit a vulnerability report, please visit and follow the instructions provided. Our security team will review your submission and get back to you as soon as possible. For any other security issues, please send an email to security@grafana.com Please encrypt your message to us; please use our PGP key. The key fingerprint is: 225E 6A9B BB15 A37E 95EB 6312 C66A 51CC B44C 27E0 The key is available from . Grafana Labs will send you a response indicating the next steps in handling your report. After the initial reply to your report, the security team will keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance. Important: We ask you to not disclose the vulnerability before it have been fixed and announced, unless you received a response from the Grafana Labs security team that you can do so. We will post a summary, remediation, and mitigation details for any patch containing security fixes on the Grafana blog. The security announcement blog posts will be tagged with the . You can also track security announcements via the .
Project: Vector (Observability and Analysis / Observability)
File: papertrail.md

title: Papertrail description: Deliver log events to from SolarWinds component_kind: sink layout: component tags: ["papertrail", "solarwinds", "component", "sink", "logs"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Checkmk (Observability and Analysis / Observability)
File: 16409.md

key | value | date | 2024-03-07T17:16:21+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes In Werk #14573, the deprecation of the options 'IP Address' and 'Host name' of the rules Prometheus and Alertmanager was announced and described. This Werk removes these options.
Project: Checkmk (Observability and Analysis / Observability)
File: 15720.md

key | value | date | 2024-01-18T13:15:53+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes The "Docker node info" service reports about failures of the mk_docker agent plugin. In the past it always only reported one error per check cycle, which now changed to displaying all reported issues.
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: rudderstack.md

title: RudderStack Integration description: Integrate Flagsmith with RudderStack sidebar_label: RudderStack hide_title: true You can integrate Flagsmith with RudderStack. Send your Identity flag states into RudderStack for further downstream analysis. Get the RudderStack API key for your RudderStack project. Add an HTTP API source, and make a note of the `Write Key`. Make a note of the RudderStack Data Plane URL. Go to your Flagsmith project, and click Integrations. Add the RudderStack Integration. Paste the `Write Key` from step 1 into the API Key field in Flagsmith. Select the Flagsmith Environment that you want to send events from. Then hit Save. All API calls generated by the Flagsmith SDK to the `Get Identity Flags` endpoint will send the a full set of flag evaluations for that particular user to RudderStack. :::tip For flags that contain remote config values, Flagsmith will pass the value of the flag to RudderStack if the flag is `enabled`. If the flag has no remote config value, Flagsmith will just pass the boolean state for the flag. ::: Identity flag values are passed into RudderStack. If we make the call to the Flagsmith API to get the flags for an Identity: ```bash curl 'https://edge.api.flagsmith.com/api/v1/identities/?identifier=developmentuser123456' \ -H 'x-environment-key: 8KzETdDeMY7xkqkSkY3Gsg' ``` And then take a look in our RudderStack dashboard, you can see the user and the flag data that has been sent to the RudderStack platform. Once the integration has been set up, you can start segmenting your RudderStack identities based on the flags that they saw. This means you can run AB tests driven by Flagsmith segments, and have the data show up automatically in RudderStack. You have to identify users on both platforms in the same way. The Flagsmith `Identity ID` must be the same as the RudderStack `user_id`.
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: features.md

title: Features sidebar_position: 110 The import and export of feature data associated with a given environment is possible on Flagsmith. The feature data that's exported includes multivariate features, but does not include other data that's associated with tags, owners, group owners, etc. It's useful for transfering features between any running instances of Flagsmith, even when only a subset of features (e.g., importing features of a given tag) are needed. On the Export tab of the project settings page it is possible to export the project's features using the environment's values. Simply select the source environment from the drop down list and, if required, select one or more feature tags to filter the features. By tapping the Export Features button the feature export should quickly process and a list of processed features exports is available at the bottom of the page. :::tip Feature exports are available for only two weeks, so if an export is needed for a longer period of time be sure to make a local backup. ::: On the Import tab of the project settings page you'll find the feature import functionality complete with file upload at the bottom of the page. :::caution The target environment is the environment to inherit the features of the exported environment. All other environments will be set to the values defined when the feature was initially created. Use with caution, especially when using with the Overwrite Destructive merge strategy. ::: Since a feature may have an identical name it's important to carefully select a merge strategy during a feature import. The first option is the Skip strategy which allows an import to process a feature export and at any time a feature has a pre-existing feature present it skips the import for that given feature. For example, if a user is importing ten features but two of them were already there, only eight features will be added to the project. This strategy is best for organisations that want to hold onto their existing data as close as possible. The second option is the Overwrite Destructive strategy. In contrast to the Skip strategy the Overwrite Destructive method clobbers over your existing features and it's important to remember that this is across all environments. This strategy is most useful only when every feature that was included in the export was vetted to be authoritative in the target project.