Slide 3 of 6

How Database Observability works

Architecture

Database Observability architecture

How data flows

Database Observability uses Grafana Alloy to collect two types of telemetry from your databases:

SignalWhat it capturesWhere it’s stored
MetricsQuery counts, latency, errors, rows affected, resource usageGrafana Cloud Mimir (Prometheus)
LogsQuery samples, explain plans, schema details, wait eventsGrafana Cloud Loki

Collection sources

The data comes from built-in database statistics, not from intercepting queries:

  • PostgreSQL uses pg_stat_statements for aggregate query statistics and pg_stat_activity for active session information. The pg_stat_statements extension must be installed and enabled.
  • MySQL uses Performance Schema, which is enabled by default in MySQL 8.0+. Query samples are captured from running queries in the performance schema tables.

What Grafana Alloy does

Grafana Alloy runs alongside your database and handles collection:

  1. Database exporters scrape aggregate metrics from pg_stat_statements or Performance Schema and forward them to Grafana Cloud Mimir.
  2. Database Observability components query your database for detailed information (query samples, explain plans, schema details) and forward structured logs to Grafana Cloud Loki.
  3. Purpose-built dashboards in Grafana Cloud correlate these metrics and logs into a unified view of query performance.

Explain plans run EXPLAIN (not EXPLAIN ANALYZE) on sampled queries, so they estimate costs using cached statistics without actually executing the query.

Script

Here’s how all of this works under the hood. Grafana Alloy runs alongside your database and collects two types of telemetry.

First, it collects metrics: query counts, latency, errors, and resource usage. These go to Grafana Cloud Mimir, which is the Prometheus-compatible metrics backend. Second, it collects detailed logs: query samples, explain plans, schema details, and wait events. These go to Grafana Cloud Loki.

The important thing is that this data comes from built-in database statistics, not from intercepting your queries. PostgreSQL uses pg_stat_statements and pg_stat_activity. MySQL uses Performance Schema, which is enabled by default in MySQL 8.0 and later.

One detail worth noting about explain plans: they run EXPLAIN, not EXPLAIN ANALYZE. That means they estimate costs using cached statistics without actually executing the query, so there’s no performance impact on your production database.