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

This alert is triggered when a `systemd` mount unit enters a `failed state`. If you receive this alert, it means that your system has encountered an issue with mounting a filesystem or a mount point. `systemd` is the init system used in most Linux distributions to manage services, processes, and system startup. A mount unit is a configuration file that describes how a filesystem or mount point should be mounted and managed by `systemd`. A `failed state` indicates that there was an issue with mounting the filesystem, or the mount point failed to function as expected. This can be caused by multiple factors, such as incorrect configuration, missing dependencies, or hardware issues. Identify the failed mount unit Check the status of your `systemd` mount units by running: ``` systemctl list-units --type=mount ``` Look for units with a `failed` state. Check the journal logs To gain more insight into the issue, check the `systemd` journal logs for the failed mount unit: ``` journalctl -u [unit-name] ``` Replace `[unit-name]` with the actual name of the failed mount unit. Verify the mount unit configuration Review the mount unit configuration file located at `/etc/systemd/system/[unit-name].mount`. Ensure that options such as the filesystem type, device, and mount point are correct. Check system logs for hardware or filesystem issues Review the system logs (e.g., `/var/log/syslog` or `/var/log/messages`) for any hardware or filesystem related errors. Ensure that the device and mount point are properly connected and accessible. Restart the mount unit If you have made any changes to the configuration or resolved a hardware issue, attempt to restart the mount unit by running: ``` systemctl restart [unit-name].mount ``` Seek technical support If the issue persists, consider reaching out to support, as there might be an underlying issue that needs to be addressed.
Project: Vector (Observability and Analysis / Observability)
File: errors.md

title: VRL error reference short: Errors weight: 2 VRL is a language, which means that a VRL program doesn't compile unless every potential error is handled. Observability data is notoriously unpredictable and fail safety ensures that your VRL programs elegantly handle malformed data. {{< vrl/errors/compile-time >}} A runtime error occurs after compilation and during program runtime. Because VRL is fail safe, all runtime errors must be . This forces you to address how VRL programs should respond to errors. Runtime errors are strings that describe the error. You have three options for handling errors in VRL: the error the error the error As documented in the , you can assign errors when invoking an expression that's fallible. When assigned, runtime errors are simple strings: ```coffee structured, err = parse_json("not json") if err != null { log("Unable to parse JSON: " + err, level: "error") } else { . = merge(., structured) } ``` If the expression fails, the `ok` assignment target is assigned the "empty" value of its type: ```coffee foo, err = to_int(.foo) if err == null { .result = foo * 5 } ``` The above example compiles because `foo` will either be assigned the integer representation of `.foo` if it can be coerced to an integer, or it will be set to the "empty integer value" `0` if `.foo` can't be coerced into an integer. Because of this, it is important to always check whether `err` is null before using the `ok` value of an infallible assignment. Type | Empty value :-|:-- String | `""` Integer | `0` Float | `0.0` Boolean | `false` Object | `{}` Array | `[]` Timestamp | `t'1970-01-01T00:00:00Z'` (Unix epoch) Regular expression | `r''` Null | `null` As documented in the , you can coalesce errors to efficiently step through multiple expressions: ```coffee structured = parsejson("not json") ?? parsesyslog("not syslog") ?? {} . = merge(., structured) ``` As documented in the , you can raise errors to immediately abort the program by adding a `!` to the end of the function name: ```coffee structured = parse_json!("not json") . = merge(., structured) ``` {{< warning title="Raising errors should be used with caution" >}} While raising errors can simplify your program, you should think carefully before aborting your program. If this operation is critical to the structure of your data you should abort, otherwise consider handling the error and proceeding with the rest of your program. {{< /warning >}}
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: MAINTAINERS.md

This page lists all active maintainers of this repository. If you were a maintainer and would like to add your name to the Emeritus list, please send us a PR. See for governance guidelines and how to become a maintainer. See for general contribution guidelines. , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: SPLIT_MERGE_COMPACTOR.md

Given the list of all blocks in the storage: Group blocks by resolution + external labels (excluding shard ID). For each group: Group blocks by compactable time ranges (eg. 2h, 6h, 12h, 24h) Given the time range, if the time range is the "smallest one" (eg. 2h) AND there are non-sharded blocks, then we should split the block Example: TR=2h Case 1: all the blocks for the 2h time range have the "shard ID" label in the meta.json. In this case, we shouldn't run the split stage anymore. Case 2: there is at least 1 block for the 2h time range NOT having "shard ID" in the meta.json. In this case, we should run the split stage on 2h blocks without the "shard ID". Horizontal sharding Each compactor will take decisions without a central coordination Each compactor will run the planning for ALL blocks Each compactor will only execute "jobs" belonging to its shard Splitting job (each job consists of a set of blocks which will be merged together calling CompactWithSplitting()) Which blocks should belong to a specific job? We don't want all blocks to be compacted together, otherwise doesn't scale We use the configured number of output shards to determine how many concurrent jobs we want to run to split/shard blocks For each block to split, we add it to the job with index `hash(blockID) % numShards` Output: up to `numShards` jobs (each job contain the set of blocks to be merged together when running CompactWithSplitting()) How can we know if the compactor instance should process a job or not? A job is owned if `hash(tenant + stage + time range + shard ID)` belongs to the compactor tokens If the previous check has not produced any job AT ALL it means all the blocks for the "smallest time range" are already split (or there are no blocks at all), so we can proceed with the merging stage: Group blocks by "shard ID" (taking in account the case a block doesn't have the shard ID) Create a job for each group that contains 2+ blocks (because they need to be merged together) Add the job to the list of "valid jobs to execute" only if for the job shard ID there are no other jobs already in the list of "valid jobs" overlapping its time range Execute the jobs that belong to the compactor instance Loop through jobs and filter out the jobs hashes not belonging to the compactor tokens
Project: Vector (Observability and Analysis / Observability)
File: 2020-06-18-remove-custom-dns-resolution.md

date: "2020-07-23" title: "Custom DNS resolution removal" description: "Vector once again follows the guidance of the host on DNS lookups." authors: ["hoverbear"] hideonrelease_notes: false pr_numbers: [2812] release: "0.10.0" badges: type: "breaking change" In Vector 0.10.0, we no longer support custom DNS servers. This feature was adding considerable code complexity and is better handled outside of Vector through tools like . In the interest of keeping Vector lean and understandable, as well as improving it's maintainability, we've chosen to remove it. Make the following changes in your `vector.toml` file: ```diff title="vector.toml" dns_servers = [...] ``` If you were using this feature you may need to configure your host to consult DNS. This can be achieved through tools like . Alternatively, you can wrap Vector in a container and set the DNS for the container. This can be done via or
Project: Grafana Loki (Observability and Analysis / Observability)
File: tsdb.md

title: Single Store TSDB (tsdb) menuTitle: TSDB description: Describes the Loki time series database (TSDB) single store. weight: 100 Starting with Loki v2.8, TSDB is the recommended Loki index. It is heavily inspired by the Prometheus's TSDB . For a deeper explanation you can read Loki maintainer Owen's . The short version is that this new index is more efficient, faster, and more scalable. It also resides in object storage like the index which preceded it. To get started using TSDB, add the following configurations to your `config.yaml`: ```yaml schema_config: configs: from: "2023-01-03" # <- A date in the past index: period: 24h prefix: index_ object_store: gcs schema: v12 store: boltdb-shipper from: "2023-01-05" # <- A date in the future index: period: 24h prefix: index_ object_store: gcs schema: v13 store: tsdb storage_config: boltdb_shipper: activeindexdirectory: /data/index buildpertenant_index: true cache_location: /data/boltdb-cache indexgatewayclient: server_address: dns:///index-gateway.<namespace>.svc.cluster.local:9095 tsdb_shipper: activeindexdirectory: /data/tsdb-index cache_location: /data/tsdb-cache indexgatewayclient: server_address: dns:///index-gateway.<namespace>.svc.cluster.local:9095 query_scheduler: maxoutstandingrequestspertenant: 32768 querier: max_concurrent: 16 ``` We've added a user per-tenant limit called `tsdbmaxqueryparallelism` in the `limitsconfig`. This functions the same as the prior `maxqueryparallelism` configuration but applies to tsdb queries instead. Since the TSDB index will create many more smaller queries compared to the other index types before it, we've added a separate configuration so they can coexist. This is helpful when transitioning between index types. The default parallelism is `512` which should work well for most cases, but you can extend it globally in the `limits_config` or per-tenant in the `overrides` file as needed. Previously we would statically shard queries based on the index row shards configured . TSDB does Dynamic Query Sharding based on how much data a query is going to be processing. We additionally store size(KB) and number of lines for each chunk in the TSDB index which is then used by the for planning the query. Based on our experience from operating many Loki clusters, we have configured TSDB to aim for processing 300-600 MBs of data per query shard. This means with TSDB we will be running more, smaller queries. TSDB is a compact and optimized format. Loki does not currently use an index cache for TSDB. If you are already using Loki with other index types, it is recommended to keep the index caching until all of your existing data falls out of ) or your configured `maxquerylookback` under . After that, we suggest running without an index cache (it isn't used in TSDB).
Project: Checkmk (Observability and Analysis / Observability)
File: 15842.md

key | value | date | 2024-04-03T07:47:56+00:00 version | 2.3.0b4 class | feature edition | cre component | checks level | 2 compatible | yes With this release MS SQL Server is monitored using new plugin and new GUI. The old plugin is still supported but are considered deprecated. Key Enhancements out-of-the-box: Configuration flexibility: The plugin can be configured through a YAML config file for any edition and/or a graphical user interface (GUI) for enterprise edition or better. Cross platform: The plugin can be deployed on Linux and Windows. Enhanced monitoring capabilities: Supports monitoring of remote databases on both Linux and Windows hosts, in addition to local monitoring on Windows hosts. Customizable monitoring sections: Sections are now selectable and configurable Customizable SQL statements: you may change SQL statement either manually(place file in `mssql` sub directory in config dir) or using `Custom files` rule in GUI. Multi-instance support: Enables the selection of different instances for monitoring. Every instance can be configured separately Multi-host support: possible to monitor databases on various hosts using one deployed plugin. Security enhancements: Limited support for certificates is now available. Asynchronous operation: Any section with exception `instances` can be set up for asynchronous operation. Piggyback: It's possible to direct the output of a plugin to a different host, rather than to the host that retrieves the data. Other improvements: Automatic detection of instances is possible for any Windows host, local and remote, depending on SQL Server Setup. Full logging support including rotation and file limits Limit for maximal connection counts Cache time and timeout can be configured too With regard to the old plug-in, there are also a few restrictions at the moment: The database instances must be accessible via TCP/IP. If several databases are running on a system, each using their own IP addresses, these must be explicitly specified in the configuration of the agent plug-in, as the addresses and ports are currently not yet found automatically.
Project: Netdata (Observability and Analysis / Observability)
File: redis_connections_rejected.md

The `redisconnectionsrejected` alert is triggered when the number of connections rejected by Redis due to the `maxclients` limit being reached in the last minute is greater than 0. This means that Redis is no longer able to accept new connections as it has reached its maximum allowed clients. The `maxclients` limit in Redis is the maximum number of clients that can be connected to the Redis instance at the same time. When the Redis server reaches its `maxclients` limit, any new connection attempts will be rejected. Check the current number of connections in Redis: Use the `redis-cli` command-line tool to check the current number of clients connected to the Redis server: ``` redis-cli client list | wc -l ``` Check Redis configuration file for the maxclients setting: The `maxclients` value can be found in the Redis configuration file, usually called `redis.conf`. Open the file and search for `maxclients` to find the current limit. ``` grep 'maxclients' /etc/redis/redis.conf ``` Increase the maxclients limit. If necessary, increase the `maxclients` limit in the Redis configuration file (`redis.conf`), and then restart the Redis service to apply the changes: ``` sudo systemctl restart redis ``` **Note**: Keep in mind that increasing the `maxclients` limit might cause increased memory consumption. Inspect client connections. Determine if the connections are legitimate and needed for your application's requirements, or if some clients are connecting unnecessarily. Optimize your application or services as needed to reduce the number of unwanted connections. Monitor connection usage. Keep an eye on connection usage over time to better understand the trends and patterns in your system, and adjust the `maxclients` configuration accordingly.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: too-many-jobs-in-queue.md

title: Too many jobs in the queue description: Troubleshoot too many jobs in the queue weight: 474 aliases: ../operations/troubleshooting/too-many-jobs-in-queue/ The error message might also be `queue doesn't have room for 100 jobs` `failed to add a job to work queue` You may see this error if the compactor isnt running and the blocklist size has exploded. Possible reasons why the compactor may not be running are: Insufficient permissions. Compactor sitting idle because no block is hashing to it. Incorrect configuration settings. Check metric `tempodbcompactionbyteswrittentotal` If this is greater than zero (0), it means the compactor is running and writing to the backend. Check metric `tempodbcompactionerrors_total` If this metric is greater than zero (0), check the logs of the compactor for an error message. Verify that the Compactor has the LIST, GET, PUT, and DELETE permissions on the bucket objects. If these permissions are missing, assign them to the compactor container. For detailed information, check - https://grafana.com/docs/tempo/latest/configuration/s3/#permissions If theres a compactor sitting idle while others are running, port-forward to the compactors http endpoint. Then go to `/compactor/ring` and click Forget on the inactive compactor. Check the following configuration parameters to ensure that there are correct settings: `maxblockbytes` to determine when the ingester cuts blocks. A good number is anywhere from 100MB to 2GB depending on the workload. `maxcompactionobjects` to determine the max number of objects in a compacted block. This should relatively high, generally in the millions. `retention_duration` for how long traces should be retained in the backend. Check the storage section of the config and increase `queue_depth`. Do bear in mind that a deeper queue could mean longer waiting times for query responses. Adjust `max_workers` accordingly, which configures the number of parallel workers that query backend blocks. ``` storage: trace: pool: max_workers: 100 # worker pool determines the number of parallel requests to the object store backend queue_depth: 10000 ```
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_cluster.ApiListSingleNamespaceOptions.md

title: "Interface: ApiListSingleNamespaceOptions" linkTitle: "ApiListSingleNamespaceOptions" slug: "libk8scluster.ApiListSingleNamespaceOptions" .ApiListSingleNamespaceOptions `Optional` cluster: `string` The cluster to get the object from. By default uses the current cluster being viewed. _ `Optional` namespace: `string` The namespace to get the object from. _ `Optional` queryParams: The parameters to be passed to the API endpoint.
Project: Checkmk (Observability and Analysis / Observability)
File: 16579.md

key | value | date | 2024-03-01T10:46:38+00:00 version | 2.4.0b1 class | feature edition | cre component | rest-api level | 1 compatible | yes With this Werk a new endpoint for modifying downtimes is incorporated. It is possible to modify the comment and the end timestamp as in the GUI. The selection of downtimes to modify can be done by id, by query, or by hostname and service description. Method: PUT URL: domain-types/downtime/actions/modify/invoke
Project: Grafana (Observability and Analysis / Observability)
File: view-server-org-list-and-edit.md

labels: products: enterprise oss title: View org list as server admin {{< docs/list >}} {{< docs/shared lookup="manage-users/view-server-org-list.md" source="grafana" version="<GRAFANA VERSION>" >}} Click the name of the organization that you want to edit. {{< /docs/list >}}
Project: Netdata (Observability and Analysis / Observability)
File: systemd_automount_unit_failed_state.md

This alert is triggered when a `systemd` automount unit enters the `failed` state. It means that a mounted filesystem has failed or experienced an error and thus is not available for use. An automount unit is a type of `systemd` unit that handles automounting filesystems. It defines when, where, and how a filesystem should be automatically mounted on the system. Automount units use the `.automount` file extension and are typically located in the `/etc/systemd/system` directory. Identify the failed automount unit(s) To list all `systemd` automount units and their states, run the following command: ``` systemctl list-units --all --type=automount ``` Look for the unit(s) with a `failed` state. Check the automount unit file Examine the failed unit's configuration file in `/etc/systemd/system/` or `/lib/systemd/system/` (depending on your system). If there is an error in the configuration, fix it and reload the `systemd` configuration. ``` sudo systemctl daemon-reload ``` Check the journal for errors Use the `journalctl` command to check for any system logs related to the failed automount unit: ``` sudo journalctl -u [UnitName].automount ``` Replace `[UnitName]` with the name of the failed automount unit. Analyze the logs to identify the root cause of the failure. Attempt to restart the automount unit After identifying and addressing the cause of the failure, try to restart the automount unit: ``` sudo systemctl restart [UnitName].automount ``` Check the unit's status: ``` systemctl status [UnitName].automount ``` If it's in the `active` state, the issue has been resolved.
Project: Graylog (Observability and Analysis / Observability)
File: DataTable.md

```js import DataTable from './DataTable'; const entities = [ { id: '1', title: 'Dr. Emmett Brown', nickname: 'Doc', roles: ['Doctor', 'Human'], description: '1.21 GIGAWATTS!!!', }, { id: '2', title: 'Marty McFly', nickname: 'Marty', roles: ['Student', 'Human'], description: 'Nobody calls me chicken', }, ]; const filterKeys = ['title', 'nickname']; const headers = ['', 'Name', 'Nickname', 'Role', 'Quote']; const rowFormatter = (entity, idx) => { return ( <tr key={entity.id}> <td>{idx + 1}</td> <td>{entity.title}</td> <td>{entity.nickname}</td> <td>{entity.roles.join(', ')}</td> <td>{entity.description}</td> </tr> ); }; <DataTable id="entity-list" className="table-hover" headers={headers} headerCellFormatter={(header) => <th>{header}</th>} sortByKey={'title'} rows={entities} filterBy="role" filterSuggestions={['Doctor', 'Student', 'Human']} dataRowFormatter={rowFormatter} filterLabel="Filter entities" filterKeys={filterKeys} /> ``` `DataTable` with `sortBy` function: ```js import DataTable from './DataTable'; const entities = [ { id: '1', title: 'Dr. Emmett Brown', nickname: 'Doc', roles: ['Doctor', 'Human'], description: '1.21 GIGAWATTS!!!', }, { id: '2', title: 'Marty McFly', nickname: 'Marty', roles: ['A Student', 'Human'], description: 'Nobody calls me chicken', }, ]; const headers = ['', 'Name', 'Nickname', 'Role', 'Quote']; const rowFormatter = (entity, idx) => { return ( <tr key={entity.id}> <td>{idx + 1}</td> <td>{entity.title}</td> <td>{entity.nickname}</td> <td>{entity.roles.join(', ')}</td> <td>{entity.description}</td> </tr> ); }; <DataTable id="entity-list" className="table-hover" headers={headers} headerCellFormatter={(header) => <th>{header}</th>} sortBy={entity => entity.roles[0]} rows={entities} filterBy="role" filterSuggestions={['Doctor', 'Student', 'Human']} dataRowFormatter={rowFormatter} filterKeys={[]} /> ```
Project: Vector (Observability and Analysis / Observability)
File: 2020-02-05-merge-partial-docker-events.md

date: "2020-07-13" title: "Automatically merge partial Docker events" description: "Docker splits long messages by default, and now Vector merges them back for you" authors: ["binarylogic"] pr_numbers: [1457] release: "0.8.0" hideonrelease_notes: false badges: type: "enhancement" domains: ["sources"] sources: ["docker"] platforms: ["docker"] Anyone that was worked with Docker logs knows how frustrating this problem can be. Docker, by default, splits log messages that exceed 16kb. While 16kb seems like a lot, it can easily be exceeded if you're logging rich structured events. This can be a very difficult and frustrating problem to solve with other tools (we speak from experience). In this release, Vector solves this automatically with a new `autopartialmerge` option in the `docker_logs` source. ```toml title="vector.toml" [sources.mysourceid] type = "docker_logs" autopartialmerge = true ``` We love assimilation and look forward to a future where our individualistic human personalities can also be merged into a societal hive mind.