Platform · Monitoring & Observability

Every instance, every layer, one timeline.

A signed Go agent on each database host collects engine telemetry and host metrics together. When a slow database turns out to be a saturated disk, you can tell in one place instead of two tools.

View Alerting & Incidents See Query Analytics

Step one

Fleet visibility — the estate before the instance

Monitoring opens on what needs attention across every engine you run, not on a list of hostnames. The instance view is where you go second.

schemapulse — fleet overviewexample data

Instances48

Open incidents2

Verified backups46

Recovery at risk1

Healthyorders-galera-0Galera · primary

Healthyorders-galera-1Galera · synced

Lag 4.2sbilling-rs-2Replica set · secondary

Healthyanalytics-pg-0PostgreSQL · primary

Unverifiedreporting-mssql-1SQL Server · standalone

Fig. 1The fleet overview. One instance here is flagged not because it is down, but because its backup has never been verified — a state a metrics dashboard has no way to know about.

Step two

Database metrics — what the engine is doing

schemapulse — orders-galera-0 — database & system metricslast 6h · example data

Database metrics

Queries/sec4,812

Connections186

Buffer pool hit94.1%

Replica lag4.2s

Host metrics

HostCPUMemoryDiskTHP

orders-galera-062%71%44%Disabled

orders-galera-158%69%43%Disabled

billing-rs-281%88%76%Enabled

Fig. 2Engine telemetry and host metrics on the same screen and the same clock. The buffer pool figure and the replica lag figure are the two that moved during the incident on the homepage.

Throughput: Queries and operations per second, reads against writes, per instance.
Connections: Active, idle and rejected, against the configured limit — the first thing to check when an application reports timeouts.
Buffer & cache: Buffer pool and cache hit rates, page churn. A falling hit rate is usually the earliest warning of a working-set problem.
Locks & waits: Lock waits, deadlocks and contention, so a stall is attributable rather than mysterious.
Replication: Lag, applier state and error conditions per replica, tracked as a series rather than a current value.
Storage: Data and index size per database, and growth rate — read alongside backup duration and retention.

Step three

Host metrics — what is underneath it

Most incidents reported as “the database is slow” turn out to be the host. Collecting host telemetry through the same agent, on the same timeline as the engine, is what makes that distinction take seconds rather than a second tool.

CPU: Utilisation against the host's core count, so a figure means the same thing on a 4-core and a 64-core machine.
Memory: Used against total RAM, tracked over time — read alongside what the engine is configured to take rather than in isolation.
Disk: Used against capacity, with growth rate. This is the number that decides whether a retention change is safe.
Uptime: Host uptime and database uptime tracked separately. A database that restarted while the host did not is a different incident from one where both did.
Connections: Server-level connection count, which is often the first thing to move when an application misbehaves.

Host configuration that affects the database

This is the part generic infrastructure monitoring does not do. A host can look completely healthy on CPU and memory while a setting on it is the reason your database is slow.

Transparent huge pages: THP left enabled is one of the most common causes of unexplained latency spikes on a database host. SchemaPulse reports its state per host rather than assuming provisioning got it right.
Swappiness: The kernel's willingness to swap, recorded per host. A database swapping its buffer pool is a performance cliff, not a gradient.
Time sync: Clock drift breaks replication ordering and makes cross-host investigation unreliable. Flagged when detected.
TCP keepalive: Reported per host — its absence produces connection failures that look like database problems and are not.
SELinux and firewall: State recorded per host, so a difference between two supposedly identical nodes is visible before it causes an incident.
Platform and kernel: OS, version, architecture and kernel per host — the drift that explains why one replica behaves differently.

Step four

Query visibility — which statement is responsible

Metrics tell you the instance is working hard. Query analytics tells you what it is working on. A digest links to the instance it ran on, the incident it contributed to, and the deployment that changed its plan.

View Query Analytics

Step five

Topology awareness — which node, and what role

fleet — topologyexample data

Fig. 3Roles and state per engine, with elections recorded as history. When someone asks why writes moved at 02:14, the answer is a record rather than an inference from logs.

Step six

Historical investigation — what changed

Retention you set: Metrics land in InfluxDB inside your environment. How long they are kept is your decision, not a plan tier.
Aligned timelines: Database, host, query and topology events share one clock, so "what changed at 02:14" is one question rather than four.
Events, not snapshots: Elections, membership changes, deployments and maintenance windows are recorded as points on that timeline.
Per-instance baselines: Normal for a reporting replica is not normal for a write primary. Trends are judged against the instance.

The agent

What is actually installed

One binary per host: A Go agent with a signed, verified identity and its own configuration. Installed during provisioning, or added to an existing host with a single command served by the control plane.
Reports inward: The agent talks to your control plane. Metrics land in InfluxDB and metadata in PostgreSQL, both inside your environment.
Front ends too: MySQL Router and mongos are their own failure domain, so reachability is probed for those as well as the data-bearing nodes.
Removable: Offboarding is a cleanup script served by the same control plane. Nothing is left behind on the host.

Collection interval and agent resource footprint are confirmed per deployment — ask before you install anything on a production host.