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

Metrics

MariaDB v2 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 MariaDB 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: Interpret these Infrastructure metrics together with MariaDB engine behavior:

  • Disk I/O utilisation (node_disk_io_time_seconds_total): Sustained saturation delays InnoDB redo log flushing and checkpoint completion.

  • Write throughput (node_disk_written_bytes_total): Elevated write rates typically reflect InnoDB redo log flushing and buffer pool page writes.

  • Read IOPS (node_disk_reads_completed_total): High values may indicate frequent misses in the InnoDB buffer pool cache.

  • Write IOPS (node_disk_writes_completed_total): Spikes often coincide with InnoDB buffer pool flushing on large or frequently updated tables.

  • Network transmit throughput (node_network_transmit_bytes_total): Elevated values during write-heavy periods typically reflect binary log streaming to secondary nodes.

  • Network receive throughput (node_network_receive_bytes_total): Elevated values typically reflect client write traffic on the primary node, or incoming binary log events on a secondary node.

Database health metrics

Unlike the infrastructure metrics, which describe the health of the underlying node, the metrics in this section come from mysqld_exporter and describe the health of the MariaDB database engine itself. They report on activity inside the running instance, such as connection counts, query throughput, InnoDB buffer pool performance, locking, and replication status, giving you visibility into database-level behavior that node-level resource metrics cannot show.

Note: mysqld_exporter listens on port 9104 by default.

The following metrics are available to gauge the health and performance of MariaDB v2 clusters.

Database health and connections

Metric

Description

mysql_up

Indicates whether MariaDB 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.

mysql_global_status_threads_connected

The number of currently open connections. Compare this value with mysql_global_variables_max_connections and alert when usage reaches 80% of the limit.

mysql_global_status_max_used_connections

The highest number of connections in use at the same time since the server last started. Use this as a baseline for connection capacity planning.

mysql_global_variables_max_connections

The configured max_connections value. Use this together with mysql_global_status_threads_connected to calculate connection utilisation.

mysql_global_status_aborted_connects

The cumulative number of failed connection attempts. Use rate() in PromQL; a rising rate indicates authentication failures or network issues.

Query performance

Metric

Description

mysql_global_status_questions

The cumulative number of statements sent by clients to the server. Use rate() in PromQL to calculate queries per second (QPS).

mysql_global_status_queries

The cumulative number of statements executed by the server, including those executed within stored procedures. Use rate() alongside mysql_global_status_questions to distinguish client-issued queries from total query volume.

mysql_global_status_slow_queries

The cumulative number of queries that exceeded the long_query_time threshold. A rising rate indicates queries that need optimisation or indexing.

mysql_global_status_commands_total

The cumulative count of statements executed, broken down by command type (select, insert, update, delete, alter, and others) using the command label. Use rate() to see the read/write mix of the workload.

mysql_global_status_select_scan

The cumulative number of joins that performed a full table scan. A rising rate indicates queries that are missing an index.

InnoDB storage engine

Metric

Description

mysql_global_status_innodb_buffer_pool_reads

The cumulative number of logical reads that InnoDB served from disk rather than the buffer pool. A high value relative to read requests indicates memory pressure; consider increasing innodb_buffer_pool_size.

mysql_global_status_innodb_buffer_pool_read_requests

The cumulative number of logical read requests to the InnoDB buffer pool. Use together with mysql_global_status_innodb_buffer_pool_reads to compute the buffer pool hit ratio.

mysql_info_schema_innodb_metrics_buffer_pool_dirty_pages

The number of buffer pool pages holding unflushed changes. Sustained high values can delay checkpoint completion.

mysql_info_schema_innodb_metrics_buffer_pool_pages

The total number of pages in the InnoDB buffer pool. Use as the denominator when calculating what share of the buffer pool is dirty.

mysql_global_status_innodb_history_list_length

The length of the InnoDB undo log history list. A continuously growing value indicates old row versions are not being purged, typically because of a long-running transaction.

mysql_global_status_innodb_row_lock_waits

The cumulative number of times an operation on an InnoDB table had to wait for a row lock. Use rate() to track lock contention.

mysql_global_status_innodb_row_lock_time_avg

The average time, in milliseconds, spent waiting for a row lock. Alert if this value is consistently above 1000 ms.

mysql_global_status_table_locks_immediate

The cumulative number of times a table lock was granted immediately.

mysql_global_status_table_locks_waited

The cumulative number of times a table lock could not be granted immediately and a session had to wait. A rising rate relative to mysql_global_status_table_locks_immediate indicates table-level lock contention.

mysql_global_status_opened_tables

The cumulative number of times a table has been opened. A high rate relative to mysql_global_status_open_tables suggests the table cache is too small.

mysql_global_status_open_tables

The number of tables currently open.

mysql_global_status_table_open_cache_hits

The cumulative number of hits for the open tables cache. Use together with mysql_global_status_opened_tables to assess table cache effectiveness.

Note: Calculate the InnoDB buffer pool hit ratio (target: above 99%) as a derived metric:

Replication

Metric

Description

mysql_slave_status_seconds_behind_master

The replication lag on a replica instance, measured in seconds. For critical workloads, alert when this value exceeds 30 seconds.

mysql_slave_status_slave_io_running

Indicates whether the replica's I/O thread, which fetches events from the primary's binary log, is running. Alert if this value is 0.

mysql_slave_status_slave_sql_running

Indicates whether the replica's SQL thread, which applies fetched events, is running. Alert if this value is 0.

Network

Metric

Description

mysql_global_status_bytes_received

The cumulative number of bytes received from all clients. Use rate() to derive inbound throughput.

mysql_global_status_bytes_sent

The cumulative number of bytes sent to all clients. Use rate() to derive outbound throughput.

View metrics

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

Last updated

Was this helpful?