Docs/Database monitoring

Database monitoring

Point Status Harbor at your Postgres or MySQL and get four things back: live health with incidents, a graded config audit, a slow-query view and one fitness verdict that answers "is this database configured well enough for the load and data it holds".

The database is reached through a Lighthouse agent already running inside your network, so there is no inbound exposure and no IP-allowlisting - the agent is the only thing that opens a connection to the database. You enter the connection string in the console once; it is stored encrypted at rest and never shown back to the browser.

Postgres and MySQL (plus the forks - MariaDB, Percona, Galera) are supported. Managed cloud endpoints reachable only from the public internet (RDS, Cloud SQL, Aurora) are not covered in this release - the agent has to be able to reach the database from inside the network.

Before you start

You need a Lighthouse agent that can reach the database. If you don't have one yet, install it first - see Lighthouse. The agent runs the introspection; the console holds the metadata, thresholds, the encrypted connection string and the analysis.

Least-privilege setup

Status Harbor never asks for a superuser. Create a read-only monitoring role and grant it exactly the stat views.

Postgres (9.6+, pg_monitor is built in):

CREATE ROLE sh_agent LOGIN PASSWORD '...';
GRANT pg_monitor TO sh_agent;

MySQL / MariaDB:

CREATE USER 'sh_agent'@'%' IDENTIFIED BY '...';
GRANT PROCESS, REPLICATION CLIENT ON *.* TO 'sh_agent'@'%';
GRANT SELECT ON performance_schema.* TO 'sh_agent'@'%';

The console shows these exact grants in the create dialog so you can copy-paste them.

Register a database

A registered entry is a cluster, and a standalone database is just a cluster of one. In the console:

  1. Open Databases and click New Database.
  2. Give it a name, pick the engine and the Lighthouse that can reach it.
  3. Paste one connection string per node (one per line) using the sh_agent role above. The DSN is write-only - it is encrypted at rest and never returned to the browser.

The connection string format depends on the engine:

# Postgres
postgres://sh_agent:[email protected]:5432/app
 
# MySQL / MariaDB
mysql://sh_agent:[email protected]:3306/app

For a cluster, add one line per node - for example the primary and each replica - and the agent reports each node's role back.

The console delivers the connection info to the bound agent on its next heartbeat (~15s). Node identity and role are detected by the agent and matched back to what you declared, so a failover that flips a primary needs no edit - the topology redraws itself.

For the fitness verdict, set each node's deployment kind and sizing (host RAM / cores, or on Kubernetes the pod's memory limit

  • not the node's). Until you do, the verdict reads "pending sizing".

What you get

Live health + incidents. Connections used vs max_connections, cache / buffer-pool hit ratio, deadlocks, long-running transactions, transaction-wraparound headroom (Postgres), and - for clusters - replication lag, primary election (no primary is an outage, two is split-brain) and failover readiness. A breach raises an incident through the same pipeline your monitors use, so it notifies exactly like a monitor-down incident on the channels your plan already has. Warnings fire only on a sustained breach so a lunch-rush spike does not page.

Config audit (graded). A rules engine scores each node's settings against its RAM and cores and produces graded findings - shared_buffers too low for the RAM, innodb_buffer_pool_size, random_page_cost on SSD, config drift across nodes, and the Kubernetes cgroup footgun (a database tuned as if it owns a 128GB node but capped at a 4GB pod limit will be OOMKilled under load). Durability risks (fsync=off, synchronous_commit=off, innodb_flush_log_at_trx_commit in 2) are flagged critical. Prescriptive findings carry the exact remediation SQL to copy-paste - you run it yourself, Status Harbor never writes to your database.

Slow queries (on-demand). The slowest normalized queries ranked by total and mean time, with calls, p95 and rows. Because the pg_stat_statements scan is the most invasive query, collection is on-demand: click Live update on the Slow Queries tab to collect while you watch (3, 5 or 10 minutes), then it stops on its own. Postgres needs pg_stat_statements in shared_preload_libraries; MySQL needs performance_schema on. The tab shows the copy-paste steps when a prerequisite is missing.

Fitness verdict. Pillars 1-3 roll up into one headline - "Adequate", "Under-provisioned: 3 findings" or "At risk: no synchronous standby" - the answer to "is my config enough for the load and data".

Clusters

Register a cluster as a list of node connection strings. Supported topologies: standalone, Postgres streaming replication (primary + hot standbys), MySQL / MariaDB async primary-replica, and multi-writer (Galera / MySQL group). Each node is collected and evaluated on its own, with a cluster rollup for topology integrity, replication health and config drift on top.

What is stored

Introspection ships normalized facts - counts, ratios, lag seconds

  • never raw row dumps and never the query results. Health snapshots are kept in Postgres with short bounded retention (7 days of state history, latest-only for parameters and slow queries). There are no new time-series metrics.

Plans

Database monitoring is a plan feature, capped by the number of databases on your plan. See Plans & limits. The gate honours a trial: while you are trialing a plan, that plan's database allowance applies.