For the complete documentation index, see llms.txt. This page is also available as Markdown.

Metrics

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.

Note: Correlate the following infrastructure metrics with In-Memory DB engine activity:

  • 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.

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.

Note: Cache hit ratio is a derived metric, not a raw exported value. Calculate it with the following PromQL expression (target: above 90%):

Viewing metrics

You can view these metrics in the Grafana dashboard, accessed either through the DCD or through the API.

Last updated

Was this helpful?