cwielenb/CNCF-Dataset huggingface dataset:
Project: Grafana (Observability and Analysis / Observability)
File: query-management.md

keywords: explore loki logs labels: products: cloud enterprise oss title: Query management weight: 10 To help with debugging queries, Explore allows you to investigate query requests and responses, as well as query statistics, via the Query inspector. This functionality is similar to the panel inspector tasks and . {{< figure src="/static/img/docs/v71/queryinspectorexplore.png" class="docs-image--no-shadow" max-width= "550px" caption="Screenshot of the query inspector button in Explore" >}} Query history is a list of queries that you used in Explore. The history is stored in the Grafana database and it is not shared with other users. The retention period for queries in history is two weeks. Queries older than two weeks are automatically deleted. To open and interact with your history, click the Query history button in Explore. {{% admonition type="note" %}} Starred queries are not subject to the two weeks retention period and they are not deleted. {{% /admonition %}} Query history lets you view the history of your querying. For each individual query, you can: Run a query. Create and/or edit a comment. Copy a query to the clipboard. Copy a shortened link with the query to the clipboard. Star a query. All queries that have been starred in the Query history tab are displayed in the Starred tab. This allows you to access your favorite queries faster and to reuse these queries without typing them from scratch. By default, query history shows you the most recent queries. You can sort your history by date or by data source name in ascending or descending order. Click the Sort queries by field. Select one of the following options: Newest first Oldest first Filter query history in Query history and Starred tab by data source name: Click the Filter queries for specific data source(s) field. Select the data source for which you would like to filter your history. You can select multiple data sources. Note: Queries ran using the Mixed data source will appear only when filtering for Mixed and not when filtering by their individual data sources. In Query history tab it is also possible to filter queries by date using the slider: Use vertical slider to filter queries by date. By dragging bottom handle, adjust start date. By dragging top handle, adjust end date. You can search in your history across queries and your comments. Search is possible for queries in the Query history tab and Starred tab. Click the Search queries field. Type the term you are searching for into search field. You can customize the query history in the Settings tab. Options are described in the table below. | Setting | Default value | | -- | -- | | Change the default active tab | Query history tab | Note: Query history settings are global, and applied to both panels in split mode.
Project: Checkmk (Observability and Analysis / Observability)
File: 16629.md

key | value | date | 2024-03-15T09:24:42+00:00 version | 2.4.0b1 class | fix edition | cre component | multisite level | 1 compatible | yes A virtual host tree (Setup > General > Global settings > User interface > Virtual host trees) can be configured with more than three host tag tree levels. Yet, the corresponding views that are linked to from the sidebar element "Virtual host trees" were not able to display more than three rows in the "Host tags" filter and thus only filtered for the first three. This is fixed. A virtual host tree link as described above now leads to a properly filtered view with all the given host tag filters shown in the filter popup.
Project: Netdata (Observability and Analysis / Observability)
File: riakkv_kv_put_slow.md

The `riakkvkvput_slow` alert is triggered when the average processing time for PUT requests in Riak KV database increases significantly in comparison to the last hour's average, suggesting that the server is overloaded. An overloaded server means that the server is unable to handle the incoming requests efficiently, leading to increased processing times and degraded performance. Sometimes, it might result in request timeouts or even crashes. To troubleshoot this alert, follow the below steps: Check current Riak KV performance Use `riak-admin` tool's `status` command to check the current performance of the Riak KV node: ``` riak-admin status ``` Look for the following key performance indicators (KPIs) for PUT requests: riakkv.putfsm.time.95 (95th percentile processing time for PUT requests) riakkv.putfsm.time.99 (99th percentile processing time for PUT requests) riakkv.putfsm.time.100 (Maximum processing time for PUT requests) If any of these values are significantly higher than their historical values, it may indicate an issue with the node's performance. Identify high-load operations Examine the application logs or Riak KV logs for recent activity such as high volume of PUT requests, bulk updates or deletions, or other intensive database operations that could potentially cause the slowdown. Investigate other system performance indicators Check the server's CPU, memory, and disk I/O usage to identify any resource constraints that could be affecting the performance of the Riak KV node. Review Riak KV configuration Analyze the Riak KV configuration settings to ensure that they are optimized for your specific use case. Improperly configured settings can lead to performance issues. Consider scaling the Riak KV cluster If the current Riak KV cluster is not able to handle the increasing workload, consider adding new nodes to the cluster to distribute the load and improve performance.
Project: chaoskube (Observability and Analysis / Chaos Engineering)
File: CHANGELOG.md

Updates: Update builds to use Go `v1.22` @linki Update builds to use Go `v1.21` @linki Update builds to use Go `v1.20` @linki Update builds to use Go `v1.19` @linki Features: Add maximum runtime flag @IoannisMatzaris Add a Helm chart to deploy chaoskube @ghouscht Updates: Add kubeinvaders as related project in the docs @lucky-sideburn Add namespace metadata to deleted pods metric @linki Add missing max-kill flag to the docs @KeisukeYamashita Update several dependencies, such as Kubernetes to v0.20.x. Features: Allow to filter by OwnerReference's Kind @qlikcoe Updates: Added test & build to Makefile @el10savio Updates: Fix a bug that caused chaoskube to always kill the same pod of a replicated group of pods @HaveFun83 @linki Updates: Use `context.Context` to cancel in-flight requests @linki Update client-go to `v0.18.0` @linki Update builds to use Go `v1.14` @linki Updates: Add slack webhook flag to documentation @Clivern Update client-go to v0.17.0 @linki Add Makefile and prettify test output @linki Update klog to v1.0.0 @linki Update Helm's Quickstart Guide link in README @SergioSV96 Features: Support for sending Slack notifications @GaruGaru Features: Add support for terminating multiple pods per iteration @pims Updates: Remove incomplete snippet from the readme and point to examples @jan-warchol Don't attempt to terminate `Terminating` pods @pims Update builds to use Go `v1.13` @linki Update Docker images to use alpine `3.10` @linki Updates: Avoid writing logs to the container filesystem @linki Features: Add `--log-caller` flag that adds file name and line to the log output @linki Updates: Update client-go to `v12` for Kubernetes `v1.14` @linki Update builds to use Go `v1.12` and Go Modules @linki Features: Add include and exclude regular expression filters for pod names @dansimone Features: Adding JSON as additional log format @syedimam0012 Updates: Add logo for chaoskube @linki Add Dockerfile for `arm32v6` and `arm64v8` @toolboc Abstract termination strategy in order to add more means of killing pods @jakewins @linki Features: Add several useful Prometheus metrics @ruehowl @shaikatz Updates: Replace event related code with Kubernetes's `EventRecorder` @linki Document major difference to `kube-monkey` @prageethw Update dependencies to match Kubernetes v1.12 API @linki Update docker image to alpine v3.8 and go v1.11 @linki Features: Add option to define grace period given to pods @palmerabollo Implement event creation after terminating a pod @djboris9 Updates: Replace `glog` with a `noop` logger to allow for read-only filesystem @linki Features: Expose basic metrics via Prometheus @bakins Add a health check endpoint @bakins Add a flag to exclude Pods under a certain age @bakins Exclude Pods that are not in phase `Running` @linki Add a Dockerfile for building images for `ppc64le` @hchenxa Updates: Use versioned functions of `client-go` @linki Handle signals to enable more graceful shutdown @linki Run `chaoskube` as `nobody` by default @bavarianbidi Use to improve coverage results @linki
Project: Checkmk (Observability and Analysis / Observability)
File: 15722.md

key | value | compatible | yes version | 2.3.0b1 date | 2024-01-19T18:46:45+00:00 level | 1 class | fix component | omd edition | cre Starting with 2.2.0 (see #15062), we use a umask of 0077 to prevent files and directories owned by the site user from being world readable. However, when updating from the CRE to a non CRE edition, some files and directories were still set to be world readable during 'omd update'. This is now in line with the other files.
Project: Netdata (Observability and Analysis / Observability)
File: kubelet_token_requests.md

This alert is related to Kubernetes Kubelet token requests. It monitors the number of failed `Token()` requests to an alternate token source. If you receive this alert, it means that your system is experiencing an increased rate of token request failures. In Kubernetes, tokens are used for authentication purposes when making requests to the API server. The Kubelet uses tokens to authenticate itself when it needs to access cluster information or manage resources on the API server. Investigate the reason behind the failed token requests Check the Kubelet logs for any error messages or warnings related to the token requests. You can use the following command to view the logs: ``` journalctl -u kubelet ``` Look for any entries related to `Token()` request failures or authentication issues. Verify the alternate token source configuration Review the Kubelet configuration file, usually located at `/etc/kubernetes/kubelet/config.yaml`. Check the `authentication` and `authorization` sections to ensure all the required settings have been correctly configured. Make sure that the specified alternate token source is available and working correctly. Check the API server logs Inspect the logs of the API server to identify any issues that may prevent the Kubelet from successfully requesting tokens. Use the following command to view the logs: ``` kubectl logs -n kube-system kube-apiserver-<YOURNODENAME> ``` Look for any entries related to authentication, especially if they are connected to the alternate token source. Monitor kubelettokenrequests metric Keep an eye on the `kubelettokenrequests` metric using the Netdata dashboard or a monitoring system of your choice. If the number of failed requests continues to increase, this might indicate an underlying issue that requires further investigation.
Project: Netdata (Observability and Analysis / Observability)
File: postgres_table_cache_io_ratio.md

This alert monitors the PostgreSQL table cache hit ratio, which is the percentage of database read requests that can be served from the cache without requiring I/O operations. If you receive this alert, it means your PostgreSQL table cache hit ratio is too low, indicating performance issues with the database. The PostgreSQL table cache hit ratio is an important metric for analyzing the performance of a database. A high cache hit ratio means that most read requests are being served from the cache, reducing the need for disk I/O operations and improving overall database performance. On the other hand, a low cache hit ratio indicates that more I/O operations are required, which can lead to performance degradation. To address the low cache hit ratio issue, follow these steps: Analyze database performance: Analyze the database performance to identify potential bottlenecks and areas for optimization. You can use PostgreSQL performance monitoring tools such as `pgtop`, `pgstatstatements`, and `pgstatusertables` to gather information about query execution, table access patterns, and other performance metrics. Optimize queries: Review and optimize complex or long-running SQL queries that may be causing performance issues. Utilize PostgreSQL features like `EXPLAIN` and `EXPLAIN ANALYZE` to analyze query execution plans and identify optimization opportunities. Indexing and query optimization can reduce I/O requirements and improve cache hit ratios. Increase shared_buffers: If you have a dedicated database server with sufficient memory, you can consider increasing the `shared_buffers` in your PostgreSQL configuration. This increases the amount of memory available to the PostgreSQL cache and can help improve cache hit ratios. Before making changes to the configuration, ensure that you analyze the existing memory usage patterns and leave enough free memory for other system processes and caching demands. Monitor cache hit ratios: Keep monitoring cache hit ratios after making changes to your configuration or optimization efforts. Depending on the results, you may need to adjust further settings, indexes, or queries to optimize database performance.
Project: OpenTelemetry (Observability and Analysis / Observability)
File: gc-check-ins.md

As defined in the the GC will check in with maintainers of all long-term and short-term SIGs on a regular basis. During this check in, any project files or roadmap entries should be reviewed to verify that they are still accurate. if a SIG lead has any private concerns they wish to raise with the Governance Committee, this is an opportunity to do so. the health of the SIG will be reviewed, and what measures can be applied to help the SIG. The check in process is as follows: For each SIG a GC member is appointed as a GC liaison. The name of that person will be listed publicly. If a GC member was the sponsor for , they are by the GC liaison for this SIG. If a GC member is the maintainer themselves, they are by default the GC liaison for this SIG. The GC liaison is appointed for the duration of the project lifecycle, or until they do not get reelected into the GC. Outside of that regular duration, a GC liaison can resign by providing a named successor. The GC liaison is responsible to check in with the maintainers at least once per month. This can either happen via a (private, non recorded) meeting or through a text-based conversation initiated by the GC liaison. The GC liaison is responsible to bring the concerns of the SIG leads forward to the GC, and they are responsible for ensuring that all action items agreed upon during that check in are logged as issues on the project repository or community repository. The GC liaison will attend the regular project meetings at least once per quarter. If this is difficult to accomplish due to timezone constraints, the GC liaison can be freed from this obligation by the GC. This exception should only rarely be approved. The GC liaison and the maintainers are responsible to provide a quarterly health update, where they assess project health along three dimensions: Whether the SIG is making reasonable progress, and if published "On Schedule" relative to its own roadmap The "contributor experience": # of new contributors/triagers/maintainers, PR turnaround time, newbie-friendly issues, advancement opportunities, automation, etc The "maintainer experience": workload, burnout, collaboration, etc.
Project: Vector (Observability and Analysis / Observability)
File: 2020-03-11-tag-cardinality-limit-transform.md

date: "2020-04-16" title: "New Tag Cardinality Limit Transform" description: "Protect downstream metric storage systems from metric tag explosion" authors: ["binarylogic"] pr_numbers: [1959] release: "0.9.0" hideonrelease_notes: false badges: type: "new feature" domains: ["transforms"] transforms: ["tagcardinalitylimit"] High cardinality metric tags can severely disrupt downstream metrics storages. To protect against this we built a new . Getting started is easy. Simply add this component to your pipeline: ```toml title="vector.toml" [transforms.tag_protection] type = "tagcardinalitylimit" inputs = ["my-source-id"] limitexceededaction = "drop_tag" mode = "exact" value_limit = 500 ``` {{< success >}} The `limitexceededaction` described the behavior when the `value_limit` is reached. The `mode` enables you to switch between `exact` and `probabilistic` algorithms to trade performance for memory efficiency. The `value` limit allows you to select exactly how many unique tag values you're willing to accept. {{< /success >}} More to come! This feature is part of our [best-in-class operator UX][urls.milestone_39] initiative.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s.md

title: "Module: lib/k8s" linkTitle: "lib/k8s" slug: "lib_k8s" Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports _ Renames and re-exports CancellablePromise: `Promise`<() => `void`\> ResourceClasses: `Object` = `resourceClassesDict` getVersion(`clusterName?`): `Promise`<\> | Name | Type | Default value | | : | : | : | | `clusterName` | `string` | `''` | `Promise`<\> _ labelSelectorToQuery(`labelSelector`): `string` See , , , and . | Name | Type | | : | : | | `labelSelector` | | `string` _ matchExpressionSimplifier(`matchExpressions`): `string`[] \| ``""`` | Name | Type | | : | : | | `matchExpressions` | `undefined` \| { `key`: `string` ; `operator`: `string` ; `values`: `string`[] }[] | `string`[] \| ``""`` _ matchLabelsSimplifier(`matchLabels`, `isEqualSeperator?`): `string`[] \| ``""`` | Name | Type | Default value | | : | : | : | | `matchLabels` | `undefined` \| { `[key: string]`: `string`; } | `undefined` | | `isEqualSeperator` | `boolean` | `false` | `string`[] \| ``""`` _ useCluster(): ``null`` \| `string` ``null`` \| `string` _ useClustersConf(): `ConfigState`[``"allClusters"``] Hook for getting or fetching the clusters configuration. This gets the clusters from the redux store. The redux store is updated when the user changes the configuration. The configuration is stored in the local storage. When stateless clusters are present, it combines the stateless clusters with the clusters from the redux store. `ConfigState`[``"allClusters"``] the clusters configuration. _ useClustersVersion(`clusters`): readonly ; }, { ` \| ``null``; }] Hook to get the version of the clusters given by the parameter. | Name | Type | | : | : | | `clusters` | [] | readonly ; }, { ` \| ``null``; }] a map with cluster -> version-info, and a map with cluster -> error. _ useConnectApi(...`apiCalls`): `void` | Name | Type | | : | : | | `...apiCalls` | () => [] | `void`
Project: Vector (Observability and Analysis / Observability)
File: 2023-04-11-0-29-0-upgrade-guide.md

date: "2023-04-11" title: "0.29 Upgrade Guide" description: "An upgrade guide that addresses breaking changes in 0.29.0" authors: ["stephenwakely", "neuronull"] release: "0.29.0" hideonrelease_notes: false badges: type: breaking change Vector's 0.29.0 release includes breaking changes: Vector's 0.29.0 release includes deprecations: We cover them below to help you upgrade quickly: The `apikey` option has been hidden on the documentation for the `datadoglogs` and `datadog_metrics` sinks for a few releases now, with the documented name for that setting being `defaultapikey`. In `v0.28.0`, the `api_key` was communicated as deprecated and as part of the deprecation policy, is fully removed in this release. Any usages of `api_key` setting in these sinks will no longer work and they will need to be instead defined as `defaultapikey`. Following LogDNA's to Mezmo, the `logdna` sink has been renamed to `mezmo`. The old name `logdna` has been deprecated and will be removed in a future release. Please update your configurations accordingly. ```diff -type = "logdna" +type = "mezmo" ``` The `socket` source modes `tcp` and `unix` have had a `max_length` setting which is meant to be replaced by the `max_length` setting within the `framing` setting. The `max_length` setting will be removed from these modes in a future release. Please replace any explicit usages of `max_length` with a `framing` setting in your configurations.
Project: Netdata (Observability and Analysis / Observability)
File: windows_outbound_packets_errors.md

This alert monitors the number of `outbound errors` on the network interface of a Windows system over the last 10 minutes. If you receive this alert, it means that there are `5 or more errors` in outbound packets during that period. `Outbound errors` refer to problems that occur during the transmission of packets from the network interface of your system. These errors can be due to various reasons, such as faulty hardware, incorrect configuration, or network congestion. Identify the network interface(s) with high outbound errors Use the `netstat -e` command to display network statistics for each interface on your system: ``` netstat -e ``` This will show you the interfaces with errors, along with a count of errors. Check for faulty hardware or cables Visually inspect the network interface and cables for any signs of damage or disconnection. If the hardware appears to be faulty, replace it as necessary. Review network configuration settings Ensure that the network configuration on your system is correct, including the IP address, subnet mask, gateway, and DNS settings. If the configuration is incorrect, update it accordingly. Monitor network traffic Use network monitoring tools such as `Wireshark` or `tcpdump` to capture traffic on the affected interface. Analyze the captured traffic to identify any issues or patterns that may be causing the errors. Check for network congestion If the errors are due to network congestion, identify the sources of high traffic and implement measures to reduce congestion, such as traffic shaping, prioritizing, or rate limiting. Update network drivers and firmware Ensure that your network interface card (NIC) drivers and firmware are up-to-date. Check the manufacturer's website for updates and apply them as necessary.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thanks for sending a pull request! --> Summarize your changes here to communicate with the maintainers and make sure to put the link of that issue What types of changes does your code introduce to Litmus? Put an `x` in the boxes that apply [ ] New feature (non-breaking change which adds functionality) [ ] Bugfix (non-breaking change which fixes an issue) [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) [ ] Documentation Update (if none of the other choices applies) Put an `x` in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code. doc [ ] I have signed the commit for DCO to be passed. [ ] Lint and unit tests pass locally with my changes [ ] I have added tests that prove my fix is effective or that my feature works (if appropriate) [ ] I have added necessary documentation (if appropriate) Please add the links to the dependent PR need to be merged before this (if any).