cwielenb/CNCF-Dataset huggingface dataset:
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-1.2.4.md

Update FIPS API libraries of Bouncy Castle (#1853) (#1888) Thu, 13 Jan 2022 10:48:38 -0500 EAD -&gt; refs/heads/1.2, tag: refs/tags/1.2.4, refs/remotes/upstream/1.2 Update bc-fips to 1.0.2.1 Signed-off-by: Tianli Feng &lt;ftl94@live.com&gt; Update bcpg-fips to 1.0.5.1 Signed-off-by: Tianli Feng &lt;ftl94@live.com&gt; Update bctls-fips to 1.0.12.2 Signed-off-by: Tianli Feng &lt;ftl94@live.com&gt; Use the unified bouncycastle version for bcpkix-jdk15on in HDFS testing fixture Signed-off-by: Tianli Feng &lt;ftl94@live.com&gt; [Backport 1.2] Replace JCenter with Maven Central. (#1057) and update plugin repository order. (#1894) Wed, 12 Jan 2022 15:18:22 -0800 Replace JCenter with Maven Central. (#1057) On February 3 2021, JFrog the shutdown of JCenter. Later on April 27 2021, an update was provided that the repository will only be read only and new package and versions are no longer accepted on JCenter. This means we should no longer use JCenter for our central artifacts repository. This change replaces JCenter with Maven Central as per the Gradle recommendation - https://blog.gradle.org/jcenter-shutdown Signed-off-by: Rabi Panda &lt;adnapibar@gmail.com&gt; Define plugin repositories order in settings.gradle. Signed-off-by: Marc Handalian &lt;handalm@amazon.com&gt; Co-authored-by: Rabi Panda &lt;adnapibar@gmail.com&gt; Updatting Netty to 4.1.72.Final (#1831) (#1890) Wed, 12 Jan 2022 08:29:25 -0800 Signed-off-by: Sarat Vemulapalli &lt;vemulapallisarat@gmail.com&gt; Upgrading bouncycastle to 1.70 (#1832) (#1889) Tue, 11 Jan 2022 17:20:29 -0800 Signed-off-by: Sarat Vemulapalli &lt;vemulapallisarat@gmail.com&gt; RestIntegTestTask fails because of missed log4j-core dependency (#1815) (#1819) Tue, 28 Dec 2021 17:47:13 -0500 Signed-off-by: Andriy Redko &lt;andriy.redko@aiven.io&gt; Update to log4j 2.17.1 (#1820) (#1823) Tue, 28 Dec 2021 17:46:53 -0500 Signed-off-by: Andriy Redko &lt;andriy.redko@aiven.io&gt; Prepare for next development iteration, 1.2.4. (#1792) Wed, 22 Dec 2021 15:11:11 -0800 Signed-off-by: dblock &lt;dblock@amazon.com&gt;
Project: M3 (Observability and Analysis / Observability)
File: etcd.md

title: "etcd" weight: 12 All components within the M3 stack (e.g. M3 Query, M3DB, M3 Aggregator) leverage `etcd` as its distributed key-value storage. See below for examples of how this `etcd` metadata is used: Update cluster configuration in realtime Manage placements for distributed / sharded tiers like M3DB and M3Aggregator Perform leader-election in M3Aggregator Define placements for nodes within a M3DB cluster Define which shards are tied to a given node within a M3DB cluster `M3DB` ships with support for running embedded `etcd` (called `seed nodes`), and while this is convenient for testing and development, we don't recommend running with this setup in production. Both `M3` and `etcd` are complex distributed systems, and trying to operate both within the same binary is challenging and dangerous for production workloads. Instead, we recommend running an external `etcd` cluster that is isolated from the `M3` stack so that performing operations like node adds, removes, and replaces are easier. While M3 relies on `etcd` to provide strong consistency, the operations we use it for are all low-throughput so you should be able to operate a very low maintenance `etcd` cluster. should be more than sufficient for most workloads. Most of our documentation demonstrates how to run `M3DB` with embedded etcd nodes. Once you're ready to switch to an external `etcd` cluster, all you need to do is modify the `M3DB` config to remove the `seedNodes` field entirely and then change the `endpoints` under `etcdClusters` to point to your external `etcd` nodes instead of the `M3DB` seed nodes. For example this portion of the config ```yaml config: service: env: default_env zone: embedded service: m3db cacheDir: /var/lib/m3kv etcdClusters: zone: embedded endpoints: http://m3db_seed1:2379 http://m3db_seed2:2379 http://m3db_seed3:2379 seedNodes: initialCluster: hostID: m3db_seed1 endpoint: http://m3db_seed1:2380 hostID: m3db_seed2 endpoint: http://m3db_seed2:2380 hostID: m3db_seed3 endpoint: http://m3db_seed3:2380 ``` would become ```yaml config: service: env: default_env zone: embedded service: m3db cacheDir: /var/lib/m3kv etcdClusters: zone: embedded endpoints: http://external_etcd1:2379 http://external_etcd2:2379 http://external_etcd3:2379 ``` Note: `M3DB` placements and namespaces are stored in `etcd` so if you want to switch to an external `etcd` cluster you'll need to recreate all your placements and namespaces. You can do this manually or use `etcdctl`'s functionality. `M3Coordinator` does not run embedded `etcd`, so configuring it to use an external `etcd` cluster is simple. Just replace the `endpoints` under `etcdClusters` in the YAML config to point to your external `etcd` nodes instead of the `M3DB` seed nodes. See the `M3DB` example above for a detailed before/after comparison of the YAML config. If you're running `M3DB seed nodes` with embedded `etcd` (which we do not recommend for production workloads) and need to perform a node add/replace/remove then follow our and pay special attention to follow the special instructions for `seed nodes`. Just follow the instructions in the
Project: Netdata (Observability and Analysis / Observability)
File: ipfs_datastore_usage.md

This alert is related to the InterPlanetary File System (IPFS) distributed file system. It calculates the percentage of used IPFS datastore space. When you receive this alert, it means that your IPFS storage repository space is highly utilized. High datastore usage means your IPFS storage is close to its capacity. This can affect the system's performance and stability. It is essential to keep an eye on IPFS storage usage to ensure smooth functioning and avoid running out of storage. Check IPFS datastore usage To check the current IPFS datastore storage utilization, use the `ipfs repo stat` command: ``` ipfs repo stat ``` Identify large files and folders within the datastore To find the largest files and folders within your IPFS datastore, use the following command: ``` ipfs pin ls --type=recursive | xargs -n1 -I {} echo -n "{} " && ipfs object stat {} | head -n1 | awk '{print $2}' ``` Clean up IPFS datastore You can clean up and remove files that are no longer needed from your datastore using `ipfs pin rm` and `ipfs repo gc` commands. Be cautious while removing data to avoid losing any essential files. For example: ``` ipfs pin rm <CID> ipfs repo gc ``` Consider increasing the size of your datastore If your datastore is continuously getting filled, you might need to increase its capacity to ensure smooth operation. This can be done by adjusting the `Datastore.StorageMax` configuration setting in the `config` file, which is typically located in the `.ipfs` folder. ``` ipfs config Datastore.StorageMax <new size> ``` Monitor datastore usage over time Regularly monitor your IPFS datastore usage using `ipfs repo stat` command to stay informed about its storage utilization and plan for any necessary adjustments.
Project: Checkmk (Observability and Analysis / Observability)
File: 16322.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-03-08T13:45:32+00:00 level | 1 class | fix component | multisite edition | cre If you opened the "Filter" option of a view that was visited via a link from the "Virtual host tree" snapin, all filters were empty.
Project: Vector (Observability and Analysis / Observability)
File: 2022-01-12-vector-unit-test-improvements.md

date: "2022-01-12" title: "Vector Config Unit Testing Improvements" description: "Support for unit testing transforms with multiple outputs" authors: ["001wwang"] pr_numbers: [] release: "0.20.0" hideonrelease_notes: false We've added support for unit testing transforms with multiple outputs as well as full support for testing task-style transforms (previously there may have been issues when using multiple inputs with task transforms). For example, you can now test `remap` transform's `dropped` output like so, ```toml [transforms.foo] type = "remap" inputs = [] droponabort = true reroute_dropped = true source = "abort" [[tests]] name = "remapdroppedoutput" nooutputsfrom = [ "foo" ] [[tests.inputs]] insert_at = "foo" type = "log" [tests.inputs.log_fields] message = "I will be dropped" [[tests.outputs]] extract_from = "foo.dropped" [[tests.outputs.conditions]] type = "vrl" source = 'assert_eq!(.message, "I will be dropped", "incorrect message")' ``` Under-the-hood, we've reworked the unit testing implementation to more closely align with how a configuration actually runs, making it easier to support testing new features. However, as a result, some unit testing debug UX has also changed: previously, on a test condition error, debug output included `input` event information representing the event(s) prior to being transformed. `input` event information is no longer available. The original `input` event(s) for a test can be determined from your configuration.
Project: Netdata (Observability and Analysis / Observability)
File: boinc_active_tasks.md

This alert monitors the BOINC (Berkeley Open Infrastructure for Network Computing) client's average number of active tasks over the last 10 minutes. If you receive this alert, it means that there might be an issue with your BOINC tasks or client. Check the BOINC client logs Locate the BOINC client log file, usually in `/var/lib/boinc-client/`. Inspect the log file for any issues or error messages related to task execution, connection, or client behavior. Check the status of the BOINC client To check the status, run the following command: ``` sudo /etc/init.d/boinc-client status ``` If the client is not running, start it using: ``` sudo /etc/init.d/boinc-client start ``` Restart the BOINC client Restart the BOINC client, in most of the Linux distros: ``` sudo /etc/init.d/boinc-client restart ``` Ensure your system has adequate resources Monitoring and managing your computer resources (CPU, memory, disk space) can help ensure smooth operation of the BOINC client and its tasks. If your system is low on resources, consider freeing up space or upgrading your hardware. Update the BOINC client Make sure your BOINC client is up-to-date by checking the official BOINC website (https://boinc.berkeley.edu/download.php) for the latest version.
Project: Falcon (Observability and Analysis / Observability)
File: LICENSE.md

The MIT License (MIT) Copyright (c) [year] [fullname] 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: Headlamp (Observability and Analysis / Observability)
File: linux-installation.md

title: Linux Installation linktitle: Linux weight: 15 We ship Headlamp the Linux desktop in several formats: , , . gives an isolated and bundled way of running Headlamp, with decoupled runtime updates (besides other ). Make sure you , then install Headlamp with the following command: ```bash flatpak install io.kinvolk.Headlamp ``` For running it, just launch it as usually in your Linux desktop, or run: ```bash flatpak run io.kinvolk.Headlamp ``` To upgrading Headlamp when it's installed via Flatpak, run: ```bash flatpak update io.kinvolk.Headlamp ``` Headlamp can be used as an by downloading and running it directly. To download, choose the AppImage file from the . You can then run it with the following command (examplified for the AMD64, 0.16.0 version): ```bash ./Headlamp-0.16.0-linux-x64.AppImage ``` To run Headlamp from one of the tarballs, after downloading the tarball for the , you have to extract the contents from it and run the `headlamp` binary in the resulting folder (examplified below for the AMD64, 0.16.0 version): ```bash tar xvzf ./Headlamp-0.16.0-linux-x64.tar.gz cd Headlamp-0.16.0-linux-x64 ./headlamp ```
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_pubrel_sent_reason_unsuccessful.md

This alert is related to VerneMQ, a high-performance MQTT broker. It monitors the number of unsuccessful v5 `PUBREL` packets sent in the last minute. If you receive this alert, it means that there was an issue with sending `PUBREL` packets in your VerneMQ instance. `PUBREL` is a type of MQTT control packet that indicates the release of an application message from the server to the client. It is the third message in the QoS 2 (Quality of Service level 2) protocol exchange, where QoS 2 ensures that a message is delivered exactly once. An unsuccessful v5 `PUBREL` packet means that there was an error during the packet processing, and the message wasn't delivered to the client as expected. Check the VerneMQ logs: VerneMQ logs can give you valuable information about possible errors that might have occurred during the processing of `PUBREL` packets. Look for any error messages or traces related to the `PUBREL` packets in the logs. ``` sudo journalctl -u vernemq -f ``` Alternatively, if you're using a custom log location: ``` tail -f /path/to/custom/log ``` Check the MQTT client-side logs: Check the logs of the MQTT client that might have caused the unsuccessful `PUBREL` packets. Look for any connection issues, error messages, or traces related to the MQTT protocol exchanges. Ensure proper configuration for VerneMQ: Verify that the VerneMQ configuration settings related to QoS 2 protocol timeouts and retries are correctly set. Check the VerneMQ for guidance on the proper configuration. ``` cat /etc/vernemq/vernemq.conf ``` Monitor VerneMQ metrics: Use Netdata to monitor VerneMQ metrics to analyze the MQTT server's performance and resource usage. This can help you identify possible issues with the server. Address network or service issues: If the above steps don't resolve the alert, look for possible network or service-related issues that might be causing the unsuccessful `PUBREL` packets. This could require additional investigation based on your specific infrastructure and environment.
Project: Grafana Mimir (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]`. updated with experimental features.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: litmusctl-probe.md

| title | authors | creation-date | last-updated | |-|||--| | Litmusctl Probe CRUD commmands | | 2024-01-04 | 2024-01-04| The Litmusctl probe commands can help developers create/list/delete the probes through the command line ( which can help them while theyre automating), as similar to chaos-center, a developer can save probes by going to the `Resilience Probe` tab. Create, Describe, Delete, Update commands for Probe in Litmusctl Make `save chaos-experiment` command to list and use the Probes | Command | Use Case | | : | : | | `save chaos-probe` | The command allows to create a new probe,<br>specifying details such as type, name, timeout, <br>interval, retry, and polling interval. | | `delete chaos-probe` | The command allows developers to delete a probe<br> by providing its name. | | `list chaos-probe` | It displays a list of existing probes <br> including their names, IDs, types, and references. | | `describe chaos-probe` | To view detailed information about a specific probe,<br> providing its ID.| The proposal suggests leveraging chaos-center's Probe GraphQL APIs to implement Litmusctl probe commands. Detailed information about probe properties, such as timeout, interval, retry, polling interval, URL, and method, will be captured during creation and displayed during listing and describing. A promptUI can be good choice to take user inputs for defining the probe In case of Probes which requires too many inputs, user can just pass the yaml file having the probe configuration
Project: HertzBeat (Observability and Analysis / Observability)
File: extend-jmx.md

id: extend-jmx title: JMX Protocol Custom Monitoring sidebar_label: JMX Protocol Custom Monitoring From , you are familiar with how to customize types, Metrics, protocols, etc. Here we will introduce in detail how to use JMX to customize Metric monitoring. JMX protocol custom monitoring allows us to easily monitor Metrics we want by config JMX Mbeans Object. Peer Server Enable Jmx Service->HertzBeat Connect Peer Server Jmx->Query Jmx Mbean Object Data->Metric data extraction It can be seen from the process that we define a monitoring type of JMX protocol. We need to configure JMX request parameters, configure which Metrics to obtain, and configure Mbeans Object. By configuring the monitoring template YML metrics `field`, `aliasFields`, `objectName` of the `jmx` protocol to map and parse the `Mbean` object information exposed by the peer system. HertzBeat Dashboard -> Monitoring Templates -> New Template -> Config Monitoring Template Yml -> Save and Apply -> Add A Monitoring with The New Monitoring Type Configuration usages of the monitoring templates yml are detailed below. We define all monitoring collection types (mysql,jvm,k8s) as yml monitoring templates, and users can import these templates to support corresponding types of monitoring. Monitoring template is used to define the name of monitoring type(international), request parameter mapping, index information, collection protocol configuration information, etc. egDefine a custom monitoring type `app` named `example_jvm` which use the JVM protocol to collect data. ```yaml category: service app: example_jvm name: zh-CN: JVM en-US: CUSTOM JVM params: field: host name: zh-CN: Host en-US: Host type: host required: true field: port name: zh-CN: en-US: Port type: number range: '[0,65535]' required: true defaultValue: 9999 field: url name: zh-CN: JMX URL en-US: JMX URL type: text required: false hide: true placeholder: 'service:jmx:rmi:///jndi/rmi://host:port/jmxrmi' field: username name: zh-CN: en-US: Username type: text limit: 20 required: false hide: true field: password name: zh-CN: en-US: Password type: password required: false hide: true metrics: name: basic priority: 0 fields: field: VmName type: 1 field: VmVendor type: 1 field: VmVersion type: 1 field: Uptime type: 0 unit: ms protocol: jmx jmx: host: ^^host^^ port: ^^port^^ username: ^^username^^ password: ^^password^^ objectName: java.lang:type=Runtime url: ^^url^^ name: memory_pool priority: 1 fields: field: name type: 1 label: true field: committed type: 0 unit: MB field: init type: 0 unit: MB field: max type: 0 unit: MB field: used type: 0 unit: MB units: committed=B->MB init=B->MB max=B->MB used=B->MB aliasFields: Name Usage->committed Usage->init Usage->max Usage->used calculates: name=Name committed=Usage->committed init=Usage->init max=Usage->max used=Usage->used protocol: jmx jmx: host: ^^host^^ port: ^^port^^ username: ^^username^^ password: ^^password^^ objectName: java.lang:type=MemoryPool,name=* url: ^^url^^ ```
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: dns.md

title: Gadget dns The dns gadget traces DNS requests. ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: dns namespace: gadget spec: node: minikube gadget: dns filter: namespace: kube-system podname: etcd-minikube runMode: Manual outputMode: Stream ``` Start dns ```bash $ kubectl annotate -n gadget trace/dns \ gadget.kinvolk.io/operation=start ``` Stop dns and store results ```bash $ kubectl annotate -n gadget trace/dns \ gadget.kinvolk.io/operation=stop ``` Stream
Project: Checkmk (Observability and Analysis / Observability)
File: 16373.md

key | value | date | 2024-02-28T08:35:14+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes Before this Werk, the REST API was not able to access metrics named after IP addresses. This Werk fixes that and allows user to access metrics containing dots on the id
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_endpoints.Endpoints.md

title: "Class: Endpoints" linkTitle: "Endpoints" slug: "libk8sendpoints.Endpoints" .Endpoints `any` `Endpoints` new Endpoints(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeEndpoint\>('endpoint').constructor `Static` apiEndpoint: `Object` | Name | Type | | : | : | | `scale?` | { `get`: (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> ; `put`: (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> } | | `scale.get` | (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> | | `scale.put` | (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> | _ `Static` className: `string` makeKubeObject<KubeEndpoint\>('endpoint').className `get` spec(): `any` `any` _ `get` status(): `any` `any` _ `get` subsets(): `any` `any` getAddresses(): `string`[] `string`[] _ getAddressesText(): `string` `string` _ `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeEndpoint\>('endpoint').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeEndpoint\>('endpoint').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeEndpoint\>('endpoint').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeEndpoint\>('endpoint').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeEndpoint\>('endpoint').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeEndpoint\>('endpoint').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeEndpoint\>('endpoint').useList
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_hpa.KubeHPA.md

title: "Interface: KubeHPA" linkTitle: "KubeHPA" slug: "libk8shpa.KubeHPA" .KubeHPA `KubeHPA` `Optional` apiVersion: `string` . _ kind: `string` Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. In CamelCase. Cannot be updated. `see` . _ metadata: . _ spec: `HpaSpec` _ status: `HpaStatus`