Zabbix: мониторинг лога, автоматическое восстановление триггера

Есть триггер, который по timestamp мониторит лог-файл. Как только в логе появляется соответствующая запись, триггер срабатывает.

Вот пример выражения такого триггера, который срабатывает на запись «FAILED»:

{myserver_name.com:log["/var/log/my.log","FAILED","UTF-8","10",skip].logsource(FAILED)}=0

И всё хорошо, но в Item для данного триггера всё время будет появляться только запись «FAILED» и более ничего, а значит триггер никак не вернётся самостоятельно из статуса «PROBLEM» в статус «OK».

Вариант 1.

Решение я подсмотрел на форуме zabbix. Для того, чтобы триггер возвращался в состояние «ОК», надо для его срабатывания добавить ещё одно условие, которые в любом случае будет менять свой статус. Или наоборот не будет менять свой статус. В данном случае можно за основу восстановления триггера взять промежуток времени, за который Item не получает новых данных. Например:

{myserver_name.com:log["/var/log/my.log","FAILED","UTF-8","10",skip].nodata(60)}<>1

Это условие, при котором триггер сработает, если будут получены новые данные за последние 60 секунд. Получается такое общее выражение для срабатывания триггера:

{myserver_name.com:log["/var/log/my.log","FAILED","UTF-8","10",skip].logsource(FAILED)}=0 and {myserver_name.com:log["/var/log/my.log","FAILED","UTF-8","10",skip].nodata(60)}<>1

Работает оно так. В Item приходит сообщение из лога «FAILED» и первое условие триггера выполнено. Триггер смотрит на второе условие и оно тоже выполнено, т.к. за последние 60 секунд Item изменил своё значение (nodata=0). Если через 60 секунд новых данных из лога не поступило, то второе условие триггера не будет будет выполнено (nodata=1) и триггер перейдёт сразу в статус «ОК».

Время в 60 секунд было взято произвольно и для каждого случая подбирается своё. Я брал рабочее значение 86400 секунд (сутки). Раз в сутки проверяется файл и если новых значений туда не поступило, то проблема более не актуальна.


Вариант 2.

Ещё один рабочий вариант с использованием двух Item. Смысл тот же, но используются два лог-файла. Из первого я получаю сообщение «FAILED» — первое условие. А из второго — кол-во этих сообщений.

{myserver_name.com:log["/var/log/my.log","FAILED","UTF-8","10",skip].logsource(FAILED)}=0 and {myserver_name.com:vfs.file.contents[/var/log/my.log].last(86400s)}>1

Это вариант удобнее тем, можно варьировать чувствительность триггера к кол-ву ошибок. В примере, если кол-во ошибок будет равно единицы, но при этом в лог-файле с ошибками записи «FAILED» нет, то это считается не критичным и триггер не сработает.

*Вариант-2 в рабочем исполнении используется вместо с скриптом bash, поэтому может выглядеть немного нелогичным. Например, можно подумать, зачем смотреть сообщение «FAILED», когда при его наличии кол-во ошибок и так будет известно. Тут не совсем так, т.к. скрипт парсит совсем другой лог и смотрит только конкретные строки с сообщением «FAILED». При этом могут быть другие ошибки «FAILED» и скрипт посчитает только их кол-во.


Использованный материал.

https://www.zabbix.com/forum/showthread.php?t=39146

Zabbix: мониторинг лога, автоматическое восстановление триггера: 2 комментария

    1. Приветствую. В данной статье я описал только триггеры. Если взять выражение самого первого триггера в статье, то Item там будет log[«/var/log/my.log»,»FAILED»,»UTF-8″,»10″,skip]. В статье
      https://vot-tak-vot.tk/?p=90 можно посмотреть как создаются аналогичные Item и триггеры для них.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *