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

Monitor MariaDB v2 Clusters Using Grafana

Overview

This tutorial demonstrates how to configure observability for MariaDB v2 clusters on IONOS CLOUD using the Logging Service and Monitoring Service. Once both services are activated at the contract level and the cluster level, metrics and logs stream to a regional Grafana endpoint where you can search and visualize MariaDB health metrics.

MariaDB v2 on IONOS CLOUD provides two categories of observable metrics:

  • Infrastructure metrics, collected by node_exporter, covering CPU, memory, disk I/O, filesystem capacity, and network throughput at the operating-system level.

  • Database health metrics, sourced from mysqld_exporter, covering connection counts, query throughput, InnoDB buffer pool performance, locking, and replication status.

MariaDB v2 metrics provide actionable insight into cluster performance, enabling reliable operations, faster incident resolution, and data-driven capacity planning for production deployments. For the complete list of available metrics, see Metrics.

Target audience

This tutorial targets database administrators, DevOps engineers, and platform engineers who manage MariaDB workloads on IONOS CLOUD. Readers benefit from prior experience with REST APIs, Bearer token authentication, and basic PromQL or Grafana dashboard concepts.

What you will learn

By following this tutorial, you will learn how to:

  • Activate observability services and allow log and metric collection on a MariaDB v2 cluster.

  • Access the regional Grafana endpoint and search for MariaDB metrics.

  • Apply recommended alert thresholds for CPU, memory, disk, connections, and replication metrics.

Prerequisites

Ensure you have:

  • An active IONOS CLOUD contract with permissions to manage observability and database resources.

  • A valid IONOS CLOUD API token exported as IONOS_TOKEN.

  • A MariaDB v2 cluster, or permission to create one. For more information, see MariaDB v2 API specification.

  • curl or any HTTP client for API calls.

  • A web browser to use Grafana.

Cost considerations

The following resources are billable and incur costs when you use them:

  • Logging and Monitoring services: Charges apply per region after activation.

  • MariaDB v2 clusters: Compute, storage, and Point-in-Time Recovery (PITR) backup charges apply independent of observability settings.

Note: Delete clusters and make observability services inactive if not in use to avoid ongoing charges.

Procedure

The activation flow has two independent layers. You activate the Logging and Monitoring services once per region at the contract level, and you toggle log and metric collection per cluster. Both layers must show true before data appears in Grafana.

Use the following procedure to configure observability for a MariaDB v2 cluster:

1

Activate the Logging Service for a region

Send a request to the regional Logging API endpoint with enabled set to true. The Logging Service activates for the contract in that region.

Refer to the full schema in the Logging API v1 documentation.

Note: You can also allow Central Logging through the DCD. For more information, see Send Logs to the Platform.

The response returns a resource that includes the grafanaEndpoint URL and the enabled: true property. The grafanaEndpoint value is identical for all customers in that region.

2

Activate the Monitoring Service for the same region

Repeat the activation against the Monitoring API endpoint. The Monitoring Service activates separately from Logging.

Refer to the full schema in the Monitoring API v1 documentation.

Note:

  • Activation is regional. You can activate Logging and Monitoring in every region where MariaDB clusters run. MariaDB v2 is available in nine regions: de-txl, de-fra, fr-par, es-vit, gb-lhr, gb-bhx, us-las, us-mci, and us-ewr. The grafanaEndpoint returned by both services resolves to the same Grafana instance per region, for example https://grafana.logging.de-fra.ionos.com.

  • You can perform activation using the DCD. To do so, refer to the full schema in the Define logging pipeline properties and Send Metrics to the Platform.

3

Allow logs and metrics on a MariaDB cluster

Set logsEnabled and metricsEnabled to true in the cluster properties block. Apply the setting in one of two ways:

  • POST /clusters to create a new cluster with observability activated.

  • PUT /clusters/{clusterId} to update an existing cluster. PUT replaces the entire resource. Include all required fields in the request body, even if you are not changing their values. Any field omitted is set to its schema default or cleared to empty.

No separate activation endpoint exists for the cluster-level toggles.

Each cluster manages logs and metrics independently. Use it to keep test clusters quiet while production clusters stream full telemetry.

4

Verify the activation matrix

Both layers must report true for data to appear in Grafana. The following matrix summarizes every combination.

Logging or Monitoring Service activated

MariaDB cluster logs or metrics activated

Visibility result

true

true

Logs visible, metrics visible

true

false

Not visible

false

true

Not visible

false

false

Not visible

5

Access the Grafana dashboard

1. Open the regional Grafana URL returned by the activation response. The URL follows the pattern https://grafana.logging.{region}.ionos.com, for example:

2. Sign in with your IONOS CLOUD contract user credentials. Administrator users and users with observability access can sign in.

Note: If you have not previously used the observability product, you cannot sign in to Grafana until your permissions propagate.

3. On the left-hand menu, go to Connections > Data sources, then select Drilldown > Metrics and choose the Mimir data source.

Grafana metrics Data Source

4. In Search metric, search for a MariaDB metric name, such as mysql_up, mysql_global_status_threads_connected, mysql_global_status_slow_queries, or mysql_slave_status_seconds_behind_master, to plot it as its own panel. Infrastructure metrics such as node_memory_MemAvailable_bytes and node_disk_io_time_seconds_total are also available from the same data source.

MariaDB cluster health metrics

5. Review the curated metric catalog in Metrics, which lists infrastructure metrics (collected by node_exporter) and database health metrics (sourced from mysqld_exporter), and view the corresponding metrics in Grafana.

6

Configure the following alert rules in Grafana to detect the most common MariaDB failure modes early:

Alert

Threshold

What it indicates

Instance reachability

mysql_up equal to 0

The instance is unreachable; alert immediately.

Connection saturation

mysql_global_status_threads_connected approaching mysql_global_variables_max_connections

Client connections nearing the configured limit; alert before mysql_global_status_aborted_connects starts increasing.

Slow queries

mysql_global_status_slow_queries increasing

Queries exceeding the configured time threshold; alert on any sustained increase.

InnoDB buffer pool efficiency

Rising mysql_global_status_innodb_buffer_pool_reads relative to mysql_global_status_innodb_buffer_pool_read_requests

Increasing disk reads instead of buffer pool hits, indicating an undersized buffer pool.

Replication lag

mysql_slave_status_seconds_behind_master above an acceptable threshold for your workload

A secondary instance falling behind the primary.

Replication thread state

mysql_slave_status_slave_io_running or mysql_slave_status_slave_sql_running equal to 0

A replication thread has stopped; alert immediately.

Available memory

Below 10% of node_memory_MemTotal_bytes

Node-level memory pressure that can affect the instance.

Filesystem free space

Below 15% of node_filesystem_size_bytes

Risk of write failures on data or log volumes.

Disk I/O saturation

rate(node_disk_io_time_seconds_total[5m]) above 0.9

I/O saturation that can affect InnoDB redo log flushing and checkpoint completion.

Example PromQL for the InnoDB buffer pool efficiency alert:

Example PromQL for the available memory alert:

Troubleshooting

No data appears in Grafana after activation

Both layers must report true before data flows. Verify that the contract-level Logging and Monitoring services are active for the region and that the cluster properties block shows logsEnabled: true and metricsEnabled: true. If either layer is false, no data flows regardless of the other layer's state.

API accepts logsEnabled: true but no data flows

This is an expected behaviour. If you set logsEnabled or metricsEnabled to true while the contract-level service is inactive, the API accepts the request without error. Activate the corresponding Logging or Monitoring Service for the region first, then verify that the cluster property is still set to true.

Grafana sign-in fails or shows a permission error

Only administrator users and users who have been explicitly granted access to the observability product can sign in. If you have never previously interacted with the observability product, your permissions may not have propagated yet. Wait a few minutes and try again, or ask your contract administrator to confirm that observability access has been granted.

Activation response does not include a grafanaEndpoint

A missing grafanaEndpoint in the activation response indicates that the request body was malformed or that the service was not activated successfully. Confirm that the request body includes "enabled": true inside a valid properties object and that the Content-Type: application/json header is present. Re-send the request and check the response for an enabled: true field alongside the endpoint URL.

Searching for a metric name returns no results

MariaDB v2 database health metrics use the mysql_ prefix (for example, mysql_up, mysql_global_status_threads_connected). If a metric name returns no results, confirm you are searching for a mysql_-prefixed name. Infrastructure metrics use the node_ prefix.

Conclusion

You configured end-to-end observability for a MariaDB v2 cluster on IONOS CLOUD. The two-layer activation model gives you contract-level control over billing and per-cluster control over telemetry granularity. The curated metric catalog and recommended thresholds provide a starting point for production-grade alerting.

Next steps

Last updated

Was this helpful?