Operations, Security & Reliability
Database Observability
Database observability connects user-visible workload and latency to transactions, waits, plans, replication, recovery, and host resources while controlling metric cardinality and protecting sensitive query data.
- Start from service outcomes.
- Saturation is a queue, not just high CPU.
- Waits explain where elapsed time goes.
- Query fingerprints need plan and data context.
- Protection systems are part of health.
- Telemetry has cost and privacy boundaries.
| Layer | Signals | Diagnostic join key |
|---|---|---|
| Service/workload | rate, errors, latency percentiles, freshness | operation + request/trace ID |
| Admission/session | pool wait, connections, state, transaction age | service + session/application name |
| Query/transaction | fingerprint, calls, rows, elapsed, errors, plans | fingerprint + transaction/request ID |
| Contention | wait class/event, blocker chain, deadlocks | session/transaction/resource |
| Resources | CPU/run queue, memory, cache, IOPS/latency, network | instance + time |
| Data/maintenance | growth, dead versions, stats age, bloat, jobs | database/object + time |
| Protection | backup/restore, archive, replication lag/conflict, audit export | instance/stream + timeline |
symptom: checkout p99 and order-create p99 exceed objective for 10 min
impact: affected operations, regions, tenants (bounded categories), error budget burn
corroboration: DB active/waiting, wait classes, storage latency, lock graph
context: deploy/schema/config/failover events within 60 min
runbook: safe evidence query, containment options, owner, escalation
auto-close: sustained recovery plus backlog drained
Do not alert on a single internal metric without an actionable hypothesis.