> For the complete documentation index, see [llms.txt](https://docs.ionos.com/cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ionos.com/cloud/databases/in-memory-db/overview/metrics.md).
# Metrics
Monitor IONOS CLOUD In-Memory DB clusters with infrastructure and database health metrics from node\_exporter and redis\_exporter, covering CPU, memory, disk I/O, client connections, cache hit ratio, ke
In-Memory DB exposes a combination of infrastructure and database health metrics so you can monitor the state of your clusters. Infrastructure metrics describe the underlying node's resource usage, while database health metrics describe the behavior of the In-Memory DB engine itself.
## Infrastructure metrics
Infrastructure metrics describe the health of the underlying node that hosts a database cluster, rather than the database engine itself. These metrics are collected by `node_exporter` and cover CPU, memory, disk I/O, filesystem capacity, and network throughput at the operating-system level. Use them together with database-specific metrics to distinguish node-level resource constraints, such as CPU saturation or low disk space, from issues originating inside the database engine.
The following metrics are available to gauge the infrastructure health of a database cluster.
CPU and system load
| **Metric** | **Description** |
| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `node_cpu_seconds_total` | Cumulative CPU time spent in each mode (idle, user, system, I/O wait) per core. Apply `rate()` to convert to per-second usage. Monitor this metric to detect storage bottlenecks that degrade query execution. Alert if I/O wait exceeds 1%. |
| `node_load1` | Average number of runnable or uninterruptible processes over the last minute. Reflects immediate CPU demand on the node. Monitor this metric to detect contention that delays query processing. A sustained value above the number of available CPU cores indicates load pressure. |
| `node_load5` | Average number of runnable or uninterruptible processes over the last 5 minutes. Smooths short-lived spikes to confirm whether a `node_load1` spike represents a genuine load trend. Monitor this metric to distinguish transient spikes from sustained pressure. |
| `node_load15` | Average number of runnable or uninterruptible processes over the last 15 minutes. Serves as a long-term trend indicator. Monitor this metric to assess sustained workload growth and plan capacity adjustments for the cluster. |
| `node_boot_time_seconds` | Unix timestamp recording when the node last started. Subtract this value from the current time (`time() - node_boot_time_seconds`) to derive node uptime. Monitor this metric to detect unexpected restarts or failover events in the cluster. |
Memory
| **Metric** | **Description** |
| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `node_memory_MemAvailable_bytes` | Estimated memory available for new allocations without swapping, accounting for reclaimable memory and buffers. Monitor this metric to detect memory pressure that can slow queries. Alert if the value falls below 10% of `node_memory_MemTotal_bytes`. |
| `node_memory_MemTotal_bytes` | Total physical memory installed on the node. Use the value as the denominator when calculating the memory utilisation ratio (`1 - MemAvailable_bytes / MemTotal_bytes`). |
Disk I/O
| **Metric** | **Description** |
| ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `node_disk_io_time_seconds_total` | Cumulative time the disk device was actively processing I/O requests. Apply `rate()` to obtain a utilisation ratio between 0 and 1. Monitor this metric to detect I/O saturation. A ratio above 0.9 indicates saturation that can degrade query or command execution. |
| `node_disk_read_bytes_total` | Cumulative bytes read from the disk device since node start. Apply `rate()` to derive read throughput in bytes per second. Monitor this metric to detect sequential scans or index rebuilds on the data volume. |
| `node_disk_written_bytes_total` | Cumulative bytes written to the disk device since node start. Apply `rate()` to derive write throughput in bytes per second. Monitor this metric to track write throughput and identify sustained write pressure on the data volume. |
| `node_disk_reads_completed_total` | Cumulative read operations successfully completed by the disk device. Apply `rate()` to compute read IOPS. Monitor this metric to detect frequent buffer cache misses that force data retrieval from disk. |
| `node_disk_writes_completed_total` | Cumulative write operations successfully completed by the disk device. Apply `rate()` to compute write IOPS. Monitor this metric to identify spikes from transaction commits, background maintenance operations, or bulk load operations. |
Filesystem
| **Metric** | **Description** |
| ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `node_filesystem_avail_bytes` | Bytes available to unprivileged processes on the filesystem, monitored separately for the DBDATA and BACKUP volumes. Monitor this metric to prevent write failures. Alert if the value falls below 15% of `node_filesystem_size_bytes`. |
| `node_filesystem_size_bytes` | Total capacity of the filesystem in bytes. Use the value as the denominator for the capacity utilisation ratio (`1 - avail_bytes / size_bytes`). Tracked across DBDATA and BACKUP mount points to support storage sizing decisions. |
Network
| **Metric** | **Description** |
| ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `node_network_receive_bytes_total` | Cumulative bytes received on the network adapter since node start. Apply `rate()` to derive inbound throughput in bytes per second. Monitor this metric to detect spikes in client connections, replication traffic, or backup data ingestion. |
| `node_network_transmit_bytes_total` | Cumulative bytes transmitted on the network adapter since node start. Apply `rate()` to derive outbound throughput in bytes per second. Monitor this metric to track large query result sets, replication traffic to standby nodes, or backup data egress. |
{% hint style="info" %}
**Note:** Interpret these [Infrastructure metrics](#infrastructure-metrics) together with In-Memory DB engine behavior:
* **Write throughput** (`node_disk_written_bytes_total`) and **write IOPS** (`node_disk_writes_completed_total`): Spikes typically coincide with AOF persistence flushes or RDB snapshot operations. Correlate with `redis_rdb_last_save_timestamp_seconds` and `redis_aof_enabled`.
* **Disk I/O saturation** (`node_disk_io_time_seconds_total`): Saturation during persistence operations can cause command latency spikes. Correlate with `redis_commands_duration_seconds_total`.
{% endhint %}
## Database health metrics
Unlike the infrastructure metrics, which describe the health of the underlying node, the metrics in this section come from `redis_exporter` and describe the health of the In-Memory DB engine itself. In-Memory DB is powered by Valkey. Metrics use the `redis_*` prefix because `redis_exporter` natively supports Valkey through protocol compatibility; the engine itself is Valkey.
They report on activity inside the running instance, such as reachability and uptime, memory usage, and fragmentation, client connections, command throughput, latency, cache hit/miss rates, network traffic, and key statistics, giving you visibility into database-level behavior that node-level resource metrics cannot show.
The following metrics are available to gauge the health and performance of In-Memory DB clusters.
Instance health and identity
| **Metric** | **Description** |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `redis_up` | Indicates whether the instance is reachable. A value of `1` means the instance is up; a value of `0` means it is unreachable. Alert immediately if the value is `0`. |
| `redis_uptime_in_seconds` | The instance uptime, in seconds. Monitor this metric for unexpected restarts. |
| `redis_instance_info` | An informational metric exposing labels such as `role` (primary or replica) and `redis_version` (the running Valkey engine version). Use the labels rather than the metric value. |
Memory
| **Metric** | **Description** |
| ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `redis_memory_used_bytes` | The amount of memory currently in use, in bytes. Monitor growth relative to `redis_memory_max_bytes`. |
| `redis_memory_max_bytes` | The configured `maxmemory` limit, in bytes. A value of `0` means the limit is unset. Set alerts relative to the available system RAM. |
| `redis_config_maxmemory` | The configured `maxmemory` value read from the running configuration. Compare with `redis_memory_used_bytes` to track headroom. |
| `redis_mem_fragmentation_ratio` | The ratio of RSS memory to used memory. A typical range is 1.0–1.5; a value above 1.5 indicates fragmentation. |
| `redis_memory_used_dataset_bytes` | The portion of used memory occupied by the actual dataset, excluding overhead. |
| `redis_memory_used_overhead_bytes` | The portion of used memory consumed by internal structures rather than the dataset itself. |
| `redis_memory_used_lua_bytes` | The amount of memory used by the Lua scripting engine. |
| `redis_memory_used_rss_bytes` | The resident set size: physical memory allocated to the process by the operating system. Compare with `redis_memory_used_bytes` to derive `redis_mem_fragmentation_ratio`. |
Client connections
| **Metric** | **Description** |
| ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `redis_connected_clients` | The number of currently connected clients. Alert at the configured `maxclients` threshold. |
| `redis_blocked_clients` | The number of clients blocked on blocking commands, such as `BLPOP`. Non-zero values are expected when blocking commands are in use; alert on sustained values. |
| `redis_connected_slaves` | The number of connected replicas. Monitor for unexpected drops, which indicate a replica has disconnected. |
| `redis_config_maxclients` | The configured `maxclients` limit. Use together with `redis_connected_clients` to calculate connection utilisation. |
| `redis_cluster_connections` | The number of cluster bus connections used for inter-node communication. |
| `redis_connections_received_total` | The cumulative number of connections accepted since start. Apply `rate()` to derive the connection rate. |
| `redis_rejected_connections_total` | The cumulative number of connections rejected, typically because `redis_config_maxclients` was reached. Alert on any sustained increase. |
Cache performance and key statistics
| **Metric** | **Description** |
| ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `redis_keyspace_hits_total` | The cumulative number of successful key lookups. Use together with `redis_keyspace_misses_total` to compute the cache hit ratio. |
| `redis_keyspace_misses_total` | The cumulative number of failed key lookups (key not found). A high miss rate indicates that keys have expired or the cache is not warm. |
| `redis_db_keys` | The total number of keys per database. Monitor growth over time. |
| `redis_db_keys_expiring` | The number of keys with a TTL set, per database. Compare with `redis_db_keys` to assess TTL coverage. |
| `redis_expired_keys_total` | The cumulative number of keys removed automatically because their TTL elapsed. Apply `rate()` to track the expiration rate. |
| `redis_evicted_keys_total` | The cumulative number of keys evicted due to the `maxmemory` policy. This is the primary KPI for this engine. Alert on a sustained non-zero rate rather than the raw counter value: `rate(redis_evicted_keys_total[5m]) > 0`. |
Persistence
| **Metric** | **Description** |
| --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `redis_rdb_last_save_timestamp_seconds` | The Unix timestamp of the last RDB snapshot. Derive the time since the last save and alert if the gap exceeds your configured threshold. |
| `redis_rdb_changes_since_last_save` | The number of write operations since the last RDB save. A high value combined with no recent save indicates a risk of data loss on crash. |
| `redis_aof_enabled` | Indicates whether AOF persistence is enabled. A value of `1` means enabled; a value of `0` means disabled. This value is set by the IONOS CLOUD configuration and is informational. |
Command throughput and latency
| **Metric** | **Description** |
| --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| `redis_commands_total` | The cumulative number of calls per command. Apply `rate()` to derive commands per second, or `topk()` to identify the busiest commands. |
| `redis_commands_duration_seconds_total` | The cumulative time spent executing each command. Use together with `redis_commands_total` to derive average latency per command. |
Network traffic
| **Metric** | **Description** |
| ------------------------------ | ---------------------------------------------------------------------------------------- |
| `redis_net_input_bytes_total` | The cumulative bytes received from clients. Apply `rate()` to derive inbound throughput. |
| `redis_net_output_bytes_total` | The cumulative bytes sent to clients. Apply `rate()` to derive outbound throughput. |
Errors
| **Metric** | **Description** |
| -------------------- | ------------------------------------------------------------------------------------------------------ |
| `redis_errors_total` | The cumulative number of command errors, grouped by the `err` label. Monitor for unexpected increases. |
{% hint style="info" %}
**Note:** Cache hit ratio is a derived metric, not a raw exported value. Calculate it with the following `PromQL` expression (target: above 90%):
```promql
rate(redis_keyspace_hits_total[5m])
/
(
rate(redis_keyspace_hits_total[5m])
+ rate(redis_keyspace_misses_total[5m])
)
```
{% endhint %}
## View metrics
You can view these metrics in the Grafana dashboard, accessed either through the [DCD](/cloud/databases/in-memory-db/how-tos/v2/view-in-memory-db-cluster-metrics.md) or through the [API](https://docs.ionos.com/cloud/tutorials/databases/in-memory-db/monitor-in-memory-db-databases).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.ionos.com/cloud/databases/in-memory-db/overview/metrics.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.