installation details:
zabbix server 3.4 + mysql(mariadb) with partitioning (on the same server CentOS7)
zabbix proxy 3.4 + mysql(mariadb)
mysql Ver 15.1 Distrib 10.1.32-MariaDB
zabbix_server (Zabbix) 3.4.8
Issue:
After disbling one single trigger in the template an escalator process gets busy 100% and DISK I/O load severely increases
As result no notifications being sent out, overall server performance degrades
Described symptoms stay even after reloading the VM, zabbix-server, mariadb services
Inscreasing a number of the escalator processes on the config file does not change the situation
The trigger is for a standard item - system.uptime (agent check)
The template has been applied for some months already to about ~100 windows servers)
For testing purposes some similar triggers were disabled from the template with no problem
The issue showed up for the fisrt time on 3.2 version. Upgarding zabbix to 3.4 and mariadb to the latest release did not change a thing
Zabbix bug? corrupted data?
any thoughts and suggestions would be much appreciated
some debug(5) logs
8231:20180411:175451.559 End of check_escalation():cancel error:'trigger "{HOST.NAME} uptime > 30 days" disabled.'
8231:20180411:175707.760 In check_escalation() escalationid:594427 status:sleep
8231:20180411:175707.761 End of check_escalation():cancel error:'trigger "{HOST.NAME} uptime > 30 days" disabled.'
8232:20180411:180300.425 In check_escalation() escalationid:366904 status:sleep
8232:20180411:180300.429 End of check_escalation():cancel error:'trigger "{HOST.NAME} uptime > 30 days" disabled.'
8230:20180411:180307.547 In check_escalation() escalationid:550077 status:sleep
8230:20180411:180307.551 End of check_escalation()
rocess error:''
8230:20180411:180307.555 In check_escalation() escalationid:581580 status:sleep
8230:20180411:180307.559 End of check_escalation():cancel error:'trigger "{HOST.NAME} uptime > 30 days" disabled.'
8229:20180411:180311.591 In check_escalation() escalationid:613754 status:active
8229:20180411:180311.594 End of check_escalation()rocess error:''
8229:20180411:180313.277 In check_escalation() escalationid:613767 status:active
8229:20180411:180313.280 End of check_escalation()rocess error:''
8229:20180411:180314.397 In check_escalation() escalationid:613777 status:active
8229:20180411:180314.401 End of check_escalation()rocess error:''
8229:20180411:180315.622 In check_escalation() escalationid:534119 status:sleep
8229:20180411:180315.625 End of check_escalation():cancel error:'trigger "{HOST.NAME} uptime > 30 days" disabled.'
8233:20180411:180320.184 In check_escalation() escalationid:393636 status:sleep
8233:20180411:180320.188 End of check_escalation():cancel error:'trigger "{HOST.NAME} uptime > 30 days" disabled.'
zabbix server 3.4 + mysql(mariadb) with partitioning (on the same server CentOS7)
zabbix proxy 3.4 + mysql(mariadb)
mysql Ver 15.1 Distrib 10.1.32-MariaDB
zabbix_server (Zabbix) 3.4.8
Issue:
After disbling one single trigger in the template an escalator process gets busy 100% and DISK I/O load severely increases
As result no notifications being sent out, overall server performance degrades
Described symptoms stay even after reloading the VM, zabbix-server, mariadb services
Inscreasing a number of the escalator processes on the config file does not change the situation
The trigger is for a standard item - system.uptime (agent check)
The template has been applied for some months already to about ~100 windows servers)
For testing purposes some similar triggers were disabled from the template with no problem
The issue showed up for the fisrt time on 3.2 version. Upgarding zabbix to 3.4 and mariadb to the latest release did not change a thing
Zabbix bug? corrupted data?
any thoughts and suggestions would be much appreciated
some debug(5) logs
8231:20180411:175451.559 End of check_escalation():cancel error:'trigger "{HOST.NAME} uptime > 30 days" disabled.'
8231:20180411:175707.760 In check_escalation() escalationid:594427 status:sleep
8231:20180411:175707.761 End of check_escalation():cancel error:'trigger "{HOST.NAME} uptime > 30 days" disabled.'
8232:20180411:180300.425 In check_escalation() escalationid:366904 status:sleep
8232:20180411:180300.429 End of check_escalation():cancel error:'trigger "{HOST.NAME} uptime > 30 days" disabled.'
8230:20180411:180307.547 In check_escalation() escalationid:550077 status:sleep
8230:20180411:180307.551 End of check_escalation()
rocess error:''8230:20180411:180307.555 In check_escalation() escalationid:581580 status:sleep
8230:20180411:180307.559 End of check_escalation():cancel error:'trigger "{HOST.NAME} uptime > 30 days" disabled.'
8229:20180411:180311.591 In check_escalation() escalationid:613754 status:active
8229:20180411:180311.594 End of check_escalation()
rocess error:''8229:20180411:180313.277 In check_escalation() escalationid:613767 status:active
8229:20180411:180313.280 End of check_escalation()
rocess error:''8229:20180411:180314.397 In check_escalation() escalationid:613777 status:active
8229:20180411:180314.401 End of check_escalation()
rocess error:''8229:20180411:180315.622 In check_escalation() escalationid:534119 status:sleep
8229:20180411:180315.625 End of check_escalation():cancel error:'trigger "{HOST.NAME} uptime > 30 days" disabled.'
8233:20180411:180320.184 In check_escalation() escalationid:393636 status:sleep
8233:20180411:180320.188 End of check_escalation():cancel error:'trigger "{HOST.NAME} uptime > 30 days" disabled.'
Comment