Отрицательная длительность в "Проблемах"

[DSV12]

Сегодня вижу странное: сработал триггер, у которого длительность существования проблемы показывается как отрицательная: -2сек.

Проблема создана: 26.12.2018 09:17:24
Проблема решена: 26.12.2018 09:17:22

Это как? Со временем и синхронизацией всё в порядке (более того, хост, на котором возникала проблема, сам является ntpd-сервером).

Zabbix-сервер v4.0.3, хост с отрицательным временем - FreeBSD 11.1-RELEASE-p11, zabbix_agentd (daemon) (Zabbix) 3.4.8.

[astrix89]

https://www.zabbix.com/documentation/4.0/ru/manual/web_interface/frontend_sections/monitoring/problems#отрицательная_длительность_проблемы

[DSV12]

https://www.zabbix.com/documentation...роблемы

Описанные в документации варианты возникновения отрицательной длительности проблемы не подходят к моему случаю. Упрощённое выражение проблемы (в реале у меня разные пороги для рабочего и нерабочего времени):

{Template BIND:bind.stats.query[SERVFAIL].avg(5m)}>={$BIND_SERVFAIL_MAX} Тип: Zabbix агент (активный)

Интервал обновления 1m, триггер срабатывает, если среднее за 5мин >= порога. Как тут может -2 секунды появиться - не понимаю.

Может это и не относится к этой странности, но, полазив по "Проблемам", обнаружил, что сегодня же, в районе 3 ночи (точное время 03:06:50, сработало на всех узлах в одну и ту же секунду, так что проблемы, скорее всего, были со стороны сервера) у меня была массовая проблема практически на всех узлах, включая сам Zabbix сервер: "Zabbix agent on Zabbix server is unreachable for 5 minutes", и при этом почти у всех проблем (но НЕ у всех!) "Длительность" отрицательная, порядка 4 - 5 мин! Что за чудеса?

[astrix89]

NVPS и history write cache при этом проседали? Прокси использутете?

[DSV12]

NVPS и history write cache при этом проседали? Прокси использутете?

Ответ на оба вопроса - нет. Не проседали, прокси не использую.

UPD: просто для справки, может кому пригодится: чаще всего BIND мониторят или используя утилиту rndc или, более предпочтительный вариант, используя statistics-channels, снимая данные в формате xml. Начиная с версии BIND 9.10 формат xml оставлен только версии 3 (это внутренняя версия xml-формата статистики bind-а). Под эти варианты можно найти хорошего качества готовые подборки конфигов/скриптов/шаблонов, н-р, Zabbix-Bind9-Statistics-Collection. Но как-то совершенно незамеченной осталась возможность снимать статистику с BIND-а в JSON-формате. Мне не попадался ни один пример, использующий этот формат, я и сам узнал об этом случайно, ткнувшись в документацию по BIND-у: https://ftp.isc.org/isc/bind9/9.12.2...stics_channels

Может кому-то эта информация окажется полезной и человек сваяет новую версию Zabbix-BIND9 Statistics Collection, используя JSON-формат статистики.

[DSV12]

Может это и не относится к этой странности, но, полазив по "Проблемам", обнаружил, что сегодня же, в районе 3 ночи (точное время 03:06:50, сработало на всех узлах в одну и ту же секунду, так что проблемы, скорее всего, были со стороны сервера) у меня была массовая проблема практически на всех узлах, включая сам Zabbix сервер: "Zabbix agent on Zabbix server is unreachable for 5 minutes", и при этом почти у всех проблем (но НЕ у всех!) "Длительность" отрицательная, порядка 4 - 5 мин! Что за чудеса?

Так, с "Zabbix agent on ... is unreachable for 5 minutes" в 03:06:50 кое-что прояснилось:

[root@zabbix backups]# crontab -l
0 3 * * 3,6 /root/backups/backup-db.sh
[root@zabbix backups]# cat backup-db.sh
#!/bin/bash
now=$(date +"%d-%m-%Y-%H-%M")
mysqldump -u root zabbix | gzip -9 > /root/backups/mysql/zabbix-bak-$now.sql.gz
[root@zabbix backups]#

Судя по тому, что

[root@zabbix backups]# time mysqldump -u root zabbix > 1.dmp

real    0m59.235s - дамп работает почти точно одну минуту
user    0m18.589s
sys     0m4.066s

а проблемы возникают позже, в 03:06:50, виноват в "Zabbix agent on ... is unreachable" 'gzip -9'. Мда, хорошая многозадачность у centos 7 А ведь

cat /proc/cpuinfo | grep -E 'processor|model name'
processor       : 0
model name      : Intel(R) Xeon(R) CPU           E5440  @ 2.83GHz
processor       : 1
model name      : Intel(R) Xeon(R) CPU           E5440  @ 2.83GHz
processor       : 2
model name      : Intel(R) Xeon(R) CPU           E5440  @ 2.83GHz
processor       : 3
model name      : Intel(R) Xeon(R) CPU           E5440  @ 2.83GHz

не совсем ведь слабенько. Диски - 1Tb, зеркало (mdadm), iostat проблем с производительностью не выявил. Ладно, сделаю дефолтные '-6' для gzip-а или приоритет ему понижу, посмотрим, будут агенты отваливаться или нет. Кстати, 'time cat 1.dmp | gzip -9 > 9.gz' выдал 'real 6m50.984s'. Точно оно...

UPD: От же...

time cat 1.dmp | gzip -6 > 6.gz

real    1m30.587s
user    1m28.989s
sys     0m1.875s

ls -lah *.gz
-rw-r--r-- 1 root root 295M Dec 26 16:38 6.gz
-rw-r--r-- 1 root root 293M Dec 26 16:30 9.gz

И зачем я этот '-9' использовал

[kulpin]

У меня подобная проблема, обсуждали в посте https://www.zabbix.com/forum/in-russ...решения