Собирали ли логи в Zabbix?
Что проверяют
Умеете ли вы смотреть на систему со стороны эксплуатации и понимаете ли, что Zabbix это мониторинг и оповещения, а не хранилище логов. Для тестировщика вопрос обычно ещё и про то, проверяете ли вы срабатывание алертов так же, как остальную функциональность.
Как отвечать
По существу инструмента: за логи отвечают элементы данных log и logrt для файлов с ротацией, тип значения у них «Журнал». Работают они только через активные проверки агента, потому что агент сам помнит позицию в файле и досылает новые строки.
log[/var/log/app/app.log,"ERROR",,,skip]Второй параметр это регулярное выражение отбора, skip заставляет начать с конца файла, а не перечитывать всю историю. Приложение может слать события и само, через трапперный элемент и zabbix_sender. Дальше строится триггер на совпадение или на отсутствие данных, а к триггеру привязывается оповещение.
Что стоит добавить от лица тестировщика:
- проверка оповещения это тест: искусственно вызвать ошибку и убедиться, что триггер сработал и сообщение дошло адресату;
- ценна не только строка с ошибкой, но и её отсутствие после релиза;
- глубокий разбор логов ведут в системе полнотекстового поиска, Zabbix держит факт и порог.
Если опыта с Zabbix нет, скажите честно и опишите, какие проверки заводили в другом инструменте мониторинга.
Где спотыкаются
Ждут от Zabbix поиска по логам. Он ловит совпадение и меняет состояние триггера, а читать историю произвольными запросами там неудобно, для этого берут другой стек.
Второе: заводят элемент лога на пассивном агенте и не понимают, почему данных нет. Тип проверки обязан быть активным, иначе элемент так и останется неподдерживаемым.
Третье: пишут выражение отбора настолько широким, что триггер срабатывает на каждую вторую строку. Команда через неделю перестаёт читать такие оповещения, и реальная авария теряется в шуме.