A whole class of slowness — row locks, advisory locks, schema-mod locks, lock chains — doesn't spike CPU. The agent polls pg_stat_activity every 5 minutes for sessions stuck in any wait state more than 5 seconds, with the blocking PIDs included.
A query waiting on a row lock burns no CPU and no I/O. Every threshold you have stays green while the application stalls.
The session blocking everything is often idle in transaction — doing nothing, holding everything. You need it named.
Three sessions deep, the one at the front is the only one worth killing.
pg_stat_activity on Postgres, INNODB_TRX on MySQL.Waiting sessions are read continuously — they consume no CPU, so nothing else you monitor will surface them.
The chain is followed to the session actually holding the lock, which is very often idle in a transaction.
A wait of a few milliseconds is normal operation. A wait measured in seconds is the thing worth a notification.
engine column. The agent's INNODB_TRX collector is on the next batch.pg_cancel_backend / pg_terminate_backend) is on the next round. V1 is read-only.DB Lock-Wait Monitor included from Starter. Postgres in V1, MySQL on the next round.