Есть триггер, который по 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