As for alerting on LOCK_log waits, the instrumentation is available for all of that in performance_schema in 5.5 which a) monitors LOCK_log (mutex) waits down to picosecond resolution and b) monitors all threads, including connected slave IO threads.

Something like this would give the same kind of info (less the full stack of course) as PMP:

SELECT IF(pps.name = ‘thread/sql/one_connection’,
CONCAT(ips.user, ‘@’, ips.host),
REPLACE(name, ‘thread/’, ”)) user,
db,
command,
state,
time,
event_name AS last_wait,
IF(timer_wait IS NULL,
‘Still Waiting’,
timer_wait/1000000) last_wait_usec,
source
FROM performance_schema.events_waits_current
JOIN performance_schema.threads pps USING (thread_id)
LEFT JOIN information_schema.processlist ips ON pps.processlist_id = ips.id;

An example with a normal thread and slave IO thread:

*************************** 9. row ***************************
user: msandbox@localhost
db: NULL
command: Query
state: executing
time: 0
last_wait: wait/io/file/myisam/dfile
last_wait_usec: 19.4230
source: mi_dynrec.c:258
*************************** 10. row ***************************
user: msandbox@localhost:54550
db: NULL
command: Binlog Dump
state: Master has sent all binlog to slave; waiting for binlog to be up
time: 983
last_wait: wait/synch/cond/sql/MYSQL_BIN_LOG::update_cond
last_wait_usec: Still Waiting
source: log.cc:5533

You would just see a pile up on the “wait/synch/mutex/sql/LOG::LOCK_log” event for threads “Still Waiting”.

I don’t think there is enough instrumentation to alert on this. The best general-purpose way I can think of is to look at the relay log position on replicas and compare it to the current log and position on the master.

The binlog cache hit rate I’m referring to is computed from SHOW GLOBAL STATUS as Binlog_cache_disk_use/Binlog_cache_use. I’ve never seen a case where that was a useful diagnostic, much less useful to alert on. Binlog_cache_disk_use per second could be something useful to compute manually if troubleshooting points to that as a source of problems, but it’s not something I’d bake into a monitoring tool a priori. I should note that my opinions on this have changed. I built Binlog_cache_disk_use/Binlog_cache_use into innotop three or four years ago. But that was a younger me, who also thought that the MyISAM key cache hit rate was important. I can only plead that I’ve learned better ways by spending time doing things that didn’t really produce results.