How do I monitor databases and application dependencies?

To monitor databases and application dependencies effectively, you want observability across performance, availability, latency, errors, and dependency health. A good setup usually combines metrics, logs, traces, and synthetic checks.

1) Monitor the database itself

Track core database health indicators:

• Availability / uptime
• Query latency: average, p95, p99
• Throughput: queries/sec, transactions/sec
• Error rate: failed queries, timeouts, deadlocks
• Resource usage:
  • CPU
  • memory
  • disk I/O
  • storage utilization
  • connection count / pool saturation
• Replication status:
  • replication lag
  • failover state
  • read replica health
• Locks and contention:
  • long-running queries
  • lock waits
  • deadlocks
• Cache efficiency:
  • buffer cache hit ratio
  • page reads vs cache hits

Database monitoring tools

Depending on your database, you can use:

• PostgreSQL: pg_stat_statements, pg_stat_activity, exporter + Prometheus/Grafana
• MySQL/MariaDB: Performance Schema, slow query log, exporter
• SQL Server: Query Store, DMVs, Extended Events
• MongoDB: serverStatus, profiler, Atlas monitoring
• Cloud DBs:
  • AWS CloudWatch / RDS Performance Insights
  • Azure Monitor / Azure Database Insights
  • GCP Cloud Monitoring / Cloud SQL insights

2) Monitor application dependencies

Dependencies include:

• databases
• caches
• message brokers
• APIs
• third-party services
• file/object storage
• authentication providers

For each dependency, monitor:

• Latency
• Availability
• Success/error rate
• Timeouts
• Retry rate
• Rate limiting / throttling
• Saturation (connections, queue depth, threads, etc.)

3) Use distributed tracing

Tracing is especially useful for understanding how dependencies affect end-to-end requests.

With tracing, you can see:

• which database queries slow down a request
• which external API causes a bottleneck
• where retries or failures happen
• total request time broken down by dependency

Typical tools:

• OpenTelemetry
• Jaeger
• Zipkin
• Grafana Tempo
• commercial APMs like Datadog, New Relic, Dynatrace

4) Centralize logs

Logs help explain why something failed:

• DB connection failures
• deadlocks
• timeout exceptions
• dependency response codes
• circuit breaker trips
• retries exhausted

Best practice:

• include a correlation/request ID
• log dependency name, latency, status, and error reason
• avoid logging sensitive data

5) Set alerts on symptoms, not just causes

Good alert examples:

• DB CPU > 80% for 10 min
• p95 query latency above threshold
• connection pool exhaustion
• replication lag > X seconds
• external API error rate > 5%
• queue depth growing continuously
• application request latency increasing with dependency timeouts

Avoid too many alerts based only on raw metrics; tie them to user impact when possible.

6) Create service-level indicators (SLIs)

Useful SLIs:

• request success rate
• end-to-end latency
• dependency success rate
• database query latency
• time spent waiting on dependencies

Then define SLOs, such as:

• 99.9% of requests under 300 ms
• 99.5% of DB queries under 50 ms
• 99.9% of dependency calls succeed without retry exhaustion

7) Use synthetic checks

Synthetic monitoring runs test transactions continuously:

• connect to DB
• run a lightweight query
• call a third-party API
• verify login flow or checkout flow

This helps detect issues even when traffic is low.

8) Watch connection pools and queues

Many app issues come from resource exhaustion rather than the database query itself:

• DB connection pool maxed out
• thread pools saturated
• queue backlog increasing
• retry storms
• circuit breaker open too often

These are often leading indicators before a full outage.

9) A simple monitoring stack

A common open-source stack:

• Prometheus for metrics
• Grafana for dashboards
• Alertmanager for alerts
• OpenTelemetry for tracing and metrics
• Loki/ELK/Opensearch for logs

Commercial alternatives:

• Datadog
• New Relic
• Dynatrace
• Splunk Observability

10) What a good dashboard should show

For each database/dependency:

• health status
• latency percentiles
• error rate
• throughput
• saturation/utilization
• recent incidents and alerts
• top slow queries or failing endpoints

---

If you want, I can also give you:

1. a sample monitoring checklist,
2. a Prometheus/Grafana setup, or
3. a database + dependency monitoring design for PostgreSQL, MySQL, or a cloud app.