Skip to content
ProductDatabases

Monitor what your database knows.

Replication lag, queue depth, pending order counts: the signals that live inside your database, surfaced as status without exporters or sidecars.

DatabaseQueryMetricread-onlytimeout 5s12234758threshold 50OperationalDegraded
One query, one number, plotted against its threshold. Cross the line and the verdict follows.

The most honest signal is often a number your database already holds. Observer reads it with a plain read-only query. No postgres_exporter, no redis_exporter, no sidecar to deploy and keep alive: just a read on a schedule, and the result on your status page.

Sources

Four engines, one number.

Postgres, MySQL, Redis, and MongoDB. Each one speaks differently; each one returns a single number Observer can read.

PostgreSQL
Anything a SELECT can reach: pg_stat_replication, pg_stat_activity, or a count in one of your own tables.
MySQL
Seconds_Behind_Master, connection counts, or a business figure straight out of a row. No mysqld_exporter in between.
Redis
A read-only command allowlist: DBSIZE, LLEN, SCARD, TTL, EXISTS. Queue depth and key counts, no redis_exporter.
MongoDB
countDocuments and estimatedDocumentCount with a filter. A pending-document count straight from a collection.
How it works

A credential, a query, a schedule.

Setup is three things you already know how to do. The safeguards are the part you do not have to think about.

  1. 01

    Create a read-only credential

    Grant the agent access that can read and nothing else. The boundary is enforced by your database, not by trust.

  2. 02

    Write a single-value query

    One number out. A SQL SELECT, a Redis read command, or a Mongo count: whatever the database already knows.

  3. 03

    The agent runs it on schedule

    Every 10 seconds to 5 minutes, you choose. The query runs inside your network; only the result leaves.

  4. 04

    The value drives status

    Same threshold, dwell, SLO and incident logic as any other metric. A database signal is just a metric downstream.

  5. 05

    Safeguards hold the line

    Statement timeouts, read-only command checks, and capped pools keep a bad query from ever becoming your problem.

Safeguards

Pointed at production, by design.

A monitoring tool with database credentials has to earn that trust. Five guarantees, none of them optional.

  • Read-only access, enforced at the credential level.
  • Statement timeout: 5 seconds by default, 30 maximum.
  • Reads only. SQL is parsed SELECT-only, Redis runs a read-command allowlist, Mongo is limited to counts.
  • The query returns exactly one number, nothing larger.
  • Connection pool capped per source, so probes never starve the database.
In practice

The figures worth paging on.

A few of the queries teams point at Observer, and what each one tells them.

  • Postgres replication lag from pg_stat_replication, surfaced before a read replica falls too far behind.

  • MySQL Seconds_Behind_Master crossing its limit flips the page and drafts an incident.

  • A Redis list length tracks job-queue depth, warning before workers fall behind.

  • A MongoDB pending-document count reads as a business-level health signal straight from a collection.

  • Connection pool headroom approaching exhaustion warns while there is still time to act.

  • Long-running query count climbing is an early sign of a database under strain.