> 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/mariadb/overview/metrics.md).
# Metrics
Monitor IONOS CLOUD DBaaS MariaDB v2 clusters with infrastructure and database health metrics from node\_exporter and mysqld\_exporter, covering CPU, memory, disk I/O, connections, replication lag, buff
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. |
{% hint style="info" %}
**Note:** Interpret these [Infrastructure metrics](#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.
{% endhint %}
## 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.
{% hint style="info" %}
**Note:** `mysqld_exporter` listens on port `9104` by default.
{% endhint %}
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. |
{% hint style="info" %}
**Note:** Calculate the InnoDB buffer pool hit ratio (target: above 99%) as a derived metric:
```promql
1 - (
rate(mysql_global_status_innodb_buffer_pool_reads[5m])
/
rate(mysql_global_status_innodb_buffer_pool_read_requests[5m])
)
```
{% endhint %}
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](/cloud/databases/mariadb/how-tos/v2/view-mariadb-cluster-metrics.md) or through the [API](https://docs.ionos.com/cloud/tutorials/databases/mariadb/monitor-mariadb-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/mariadb/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.