Database monitoring from query to service

What is database monitoring?

Database monitoring is the continuous tracking of database health, performance and resource usage, from the server down to individual queries. It covers relational databases such as PostgreSQL, MySQL and SQL Server, NoSQL stores such as MongoDB and Redis, and managed cloud databases. Good database monitoring tells you not only whether a database is up, but which queries are slow, why they are slow and which part of your application is affected.

Databases sit at the center of most systems. Nearly every user request ends in at least one query, and a single inefficient statement can slow down an entire product. That makes the database one of the most valuable places to observe and one of the most common sources of incidents.

Why database monitoring matters

Database problems rarely announce themselves clearly. A missing index after a schema change, a query plan that flips as data grows, a connection pool that runs dry under load or a long-running transaction holding locks can all present as generic application latency. Application teams see slow endpoints, database administrators see busy servers, and nobody sees the connection between the two.

Database monitoring bridges that gap. With query-level data correlated to application traces, developers can see exactly which code path issues a problematic query, and database specialists can see which service and release introduced it. It also supports capacity planning: storage growth, connection trends and replica lag reveal when you need to scale before users feel it.

Key database metrics

The golden signals apply to databases as well: throughput, errors, latency and saturation. In practice, these metrics matter most:

• Query throughput and latency: queries per second and latency percentiles, overall and per normalized statement.
• Slow queries: statements that exceed a duration threshold, with execution counts and rows examined.
• Connections: active and waiting connections compared with configured limits and pool sizes.
• Locks and deadlocks: blocked sessions, lock wait time and deadlock counts.
• Cache efficiency: buffer or cache hit ratio, and for Redis, hit rate and evictions.
• Replication: lag between primary and replicas, which affects read consistency and failover safety.
• Resources: CPU, memory, disk I/O, IOPS and storage consumption.

How Obseria handles database monitoring

Obseria collects database telemetry from three angles. The Obseria Agent and OpenTelemetry Collector receivers read engine metrics and query statistics from self-hosted databases, including those running in Kubernetes. Managed databases on AWS, Azure and Google Cloud are monitored agentless through cloud APIs. And OpenTelemetry instrumentation in your applications records every database call as a span, with the statement, duration and target database as attributes.

Bringing these together is what makes the difference. Obseria TopoGraph shows which services depend on which databases. When an endpoint slows down, you can move from the trace to the slow span, to the normalized query, to the database instance and its lock or I/O metrics, without switching tools. Obseria Intelligence uses this context to explain incidents, for example linking a latency spike to a deployment that introduced a new query pattern. Continuous profiling, with under 1% overhead, adds code-level detail on the application side.

All data is queryable in Obseria Lake with OQL, PromQL or SQL:

fetch spans
| filter db.system == "postgresql"
| summarize count(), p95(duration), by:{db.statement, service.name}

Obseria Pipeline can mask literal values in query text at ingest, so sensitive data in statements does not end up in your telemetry.

Database monitoring best practices

1. Normalize queries. Group statements by structure, not literal values, to see true hot spots.
2. Correlate with deployments. Many query regressions follow a release or schema migration.
3. Alert on saturation early. Connection limits, storage and replica lag deserve warnings well before they are exhausted.
4. Protect sensitive data. Mask parameters in statements and restrict access to query text.
5. Look at percentiles. Averages hide the slow outliers that users actually notice.