Skip to main content

Real-time database monitoring

Database performance problems lead directly to slow applications and service outages, and they immediately affect end-user experience and revenue. This guide walks through how to use WhaTap Database Monitoring to monitor operating status against thresholds in real time and to analyze the root cause when a problem occurs.

Five things to check when designing DB monitoring​

  • Set the goal — Be clear about what to monitor, such as the maximum acceptable query response time or the throughput of a specific job.
  • Choose the metrics — CPU, memory, disk I/O, network, session status, wait events, and so on.
  • Set the interval — Keep it consistent and matched to the DB characteristics and load so that the latest status is always collected.
  • Combine the tools — Built-in DBMS tools, cloud managed services, and third-party solutions. Choose by features, scalability, and convenience.
  • Verify the improvement — Identify the problem from the monitoring results, then monitor again after resolving it to confirm the effect.

Two pillars of WhaTap DB monitoring​

1. Per-second visualization (5-second interval)​

WhaTap collects and visualizes most of the metrics the DB provides at 5-second intervals.

  • Monitor both on-premises DBs and cloud RDS on the same screen, removing blind spots in DB monitoring.
  • Get a real-time alert when a threshold is exceeded so you can respond right away.
  • Observe multiple DB instances together in a single project and a single dashboard.

2. Root cause analysis tools​

Beyond simple metric monitoring, built-in features let you dig into why it got slow.

Table | DB root cause analysis tools
FeatureWhen to use
Active SessionTo see what the sessions currently running on the DB are waiting for
Slow QueryTo review the slow query list, execution plans, and wait events
DB lock trackingTo identify lock holder-waiter relationships and deadlock situations
SQL DetailsTo check the execution history and call site of an individual delayed SQL
SQL StatisticsTo review query frequency and average response trends by time
DB logsTo read the original error and warning logs
Table/DB size changesTo track table size changes for capacity planning
Parameter comparisonTo detect configuration differences between production and staging DBs

Example monitoring scenarios​

When the application suddenly slows down​

  1. Check whether the DB call section is slow in the application transaction trace.
  2. Identify the occupying sessions and wait events in Active Session for that time range.
  3. Find the slow queries in Slow Query, and check their execution plans and wait events.
  4. Cross-check whether a DB lock occurred.
  5. Connect this to your alert rules. For details on the configuration, see Setting the DB metrics alert.

Detecting query performance regression after a deployment​

  1. Compare the average response time of key queries before and after the deployment in SQL Statistics.
  2. If you find a regressed query, check environment changes with parameter comparison.
  3. If necessary, connect this to the one-week trend verification flow in the release verification scenario.

Capacity planning​

  1. Track the monthly growth rate with table/DB size changes.
  2. Include it in your weekly and monthly performance reports. You can connect this to the performance reporting scenario.

Next steps​

Last updated on