cwielenb/CNCF-Dataset huggingface dataset:
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_kubeconfig.KubeconfigObject.md

title: "Interface: KubeconfigObject" linkTitle: "KubeconfigObject" slug: "libk8skubeconfig.KubeconfigObject" .KubeconfigObject KubeconfigObject is the object that is stored in indexDB as string format. It is a JSON encoded version of the kubeconfig file. It is used to store the kubeconfig for stateless clusters. This is basically a k8s client - go Kubeconfig object. KubeconfigObject holds the information needed to build connect to remote kubernetes clusters as a given user @see `see` storeStatelessClusterKubeconfig `see` getStatelessClusterKubeConfigs `see` findKubeconfigByClusterName apiVersion: `string` version of the kubeconfig file. _ clusters: { `cluster`: { `certificateAuthority?`: `string` ; `certificateAuthorityData?`: `string` ; `disableCompression?`: `boolean` ; `extensions?`: { `extension`: {} ; `name`: `string` }[] ; `insecureSkipTLSVerify?`: `boolean` ; `proxyURL?`: `string` ; `server`: `string` ; `tlsServerName?`: `string` } ; `name`: `string` }[] Clusters is a map of referencable names to cluster configs. `see` _ contexts: { `context`: { `cluster`: `string` ; `extensions?`: { `extension`: {} ; `name`: `string` }[] ; `namespace?`: `string` ; `user`: `string` } ; `name`: `string` }[] Contexts is a map of referencable names to context configs. `see` _ current-context: `string` CurrentContext is the name of the context that you would like to use by default _ `Optional` extensions: { `extension`: {} ; `name`: `string` }[] Extensions holds additional information. This is useful for extenders so that reads and writes don't clobber unknown fields `see` _ kind: `string` kind is the type of the kubeconfig file. It is always 'Config'. _ `Optional` preferences: `Object` Preferences holds general information to be use for cli interactions `see` | Name | Type | Description | | : | : | : | | `colors?` | `boolean` | colors specifies whether output should use colors. | | `extensions?` | { `extension`: {} ; `name`: `string` }[] | extensions holds additional information. This is useful for extenders so that reads and writes don't clobber unknown fields on the Preferences object. | _ users: { `name`: `string` ; `user`: { `authProvider?`: { `config`: { `[key: string]`: `string`; } ; `name`: `string` } ; `clientCertificate?`: `string` ; `clientCertificateData?`: `string` ; `clientKey?`: `string` ; `clientKeyData?`: `string` ; `exec?`: { `args?`: `string`[] ; `command`: `string` ; `env?`: { `[key: string]`: `string`; } } ; `extensions?`: { `extension`: {} ; `name`: `string` }[] ; `impersonate?`: `string` ; `impersonateGroups?`: `string`[] ; `impersonateUserExtra?`: { `[key: string]`: `string`[]; } ; `password?`: `string` ; `token?`: `string` ; `tokenFile?`: `string` ; `username?`: `string` } }[] AuthInfos is a map of referencable names to user configs. `see`
Project: Checkmk (Observability and Analysis / Observability)
File: 16036.md

key | value | date | 2023-12-19T13:41:26+00:00 version | 2.3.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes When calling the `host_config/collections/all` endpoint with IPMI credentials activated and set to `No explicit credentials` the endpoint returns a status 500 (Internal Server Error). Now the information is correctly returned.
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: install_relay_proxy.md

sidebar_position: 20 description: Relay proxy is the component that will evaluate the flags, this page explain how to install it. If you want to access your feature flag using an API instead of the SDK. If you are not using GOlang to build your application. If you want to reduce the number of accesses to your configuration flag by centralizing them. <!-- - If you are using any SDKs that connect to the Relay Proxy. --> ```shell brew install go-feature-flag-relay-proxy ``` ```shell scoop bucket add org https://github.com/thomaspoignant/scoop.git scoop install go-feature-flag-relay-proxy ``` ```shell docker pull thomaspoignant/go-feature-flag-relay-proxy:latest ``` :::info More info in the . :::
Project: Grafana (Observability and Analysis / Observability)
File: publish-your-plugin.md

labels: products: enterprise oss title: Package your plugin Once you're happy with your plugin, it's time to package it, and submit to the plugin repository. For users to be able to use the plugin without building it themselves, you need to make a production build of the plugin, and commit to a release branch in your repository. To submit a plugin to the plugin repository, you need to create a release of your plugin. While we recommend following the branching strategy outlined below, you're free to use one that makes more sense to you. Let's create version 0.1.0 of our plugin. Create a branch called `release-0.1.x`. ``` git checkout -b release-0.1.x ``` Do a production build. ``` yarn build ``` Add the `dist` directory. ``` git add -f dist ``` Create the release commit. ``` git commit -m "Release v0.1.0" ``` Create a release tag. ``` git tag -a v0.1.0 -m "Create release tag v0.1.0" ``` Push to GitHub. `follow-tags` tells Git to push the release tag along with our release branch. ``` git push --set-upstream origin release-0.1.x --follow-tags ``` For a plugin to be published on , it needs to be added to the . Fork the Add your plugin to the `repo.json` file in the project root directory: ```json { "id": "<plugin id>", "type": "<plugin type>", "url": "https://github.com/<username>/my-plugin", "versions": [ { "version": "<version>", "commit": "<git sha>", "url": "https://github.com/<username>/my-plugin" } ] } ``` . Once your plugin has been accepted, it'll be published on , available for anyone to ! We're auditing every plugin that's added to make sure it's ready to be published. This means that it might take some time before your plugin is accepted. We're working on adding more automated tests to improve this process.
Project: Netdata (Observability and Analysis / Observability)
File: vernemq_mqtt_puback_sent_reason_unsuccessful.md

This alert is related to VerneMQ, an MQTT message broker. If you receive this alert, it means that an increasing number of unsuccessful v5 PUBACK packets have been sent in the last minute. In the MQTT protocol, when a client sends a Publish message with a Quality of Service (QoS) level 1, the message broker sends a PUBACK packet to acknowledge receipt of the message. However, MQTT v5 has added a reason code field in the PUBACK packet, allowing brokers to report any issues or errors that occurred during message delivery. An "unsuccessful v5 PUBACK" refers to a PUBACK packet that reports a delivery problem or issue. Check VerneMQ logs for possible errors or warnings: VerneMQ logs can provide valuable insights into the broker's runtime behavior, including connection issues or problems with authentication/authorization. Look for errors or warnings in the logs that could indicate the cause of the unsuccessful PUBACK packets. ``` sudo journalctl -u vernemq ``` Verify client connections: Connection issues can be a possible cause of unsuccessful PUBACK packets. Use the `vmq-admin session show` command to view the client connections, and check for any abnormal behavior (e.g., frequent disconnects and reconnects). ``` sudo vmq-admin session show ``` Check MQTT client logs: Review the logs from the devices that connect to your VerneMQ broker instance to verify if they encounter any issues or errors when sending messages. Monitor the broker's resources usage: High system load or insufficient resources may affect VerneMQ's performance and prevent it from processing PUBACK packets as expected. Use monitoring tools like `top` and `iotop` to observe CPU and I/O usage, and assess whether the broker has enough resources to handle the MQTT traffic. Update VerneMQ configuration: Double-check your VerneMQ settings for any misconfiguration related to QoS, message storage, or security policies that could prevent PUBACK packets from being sent or processed successfully.
Project: Pixie (Observability and Analysis / Observability)
File: ISSUE_TEMPLATE.md

Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: Go to '...' Click on '....' Scroll down to '....' See error Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Logs Please attach the logs by running the following command: ``` ./px collect-logs ``` App information (please complete the following information): Pixie version K8s cluster version Additional context Add any other context about the problem here.
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-1.2.3.md

Increment version to 1.2.3. (#1758) Fri Dec 17 14:34:50 2021 +0000 Update to log4j 2.17.0. (#1771) Sat Dec 18 14:33:36 2021 -0500 Fix repository-azure plugin hanging, regression introduced in 1.2.0. (#1734) Thu Dec 16 15:10:14 2021 -0500
Project: Promscale (Observability and Analysis / Observability)
File: PromscaleDBHighErrorRate.md

Promscale is experiencing high errors while performing database requests Ingestion and querying operations will have frequent failures. This may also lead to loss of data while ingesting traces. Make sure that Prometheus is monitoring Promscale's `/metric` endpoint Make sure that Promscale Dashboard is installed on Grafana Open Grafana Open Promscale dashboard Go to Query section See the Errors (HTTP) graph. If you see high error rates, see for mitigation Check Postgres logs to see if there are any errors. If found, see and for mitigation Go to grafana dashboard about Promscale and check the Network latency panel in Database row. If latency is high, go to Check the logs and fix errors (if any) Make sure that database is ready for normal operations Add more disk space if required Same as Ingestion data is invalid or corrupt in . Make sure your queries do not contain any corrupt information and is parsable by SQL
Project: Pixie (Observability and Analysis / Observability)
File: story.md

name: Story about: Task for implementing a feature/user story Describe the feature/change A clear description of the feature and changes, from the perspective of the end user. If this is a feature request, please file this issue as a "Feature Request" instead. Feature Request If linked to a feature request, link to the Github issue here. Subtasks The list of concrete tasks which must be done to complete this story. These may be low-level and engineering-oriented. [x] Here is an example of a completed task. [ ] Here is an example of an uncompleted task.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: kafka.md

title: Kafka weight: 200 generated_file: true For details, see . For an example deployment, see . ```yaml spec: kafka: brokers: kafka-headless.kafka.svc.cluster.local:29092 default_topic: topic sasloverssl: false format: type: json buffer: tags: topic timekey: 1m timekey_wait: 30s timekeyuseutc: true ``` Send your logs to Kafka How long the producer waits for acks. The unit is seconds Default: nil => Uses default of ruby-kafka library The list of all seed brokers, with their host and port information. Client ID Default: "kafka" The codec the producer uses to compress messages . The available options are gzip and snappy. Default: nil The name of default message key . Default: nil The name of default partition key . Default: nil The name of default topic . Default: nil Discard the record where Kafka DeliveryFailed occurred Default: false Exclude Partition key Default: false Exclude Topic key Default: false Get Kafka Client log Default: false Headers Default: {} Headers from Record Default: {} Idempotent Default: false Maximum value of total message size to be included in one batch transmission. . Default: 4096 Maximum number of messages to include in one batch transmission. . Default: nil Number of times to retry sending of messages to a leader Default: 1 Message Key Default: "message_key" Partition Default: "partition" Partition Key Default: "partition_key" Password when using PLAIN/SCRAM SASL authentication The number of acks required per request . Default: -1 CA certificate System's CA cert store Default: false Client certificate Client certificate chain Client certificate key Verify certificate hostname SASL over SSL Default: true If set, use SCRAM authentication with specified mechanism. When unset, default to PLAIN authentication The threshold for chunk flush performance check. Parameter type is float, not time, default: 20.0 (seconds) If chunk flush takes longer time than this threshold, Fluentd logs a warning message and increases the `fluentdoutputstatusslowflush_count` metric. Topic Key Default: "topic" Use default for unknown topics Default: false Username when using PLAIN/SCRAM SASL authentication
Project: Sentry (Observability and Analysis / Observability)
File: PULL_REQUEST_TEMPLATE.md

<!-- Describe your PR here. --> <!-- Sentry employees and contractors can delete or ignore the following. --> Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.
Project: Checkmk (Observability and Analysis / Observability)
File: 16325.md

key | value | date | 2024-01-31T13:08:07+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | no This problem affected users who wanted to discover the 'summary' mode of PSU service: it was not possible to configure the appropriate discovery rule. This werk fixes this behaviour. A rediscovery is required for the change to take effect.
Project: Graylog (Observability and Analysis / Observability)
File: PageNavigation.md

```js import PageNavigation from './PageNavigation'; <PageNavigation items={[ { title: 'Subarea 1', path: '/' }, { title: 'Subarea 2', path: '/path2' }, { title: 'Subarea 3', path: '/path3' }, ]} /> ```
Project: Netdata (Observability and Analysis / Observability)
File: memcached_cache_memory_usage.md

This alert indicates the percentage of used cached memory in your Memcached instance. High cache memory utilization can lead to evictions and performance degradation. The warning state is triggered when the cache memory utilization is between 70-80%, and the critical state is triggered when it's between 80-90%. Cache memory utilization refers to the percentage of memory used by Memcached for caching data. A high cache memory utilization indicates that your Memcached instance is close to its maximum capacity, and it may start evicting data to accommodate new entries, which can negatively impact performance. Monitor cache usage and evictions: Use the following command to display the current cache usage and evictions metrics: ``` echo "stats" | nc localhost 11211 ``` Look for the `bytes` and `evictions` metrics in the output. High evictions indicate that your cache size is insufficient for the current workload, and you may need to increase it. Increase cache size: To increase the cache size, edit the Memcached configuration file (usually `/etc/memcached.conf`) and update the value of the `-m` option. For example, to set the cache size to 2048 megabytes, update the configuration as follows: ``` -m 2048 ``` Save the file and restart the Memcached service for the changes to take effect. ``` sudo systemctl restart memcached ``` Optimize your caching strategy: Review your caching strategy to ensure that you are only caching necessary data and using appropriate expiration times. Making updates that reduce the amount of cached data can help prevent high cache memory usage. Consider cache sharding or partitioning: If increasing the cache size or optimizing your caching strategy doesn't resolve the issue, you may need to consider cache sharding or partitioning. This approach involves using multiple Memcached instances, dividing the data across them, which can help distribute the load and reduce cache memory usage.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-9-0-8.md

aliases: [] hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 9.0.8 <!-- Auto generated by update changelog github action --> Alerting: Hide "no rules" message when we are fetching from data sources. , Rendering: Add support for renderer token (#54425). , Reports: Title is showing under panels. (Enterprise) Alerting: AlertingProxy to elevate permissions for request forwarded to data proxy when RBAC enabled. ,
Project: Checkmk (Observability and Analysis / Observability)
File: 16234.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-02-20T18:39:35+00:00 level | 1 class | security component | checks edition | cre In the mk_oracle plugin <tt>sqlplus</tt> used to be called with the connection string as an argument. This connection string could contain credentials necessary to authenticate against the database. These arguments could be extracted by other users (e.g. with use of <tt>ps</tt>). This vulnerability was reported to us, we are not aware of any exploitations. <b>Affected Versions:</b> 2.2.0 2.1.0 2.0.0 (probably older versions as well) <b>Vulnerability Management:</b> We have rated the issue with a CVSS Score of 3.8 (Low) with the following CVSS vector: <tt>CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N</tt>. We assigned CVE-2024-1742 to this vulnerability. <b>Changes:</b> With this Werk the connection string is now piped via stdin to <tt>sqlplus</tt>.
Project: Netdata (Observability and Analysis / Observability)
File: mdstat_disks.md

This alert presents the number of devices in the down state for the respective RAID array raising it. If you receive this alert, then the array is degraded and some array devices are missing. When a RAID array experiences the failure of one or more disks, it can enter degraded mode, a fallback mode that generally allows the continued usage of the array, but either loses the performance boosts of the RAID technique (such as a RAID-1 mirror across two disks when one of them fails; performance will fall back to that of a normal, single drive) or experiences severe performance penalties due to the necessity to reconstruct the damaged data from error correction data. Examine for faulty or offline devices Having a degraded array means that one or more devices are faulty or missing. To fix this issue, check for faulty devices by running: ``` mdadm --detail <RAIDDEVICE> ``` Replace "RAIDDEVICE" with the name of your RAID device. To recover the array, replace the faulty devices or bring back any offline devices.
Project: SkyWalking (Observability and Analysis / Observability)
File: manual-sdk.md

Our incredible community has contributed to the manual instrument SDK. . Rust SDK follows the SkyWalking format. . C++ SDK follows the SkyWalking format. Below is the archived list. . Since Jun 14, 2023. Envoy has its internal tracer implementation for SkyWalking. Read and for more details.
Project: Checkmk (Observability and Analysis / Observability)
File: 16374.md

key | value | date | 2024-01-11T22:47:00+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes This only affects users that monitor the memory usage of Windows hosts using both averaging and predictive levels. The prediction is now based on the unaveraged original value, potentially leading to a slightly larger standard deviation. The resulting levels are still applied to the averaged value, if averaging is configured.
Project: Vector (Observability and Analysis / Observability)
File: 2020-08-04-3325-remap-v2.md

This RFC covers incremental changes to the `remap` mapping syntax. Previous RFC for context: https://github.com/vectordotdev/vector/blob/master/rfcs/2020-07-21-2744-remap-syntax.md We have a `remap` transform that allows basic mutation operations: ```coffee .foo = .bar del(.bar) .baz = "something static" ``` However, large mappings almost always require conditional logic and implementing this with the swimlanes transform introduces complexity to a config. Ideally, we want to be able to express conditional mappings directly within the `remap` transform using an `if` statement. Within a `remap` mapping it's possible to perform mappings conditionally using an `if` statement: ```coffee if .bar != null { .foo = .bar del(.bar) } .baz = "something static" ``` When the `if` logical argument resolves to `true` the mapping statements within the block are executed, otherwise they are not. An else block can be added, where the contents are executed when the argument resolves to `false`: ```coffee if .bar != null { .foo = .bar del(.bar) } else { .foo = "bar doesn't exist" } .baz = "something static" ``` Sometimes it might be more convenient to express `if` statements as an expression for assigning to a value: ```coffee .content = if .type == "foo" { .foo.content } else { .bar.body } ``` In which case each block must contain a query. It would be possible to expand this to allow assignments within the block but we need to think through and experiment with the issues of mutating context and how we'd document the behavior we choose. Implement root-level `if` statements, this is the lowest hanging fruit in terms of implementation and documentation and unblocks the majority of use cases. Implement value `if` statements which can exist on the right-hand side of an assignment. Consider allowing assignments within right-hand side `if` statement blocks. This could potentially become an RFC of its own.
Project: Tracetest (Observability and Analysis / Observability)
File: tracetest_delete.md

Delete resources Delete resources from your Tracetest server ``` tracetest delete analyzer|config|datastore|demo|env|organization|pollingprofile|test|testrunner|testsuite|variableset [flags] ``` ``` -h, --help help for delete --id string id of the resource to delete ``` ``` -c, --config string config file will be used by the CLI (default "config.yml") -o, --output string output format [pretty|json|yaml] -s, --server-url string server url -v, --verbose display debug information ``` - CLI to configure, install and execute tests on a Tracetest server
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: logz.md

title: LogZ weight: 200 generated_file: true For details, see . ```yaml spec: logz: endpoint: url: https://listener.logz.io port: 8071 token: valueFrom: secretKeyRef: name: logz-token key: token outputincludetags: true outputincludetime: true buffer: type: file flush_mode: interval flushthreadcount: 4 flush_interval: 5s chunklimitsize: 16m queuelimitlength: 4096 ``` LogZ Send your logs to LogZ.io Limit to the size of the Logz.io upload bulk. Defaults to 1000000 bytes leaving about 24kB for overhead. Limit to the size of the Logz.io warning message when a record exceeds bulk_limit to prevent a recursion when Fluent warnings are sent to the Logz.io output. Define LogZ endpoint URL Should the plugin ship the logs in gzip compression. Default is false. Timeout in seconds that the http persistent connection will stay open without traffic. Should the appender add the fluentd tag to the document, called "fluentd_tag" Should the appender add a timestamp to your logs on their process time (recommended). How many times to resend failed bulks. How long to sleep initially between retries, exponential step-off. The threshold for chunk flush performance check. Parameter type is float, not time, default: 20.0 (seconds) If chunk flush takes longer time than this threshold, Fluentd logs a warning message and increases the `fluentdoutputstatusslowflush_count` metric. Endpoint defines connection details for LogZ.io. Port over which to connect to LogZ URL. Default: 8071 LogZ API Token. LogZ URL. Default: https://listener.logz.io