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

The `vcsaloadhealth` alert indicates the current health status of the VMware vCenter Server Appliance (VCSA) system components. The color-coded health indicators help quickly understand the overall state of the system. Log in to the vCenter Server Appliance Management Interface (VAMI): Open a web browser and navigate to `https://vcsaaddress:5480`, where `vcsaaddress` is the IP address or domain name of the VCSA. Log in with the appropriate credentials (by default, the `root` user). Inspect the health status of VCSA components: Once logged in, go to the `Summary` tab, which displays the health status of various components, such as Database, Management, and Networking. You can hover over the component's health icon to get more information about its status. Check for specific component warnings or critical issues: If any component has a warning or critical health status, click on the `Monitor` tab and then on the component in question to get more details about the specific problem. Review log files: For further investigation, review the log files associated with the affected VCSA component. The log files can be accessed on the VAMI interface under the `Logs` tab. Resolve the issue: Based on the information gathered from the VAMI interface and log files, take appropriate action to resolve the issue or contact VMware support for assistance. Monitor VCSA Health: After resolving the issue, monitor the health status of the VCSA components on the `Summary` tab in VAMI to ensure that the health indicators return to a normal state.
Project: Krkn (Observability and Analysis / Chaos Engineering)
File: io_hog.md

This scenario is based on the arcaflow plugin. The purpose of this scenario is to create disk pressure on a particular node of the Kubernetes/OpenShift cluster for a time span. The scenario allows to attach a node path to the pod as a `hostPath` volume. To enable this plugin add the pointer to the scenario input file `scenarios/arcaflow/io-hog/input.yaml` as described in the Usage section. This scenario takes a list of objects named `input_list` with the following properties: kubeconfig : string the kubeconfig needed by the deployer to deploy the sysbench plugin in the target cluster namespace : string the namespace where the scenario container will be deployed Note: this parameter will be automatically filled by kraken if the `kubeconfig_path` property is correctly set node_selector : key-value map the node label that will be used as `nodeSelector` by the pod to target a specific cluster node duration : string stop stress test after N seconds. One can also specify the units of time in seconds, minutes, hours, days or years with the suffix s, m, h, d or y. target_pod_folder : string the path in the pod where the volume is mounted target_pod_volume : object the `hostPath` volume definition in the format, that will be attached to the pod as a volume io_write_bytes : string writes N bytes for each hdd process. The size can be expressed as % of free space on the file system or in units of Bytes, KBytes, MBytes and GBytes using the suffix b, k, m or g io_block_size : string size of each write in bytes. Size can be from 1 byte to 4m. To perform several load tests in the same run simultaneously (eg. stress two or more nodes in the same run) add another item to the `inputlist` with the same properties (and eventually different values eg. different nodeselectors to schedule the pod on different nodes). To reduce (or increase) the parallelism change the value `parallelism` in `workload.yaml` file
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: TEMPLATE.md

| title | authors | creation-date | last-updated | |-|||--| | title | | yyyy-mm-dd | yyyy-mm-dd | This is the title of the enhancement. It should be short, clear, and descriptive. - - The `Summary` section should be a short description of the enhancement. Before you get started this documentation, We recommend that you read the and check whether the enhancement you are proposing is already in the . This section is for explicitly listing the motivation, goals and non-goals of this proposal. Describe why the change is important and the benefits to users. List the specific goals of the proposal. How will we know that this has succeeded? What is out of scope for this proposal? Listing non-goals helps to focus discussion and make progress. This is where we get down to the nitty gritty of what the proposal actually is. Detail the things that people will be able to do if this is `implemented`. What are the caveats to the implementation? What are some important details that didn't come across above? Go into as much detail as necessary here. This is a good place to discuss core concepts and their relationships. If you want to use images, store images in the `proposals/images` directory. What are the risks of this proposal and how do we mitigate. Think broadly. For example, consider both `security` and how this will `impact the Litmus ecosystem`. If applicable, how will the component be upgraded and downgraded? Make sure this is in the test plan. Consider the following in developing an upgrade/downgrade strategy for this enhancement: What changes (in invocations, configurations, API use, etc.) is an existing cluster required to make on upgrade in order to keep previous behavior? What changes (in invocations, configurations, API use, etc.) is an existing cluster required to make on upgrade in order to make use of the enhancement? The idea is to find the best form of an argument why this enhancement should not be implemented. Similar to the `Drawbacks` section the `Alternatives` section is used to highlight and record other possible approaches to delivering the value proposed by an enhancement. Is their any reference for this proposal? If yes, please mention here.
Project: Zipkin (Observability and Analysis / Observability)
File: feature.md

name: Feature Request about: Please first, look at existing issues to see if the feature has been requested before. labels: enhancement Please first, look at to see if the feature has been requested before. If you don't find anything tell us what problem youre trying to solve. Often a solution already exists! Dont send pull requests to implement new features without first getting our support. Sometimes we leave features out on purpose to keep the project small. Description of the feature Why would this feature help others besides me? What kind of use cases would benefit from this feature? Links to prior art More links
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: linter.md

sidebar_position: 91 description: Lint your config A faulty configuration could make GO Feature Flag not the way you expect. This is why we have introduced the `go-feature-flag-lint` a command line tool validates that a flags file can be parsed by GO Feature Flag. :::tip We recommend you to use this command line in your CI/CD pipelines to avoid any disappointment. ::: ```shell brew tap thomaspoignant/homebrew-tap brew install go-feature-flag-lint ``` ```shell scoop bucket add org https://github.com/thomaspoignant/scoop.git scoop install go-feature-flag-lint ``` ```shell docker pull thomaspoignant/go-feature-flag-lint:latest ``` ```shell ./go-feature-flag-lint \ --input-format=yaml \ --input-file=/input/my-go-feature-flag-config.yaml ``` The command line has 2 arguments you should specify. | param | description | ||-| | `--input-file` | (mandatory) The location of your configuration file. | | `--input-format` | (mandatory) The format of your current configuration file. <br/>Available formats are `yaml`, `json`, `toml`. | You can run `go-feature-flag-lint` using GitHub actions: ```yaml jobs: lint: runs-on: ubuntu-latest steps: uses: actions/checkout@v3 uses: docker://thomaspoignant/go-feature-flag-lint:latest with: args: --input-file=/github/workspace/path/to/your/config.yaml --input-format=yaml ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16050.md

key | value | date | 2024-03-12T07:58:50+00:00 version | 2.4.0b1 class | feature edition | cee component | multisite level | 1 compatible | yes We change the default dashboards "Linux hosts" and "Windows hosts" (Monitor > Overview) to a new layout and partly to new dashboard elements. This change shall improve user experience and provide the most relevant Linux/Windows host information on these boards.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-get_aggreator_by_id.md

category: Aggregator apiurl: '/api/v1/aggregators' title: "Get Aggregator Info by id" type: 'GET' sample_doc: 'aggregator.html' layout: default Required ```{ "tags": "", "step": 60, "numerator": "$(cpu.idle)", "metric": "test.idle", "hostgroup_id": 343, "endpoint": "testenp", "denominator": "2" }``` ```Status: 200``` ```{ "id": 16, "grp_id": 343, "numerator": "$(cpu.idle)", "denominator": "2", "endpoint": "testenp", "metric": "test.idle", "tags": "", "ds_type": "GAUGE", "step": 60, "creator": "root" }```
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_puback_received_reason_unsuccessful.md

This alert tracks the number of `unsuccessful v5 PUBACK packets` received by the VerneMQ broker within the last minute. If you receive this alert, there might be an issue with your MQTT clients or the packets they send to the VerneMQ broker. In MQTT v5, the `PUBACK` packet is sent by the server or subscriber client to acknowledge the receipt of a `PUBLISH` packet. In the MQTT v5 protocol, the `PUBACK` packet can contain a reason code indicating whether the message was successfully processed or if there was an error. Check the VerneMQ logs: Analyze the logs to check for any errors or issues related to the MQTT clients or the incoming messages. VerneMQ's logs are usually located at `/var/log/vernemq/` directory, or you can check the log location in the VerneMQ configuration files. ``` less /var/log/vernemq/console.log less /var/log/vernemq/error.log ``` Verify MQTT clients' configurations: Review your MQTT clients' settings to ensure that they are configured correctly, especially the protocol version, QoS levels, and any MQTT v5 specific settings. Make any necessary adjustments and restart the clients. Monitor VerneMQ performance: Use the VerneMQ `vmq-admin` tool to monitor the broker's performance, check connections, subscriptions, and session information. This can help you identify potential issues affecting the processing of incoming messages. ``` vmq-admin metrics show vmq-admin session list vmq-admin listener show ``` Check the `PUBLISH` messages: Inspect the contents of `PUBLISH` messages being sent by the MQTT clients to ensure they are correctly formatted and adhere to the MQTT v5 protocol specifications. If necessary, correct any issues and send test messages to confirm the problem is resolved.
Project: OpenSearch (Observability and Analysis / Observability)
File: CHANGELOG.md

All notable changes to this project are documented in this file. The format is based on , and this project adheres to . See the for instructions on how to add changelog entries. Add support for Azure Managed Identity in repository-azure () Add useCompoundFile index setting () Make outbound side of transport protocol dependent () Bump `com.github.spullara.mustache.java:compiler` from 0.9.10 to 0.9.13 (, ) Bump `org.gradle.test-retry` from 1.5.8 to 1.5.9 () Bump `org.apache.commons:commons-text` from 1.11.0 to 1.12.0 () Bump `org.hdrhistogram:HdrHistogram` from 2.1.12 to 2.2.1 () Bump `com.gradle.enterprise` from 3.17.2 to 3.17.3 () Bump `org.apache.hadoop:hadoop-minicluster` from 3.3.6 to 3.4.0 () Bump `mockito` from 5.11.0 to 5.12.0 () Add ability for Boolean and date field queries to run when only doc_values are enabled () Refactor implementations of query phase searcher, allow QueryCollectorContext to have zero collectors () Adds support to inject telemetry instances to plugins () Remove handling of index.mapper.dynamic in AutoCreateIndex() Fix negative RequestStats metric issue () Fix get field mapping API returns 404 error in mixed cluster with multiple versions () Allow clearing `remotestore.compatibilitymode` setting ()
Project: Grafana Mimir (Observability and Analysis / Observability)
File: key-value-store.md

aliases: ../../operators-guide/architecture/key-value-store/ description: The key-value store is a database that stores data indexed by key. menuTitle: Key-value store title: Grafana Mimir key-value store weight: 70 A key-value (KV) store is a database that stores data indexed by key. Grafana Mimir requires a key-value store for the following features: Grafana Mimir supports the following key-value (KV) store backends: Gossip-based protocol (default) By default, Grafana Mimir instances use a Gossip-based protocol to join a memberlist cluster. The data is shared between the instances using peer-to-peer communication and no external dependency is required. We recommend that you use memberlist to run Grafana Mimir. To configure memberlist, refer to . {{< admonition type="note" >}} The Gossip-based memberlist protocol isn't supported for the . {{< /admonition >}} Grafana Mimir supports as a backend KV store. If you want to use Consul, you must install it. The Grafana Mimir installation does not include Consul. To configure Consul, refer to . Grafana Mimir supports as a backend KV store. If you want to use etcd, you must install it. The Grafana Mimir installation does not include etcd. To configure etcd, refer to .
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: index.md

The goal of Crane is to provide a one-stop-shop project to help Kubernetes users to save cloud resource usage with a rich set of functionalities: Time Series Prediction based on monitoring data Usage and Cost visibility Usage & Cost Optimization including: R2 (Resource Re-allocation) R3 (Request & Replicas Recommendation) Effective Pod Autoscaling (Effective Horizontal & Vertical Pod Autoscaling) Cost Optimization Enhanced QoS based on Pod PriorityClass Load-aware Scheduling TimeSeriesPrediction defines metric spec to predict kubernetes resources like Pod or Node. The prediction module is the core component that other crane components relied on, like and . Please see to learn more. EffectiveHorizontalPodAutoscaler helps you manage application scaling in an easy way. It is compatible with native but extends more features like prediction-driven autoscaling. Please see to learn more. Analytics model analyzes the workload and provide recommendations about resource optimize. Two Recommendations are currently supported: : Replicas recommendation analyze the actual application usage and give advice for replicas and HPA configurations. : Resource recommendation allows you to obtain recommended values for resources in a cluster and use them to improve the resource utilization of the cluster. Please see to learn more. Kubernetes is capable of starting multiple pods on same node, and as a result, some of the user applications may be impacted when there are resources(e.g. cpu) consumption competition. To mitigate this, Crane allows users defining PrioirtyClass for the pods and QoSEnsurancePolicy, and then detects disruption and ensure the high priority pods not being impacted by resource competition. Avoidance Actions: Disable Schedule: disable scheduling by setting node taint and condition Throttle: throttle the low priority pods by squeezing cgroup settings Evict: evict low priority pods Please see to learn more. Native scheduler of kubernetes can only schedule pods by resource request, which can easily cause a series of load uneven problems. In contrast, Crane-scheduler can get the actual load of kubernetes nodes from Prometheus, and achieve more efficient scheduling. Please see to learn more. Crane is composed of the following components: - main crane control plane. Predictor - Predicts resources metrics trends based on historical data. AnalyticsController - Analyzes resources and generate related recommendations. RecommendationController - Recommend Pod resource requests and autoscaler. ClusterNodePredictionController - Create Predictor for nodes. EffectiveHPAController - Effective HPA for horizontal scaling. EffectiveVPAController - Effective VPA for vertical scaling. - Metric server for driving the scaling. - Ensure critical workloads SLO based on abnormally detection. - This repository defines component-level APIs for the Crane platform. - Financial advisor which collect resource prices from cloud API. - A Kubernetes scheduler which can schedule pod based on actual node load.
Project: Sensu (Observability and Analysis / Observability)
File: CHANGELOG-7.md

All notable changes to this project will be documented in this file. The format is based on and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html). Etcd is no longer supported. All persistent data is now stored in postgresql. The enterprise postgresql event store is no longer supported. Events are now stored in a different format in postgresql, and postgresql is configured with the command line or configuration file (--pg-dsn). Additional environment variables are supported, see the libpq documentation for details. core/v2.Namespace is no longer supported. Users must use core/v3.Namespace, which now allows for the addition of labels and annotations. API keys can no longer be retrieved from the database. The REST APIs now use the wrapped resource format. When multiple asset builds are filtered the first asset build with the highest number of filters is returned. Previously the first filtered asset build was returned regardless of filter count. Removes the deprecated agent socket APIs Disables round robin scheduling. Checks configured with round robin will no longer be scheduled. Metadata in resource definitions is no longer represented at the top level. instead, it is represented underneath the "spec" object. Added sensu-backend configuration for postgresql. Added configuration store selectors to sensu-backend, previously an enterprise feature. Added postgresql support for storing all state and configuration. GlobalResource interface in core/v3 allows core/v3 resources to be marked as global resources. The authentication module now logs successful (INFO) and unsuccessful (ERROR) login attempts. Added a redesigned keepalive system which does not rely on asynchronous notification. Unlike the old system, it is much more resilient in the face of mass outages. This system also underpins the redesigned round robin scheduling system. Added a flag to sensu-agent to prevent the collection of network host information. This information can be quite lengthy and can reduce the overall system performance if agent entities grow to be too large. API keys can now be created with sensuctl create. Added threshold annotation even when OK status Fixed an issue where multi-expression exclusive "Deny" filters were not evaluated as described in the documentation. API keys are now securely stored in the database. Changed parameters for `sensuctl cluster-role create` to be plural Deregistration events are now silenced if a silenced entry exists matching the entity subscriptions and/or a check named `deregistration`. Upgraded Go version to 1.19.5. Old Go versions are not supported. The sensuctl api-key grant command now returns additional information. Handler errors now logged at the error level instead of info level Changed the format of threshold annotations Removed sensu-backend upgrade command. May make an appearance again in later versions. Removed support for older, unsupported postgresql versions.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-user_change_password.md

category: User apiurl: '/api/v1/user/cgpasswd' title: 'Change Password' type: 'PUT' sample_doc: 'user.html' layout: default Required ```{ "new_password": "test1", "old_password": "test1" }``` ```Status: 200``` ```{"message":"password updated!"}```
Project: LinDB (Observability and Analysis / Observability)
File: feature-request.md

name: "\U0001F680 Feature request" about: I want to request a New Feature on the product. title: '[feature]:' labels: feature 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: Checkmk (Observability and Analysis / Observability)
File: 16390.md

key | value | date | 2024-01-31T15:15:29+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes When creating or updating notification rules, the option to "cancelpreviousnotifications" was previously not available when the plugin name selected was a custom plugin script. This werk addresses this issue and now allows for custom plugin scripts when setting the option to cancel.
Project: Checkmk (Observability and Analysis / Observability)
File: 15328.md

key | value | compatible | no version | 2.4.0b1 date | 2024-04-05T09:38:28+00:00 level | 1 class | fix component | checks edition | cre You are affected by this Werk if you use mk_oracle agent plugin on unix. <tt>mk_oracle</tt> only works if it can find a <tt>sqlnet.ora</tt> in your <tt>$TNSADMIN</tt> folder. In the past, <tt>mkoracle</tt> executed all oracle binaries as root, so <tt>sqlnet.ora</tt> was alwas readable. With <a href="https://checkmk.com/werk/16232">Werk #16232</a> the oracle binaries are executed with a low privileged user, so it might be the case, that <tt>sqlnet.ora</tt> can not be read by this user. <tt>mk_oracle</tt> will exit early if it can not read <tt>sqlnet.ora</tt>. The error message might look like: <code> /etc/check_mk/sqlnet.ora can not be read by user "oracle"! Either use 'sqlnet.ora permission group' bakery rule, or directly modify permissions of the file. </code> The error message will also be visible in the <tt>oracle_instance</tt> check. If you use the agent bakery to roll out mk_oracle to unix servers using <tt>.rpm</tt>, <tt>.deb</tt> or Solaris <tt>.pkg</tt> packages, you have to use the 'sqlnet.ora permission group' bakery rule to adapt the group of the <tt>sqlnet.ora</tt> file, otherwise your permission changes might be overwritten by updating the agent. Otherwise it is sufficient to adapt the permissions. If you install the agent on Unix using the <tt>tgz</tt> package, you will have to manually adjust the permissions of the <tt>sqlnet.ora</tt> file.
Project: Chaos Mesh (Observability and Analysis / Chaos Engineering)
File: pull_request_template.md

<!-- Thank you for contributing to Chaos Mesh! If you're unsure where to start, please refer to the contributing doc: https://github.com/chaos-mesh/chaos-mesh/blob/master/CONTRIBUTING.md If you still have questions, please let us know via issues. Please follow https://www.conventionalcommits.org/en/v1.0.0/ when you open a new PR: --> <!-- Uncomment this line if some issues to close --> <!-- Close #<issue number> --> <!-- Uncomment this line if this PR is associated with a proposal --> <!-- Proposal: --> (e.g. docs) [ ] This change also requires further updates to the `UI interface` This PR should be cherry-picked to the following release branches: [ ] release-2.6 [ ] release-2.5 Must include at least one of them. [ ] I have updated the `CHANGELOG.md` [ ] I have labeled this PR with "no-need-update-changelog" Must include at least one of them. [ ] Unit test [ ] E2E test [ ] Manual test [ ] Breaking backward compatibility If you find the DCO check fails, please run commands like below (Depends on the actual situations. For example, if the failed commit isn't the most recent) to fix it: ```shell git commit --amend --signoff git push --force ```