Engines and coverages

You choose what to monitor for a database as a set of coverages. This page lists the engines the agent monitors and the coverages available for each.

Coverage types

• Standard metrics: the database’s health and capacity metrics, such as connections, cache hit ratio, replication lag, buffers, and table and index statistics. You can collect a basic set or a full set.
• Query performance: statistics for the most expensive queries across all clients, so you can find slow and heavy queries.
• Locks: lock and blocking information.
• Query logs: query activity captured as log records.
• Server and slow logs: the database’s own log entries, including slow queries.

Engine and coverage matrix

Engine	Standard metrics	Query performance	Locks	Query logs	Logs
PostgreSQL	Yes	Yes	Yes	No	Server logs
MySQL	Yes	Yes	No	No	Slow log
SQL Server	Yes	Yes	No	Yes	No
Oracle	Yes	Yes	No	Yes	No
MongoDB	Yes	No	No	No	No
MongoDB Atlas	Yes	No	No	No	No
Redis	Yes	No	No	No	No
Elasticsearch	Yes	No	No	No	No
ClickHouse	Yes	No	No	No	No
SAP HANA	Yes	No	No	No	No
Snowflake	Yes	Yes	No	No	No

Note

Database log coverages are available on a virtual machine. On Kubernetes, the agent collects database metrics and query coverages. See Database monitoring on Kubernetes.

Setup steps

Some coverages need a one-time setup step on the database. The wizard shows you the step when you select that coverage. For example:

• PostgreSQL query performance needs the pg_stat_statements extension enabled, which needs a PostgreSQL restart.
• Query performance and query-log coverages need the monitoring user to have the right grants, such as GRANT pg_monitor on PostgreSQL or the equivalent view permissions on SQL Server and Oracle.
• Log coverages may need a log setting turned on, such as the MySQL slow query log.

If a prerequisite is missing, the agent reports it and the other coverages keep working.

Keep a postgres database on managed PostgreSQL

The agent connects to the database named postgres to read server-wide statistics and query performance. These statistics cover every database on the server, so the data you see still comes from your application databases.

Managed services such as Amazon RDS, Aurora, Cloud SQL, and Azure Database for PostgreSQL usually create postgres for you. If it was dropped, or the instance only has an application database, the agent logs pq: database "postgres" does not exist (3D000) and query performance and some metrics panels stay empty.

To fix it, connect as an administrator and create an empty postgres database with pg_stat_statements in it:

CREATE DATABASE postgres;
\c postgres
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
GRANT CONNECT ON DATABASE postgres TO kmmonitor;

Replace kmmonitor with your monitoring user. KloudMate doesn’t write anything to this database. You don’t need to restart the agent; data appears on the next collection.

Filtering database logs

Database logs carry a km.db.coverage attribute set to the coverage they came from, such as query-performance, server-logs, or slow-log. You can filter database logs by this attribute in Log Explorer.

Next steps

On a VM Set up monitoring on a Linux or Windows host.

On Kubernetes Set up monitoring for in-cluster databases.

Credentials Provide the monitoring user's credentials.