Иногда возникает задача осуществлять мониторинг времени изменения какого-то файла или каталога. Например, если есть лог-файл, в который что-то постоянно пишется, или каталог, в который валится почта, результаты работы скриптов и тому подобное. Мы на работе, например, отслеживаем приход новостей от разных агентств.
В любом случае, нам может захотеться отслеживать и получать оповещения про любой случай прекращения изменений фала/каталога. Сделать это средствами zabbix довольно легко:
- создаём айтем vfs.file.time[/path/to/our_file]
- создаём триггер с выражением {flycat.info:vfs.file.time[/path/to/our_file]. fuzzytime(600) }=0 (сигнализировать, если время модификации файла больше 10 минут)
- наслаждаемся результатом: в случае, если время модификации нашего файла или каталога становится больше 600 секунд, нам приходит оповещение
Хороший способ? Хороший! Но не очень 🙂 Какие есть у него недостатки:
- Время модификации файла считается на клиентской машине исходя из показаний её часов, а текущее время для fuzzytime берётся с zabbix-сервера. Нужно ли объяснять, что произойдёт, если часы на этих машинах “разбегутся”?
- Вычисление разницы времени происходит на zabbix-сервере. Естественно, что это его, хоть и незначительно, но нагружает. А если таких параметров у вас много, нагрузка может стать довольно значительной
- Ну и ещё один фактор: низкая наглядность. Посмотрите на график айтема. По нему невозможно определить, превысило ли ожидаемое время модификации предельный срок.
Давайте теперь сделаем тоже самое, но другим способом. Пишем (на клиенте) такой скрипт под названием modtime:
#!/bin/bash s=`ls -d -l --full-time $1|awk '{print $6" "$7}'` a=`date +%s` b=`date --date="$s" +%s` echo $(( ($a - $b)/60 ))
и кладём его в каталог zabbix-плагинов. В случае, если вы не знаете, где этот каталог, можно положить его куда заблагорассудится (не забывая, конечно, о разрешениях для zabbix), но тогда нужно будет прописать в строке конфигурации zabbix-агента следующую строчку:
UserParameter=modtime[*],/opt/zabbix/plugins/modtime $1
Теперь создаём следующий айтем: modtime[/path/to/our_file] и триггер с выражением: {flycat.info:modtime[/path/to/our_file].last(0) }>10. Обратите внимание, что в этом варианте скрипта идёт учёт времени не в секундах, а в минутах.
Что мы теперь видим на графике?
По-моему, всё стало гораздо более наглядным и понятным. Пожалуй, единственный недостаток второго способа — работает он только под unix / linux, где есть bash. На Windows такие трюки не пройдут.
Прошу прощения за офтоп…
А есть возможность дать детальное описание по конфигурированию Zabbix для ловли SNMP-трапов и их последующей обработке?
Меня например интересует обработка SNMP-трапов от упсов. Но что ни в какую не получается.
Трапы ловятся, их можно уидеть в Monitoring->Last data.
В одной посылке как правило 3-4 OID-а. Как их обрабатывать? Расскажите, не понимаю 🙁
Я, честно говоря, к трапам ещё даже не подбирался. А обычные SNMP-данные ловятся и мониторятся так же как и данные от zabbix-агентов.
Вот, смотрите, что нашёл: http://habrahabr.ru/blogs/sysadm/87544/
Подскажите, есть ли возможность в Zabbix сделать шаблон следующего вида:
1. Создать шаблон
2. Элемент данных (Items) для snmp
3. Подключить триггер.
Теперь проблема, мне необходимо для различных устройств в OID элемента данных менять номер порта (параметр снимается один и тотже, но портов около 1000), как сделать так, что бы не создавать множество элементов данных и тригеров, а использоать только один?
Создавая новый узел и прикркпяя к нему шаблон неудается изменить значение OID в Items, а очень хотелось бы (поле заблокировано) .
А вот более компактный код, для которого даже плагин писать не нужно, сразу в конфиге zabbix-агента размещаем строку:
UserParameter=modtime[*],echo $(( ($(date +%s)-$(ls -ld --time-style=+%s $1 |awk '{print $6}'))/60 ))