#linux #triggers #centos #zabbix #agent
#linux #триггеры #centos #zabbix #агент
Вопрос:
У меня zabbix версии 3.4. у меня есть 2 шаблона. один для мониторинга ОС, а другой для мониторинга баз данных. у меня есть несколько серверов с CentOS 6.9, добавленных в эти шаблоны. все работает просто отлично.
затем я добавил 4 сервера к этим шаблонам с помощью CentOS 7. items работает правильно. у них ожидаемые результаты. проблема в том, что когда триггер активируется для этих 4 серверов, они не разрешаются и остаются активными, и мы видим их на панели мониторинга.
например, в шаблоне базы данных у нас есть элемент, который относится к состоянию обслуживания. если это 1 так, это означает, что служба запущена, если это что-то другое, 1 это означает, что служба не запущена. я остановил службу на одном из этих серверов CentOS 7. полученный агентом результат был равен 0. триггер был активирован. затем я запустил службу. в последних данных я вижу, что значение 1 означает, что служба запущена, но триггер не разрешен, и он все еще работает.
затем я выполнил вышеуказанные шаги для одного из серверов CentOS 6.9, и все работает просто отлично.
почему это происходит и как я могу это исправить?
Обновление: выражение триггера:
{log-b:db2stat.db2instance_service[].last()}<>1
Комментарии:
1. не могли бы вы также поделиться своим выражением триггера?
2. кроме того, вам следует рассмотреть возможность обновления до Zabbix 5
3. сервис @IronBishop не для нашей команды. мы только используем его. я должен сказать другой команде, чтобы посмотреть, что они могут сделать.
4. триггер прост, реагирует на .last() . Я согласен с @IronBishop, вам следует попросить владельца сервиса перейти на более свежую версию.
5. Обновление до zabbix 5 на CentOS 7 с помощью puppet будет сложной задачей с учетом PHP 7.
Ответ №1:
Короче говоря: возможно, проверьте журналы базы данных, если некоторые вставки / обновления не завершаются сбоем (особенно в таблицах event_recovery и проблем)
Короткая история: мы наблюдаем аналогичное поведение на ZBX 4.4 и только с определенными триггерами, проверяющими последние 10 минут данных (например, item_key.str(‘problem’,10m) = 1 ). Проблема обнаруживается, но позже не будет решена даже после события нескольких дней, хотя условия запуска больше не совпадают.
В нашем конкретном случае:
- Я заглянул в БД и нашел событие с соответствующим идентификатором события (например, 123) в таблице событий и записал идентификатор объекта (например, 100123)
- Затем я проверил таблицу событий для конкретного objectid (100123) и обнаружил, что действительно произошло событие «разрешение» (например, 125)
- при проверке таблицы event_recovery я не смог найти запись, которая соответствовала бы этим двум идентификаторам событий (в то время как в случае других триггеров у них была запись в таблице event_recovery после их разрешения)
- Я просто создал запись: вставить в значения event_recovery (eventid, r_eventid) (‘123’, ‘125’);
- однако этого недостаточно, поскольку аналогичное сопряжение необходимо настроить в таблице проблем
- в таблице проблем я обнаружил проблему с моим eventid (123) и просто сопоставил событие восстановления с этим: update problem set r_eventid=’125′ где eventid = ‘123’ и objectid =’100123′;
Проблема в том, что это не решение, а просто одноразовый обходной путь. Проблема продолжает появляться, и в настоящее время мы подозреваем, что проблема находится на стороне базы данных (у нас есть основная резервная БД с выбором, направленным в режим ожидания, что может привести к сбою определенных операций выбора, которые в конечном итоге завершаются ошибкой, поскольку резервная БД находится в режиме только для чтения).
Мы попытаемся перенаправить все в основную базу данных, чтобы посмотреть, поможет ли это.