| 2014-08-14 18:23:04 |
Mikhail Solovyev |
description |
[root@cron01 ~]# mysql -umailboxer -pmailboxer -hzabbixdb01 -e "show slave status\G"
[root@cron01 ~]# /usr/lib64/nagios/plugins/pmp-check-mysql-replication-delay -H zabbixdb01 -l mailboxer -p mailboxer -P 3306 -w 3600 -c 7200
OK 0 seconds of replication delay | replication_delay=0;3600;7200;0;
It seems to be logical to return UNKNOWN in such case, isn't it?
We discussed this with Jay Janssen in #44493
He said:
Firstly, it’s intended that you use pmp-check-mysql-replication-running to test if replication is up or down, and not just the replication-delay check. (I did not design these tools, but that’s the intention).
As far as your specific problem, I do think it is supposed to return UNKNOWN in that case, so it may be a bug. I found a similar report from a few years ago that should have been fixed: https://bugs.launchpad.net/percona-monitoring-plugins/+bug/1040528 |
[root@cron01 ~]# mysql ... -e "show slave status\G"
[root@cron01 ~]# /usr/lib64/nagios/plugins/pmp-check-mysql-replication-delay ... -w 3600 -c 7200
OK 0 seconds of replication delay | replication_delay=0;3600;7200;0;
It seems to be logical to return UNKNOWN in such case, isn't it?
We discussed this with Jay Janssen in #44493
He said:
Firstly, it’s intended that you use pmp-check-mysql-replication-running to test if replication is up or down, and not just the replication-delay check. (I did not design these tools, but that’s the intention).
As far as your specific problem, I do think it is supposed to return UNKNOWN in that case, so it may be a bug. I found a similar report from a few years ago that should have been fixed: https://bugs.launchpad.net/percona-monitoring-plugins/+bug/1040528 |
|
