Ad Widget

**Kos** · 12-04-2019, 09:47

Тип Zabbix trapper предназначен для использования в сочетании со скриптами, которые получают данные каким-либо способом, а затем отправляют их на сервер, вызывая утилиту zabbix_sender.

**dimonprodigy** · 15-04-2019, 10:37

Originally posted by Kos

Тип Zabbix trapper предназначен для использования в сочетании со скриптами, которые получают данные каким-либо способом, а затем отправляют их на сервер, вызывая утилиту zabbix_sender.

Спасибо за ответ, если вам несложно ответить - продолжу тему.

Рассмотрим простейший пример: есть скрипт bash, который засунут в crontab, исполняется, например, раз в минуту. Что же писать в тексте скрипта, помимо
#!/bin/bash
zabbix_sender

Как zabbix_sender "понимает" какие параметры передавать?
Вручную я могу указать
zabbix_sender -v -z 172.28.30.5 -s temp -k pgpool.cache.num_selects -o 3
и оно сработает. Но значение параметра pgpool.cache.num_selects (3) взято из головы, как zabbix_sender поймет какие значения передавать zabbix-серверу?

**Kos** · 15-04-2019, 12:33

Понимать должен админ, который это настраивает.
Проще показать на примере.

Предположим, есть задача: собирать в Zabbix значения некоего параметра. Я, как админ, знаю, как это значение можно добыть при помощи скрипта; но есть препятствие: добывание этих данных - довольно длительный процесс. Поэтому использвать механизм UserParameter не получится (там значение должно возвращаться в пределах тайм-аута - т.е. максимум за несколько секунд). Поэтому я засовываю в crontab вызов своего скрипта, в котором первая часть занимается получением данных, а вторая - отсылкой полученных данных на сервер с помощью утилиты zabbix_sender. При этом я сам придумываю названия для всех нужных метрик, и в соответствии с этим:

создаю нужные элементы данных через веб-интерфейс Zabbix;
указываю те же ключи и имя хоста при вызове утилиты zabbix_sender.

К примеру, а нас используется система резервного копирования Avamar. Многие интересующие бэкапного админа параметры можно получить, используя утилиту командной строки mccli, запуская её с разными аргументами. Можно засунуть её вызов в скрипт, и там же в скрипте обрабатывать возвращаемые данные, чтобы извлечь то, что нужно. Беда лишь в том, что зачастую эта утилита может работать долго (несколько минут); но данные, в конце концов, возвращает.
Поэтому мы для начала придумываем, какие параметры хотели бы собирать, и выбираем имена и ключи для них:

Name	Key
Backups completed successfully	avamar.activity.completed
Backups completed with exceptions	avamar.activity.exceptions
Backups failed	avamar.activity.failed
Last valid checkpoint age	avamar.checkpoint.age
Last valid checkpoint duration	avamar.checkpoint.duration
Bytes protected	avamar.server.bytes.protected
Capacity	avamar.server.capacity
Capacity used	avamar.server.capacity.used
Backup Deduplication Ratio	avamar.server.dedup.rate
Load	avamar.server.load
Active sessions	avamar.server.sessions
Utilization	avamar.server.utilization

Имена ключей могут быть любыми (в рамках ограничений, накладываемых правилами именования ключей).
Ну а далее, как было сказано выше, сначала создаём элементы данных с такими ключами на нужном хосте, а затем - пишем свои скрипты, которые будут иметь структуру:

Code:

#!/bin/bash
#Получение данных
REZ=$(/usr/local/avamar/bin/mccli ... | awk ... )
#Отсылка данных
/usr/local/bin/zabbix_sender -c /usr/local/etc/zabbix_agentd.conf -s $(hostname -s) -k avamar.ключ.параметра -o "$REZ" >/dev/null 2>&1

Например, раз в сутки (утром) выполняется такой скрипт, который один раз вызывает "долгоиграющую" команду mccli (ещё и через sudo, поскольку для её вызова с такими аргументами нужны дополнительные привилегии), а затем на основе статистики за последние сутки подсчитывает количество заданий, завершившихся успешно, неуспешно и с исключениями:

Code:

#!/bin/bash
export PATH=${PATH}:/usr/local/avamar/bin

REZ=$(sudo /usr/local/avamar/bin/mccli activity show | awk -v CURDATE=$(date "+%Y-%m-%d") -v PREVDATE=$(date --date="yesterday" "+%Y-%m-%d") '
$8==CURDATE  && $12=="Backup"                {print $0}
$8==PREVDATE && $12=="Backup"    {if (substr($9,1,2)>17) print $0}
')
/usr/local/bin/zabbix_sender -c /usr/local/etc/zabbix_agentd.conf -s $(hostname -s) -k avamar.activity.failed -o $(echo "$REZ" | grep -c -i failed) >/dev/null 2>&1
/usr/local/bin/zabbix_sender -c /usr/local/etc/zabbix_agentd.conf -s $(hostname -s) -k avamar.activity.completed -o $(echo "$REZ" | grep -c -i completed) >/dev/null 2>&1
/usr/local/bin/zabbix_sender -c /usr/local/etc/zabbix_agentd.conf -s $(hostname -s) -k avamar.activity.exceptions -o $(echo "$REZ" | grep -c -i exceptions) >/dev/null 2>&1

**dimonprodigy** · 15-04-2019, 14:41

Большое спасибо за подробнейший ответ.

Уточняющий вопрос №1:
Я правильно понимаю, что тип "zabbix trapper" нужно использовать если:
- связь центра мониторинга и мониторящихся узлов нестабильна;
- если на мониторящихся узлах выполняются некие сложные, дольше нескольких (скольких именно?) секунд, запросы?

Уточняющий вопрос №2:
Я правильно понимаю, что "zabbix trapper" в случае падения мониторящегося узла просто ничего не пришлет и по определению на основе данных "zabbix trapper" нельзя создать триггеры?
...
Собственно, почему я поднял тему. Тестировал несколько Template для мониторинга PostgreSQL, в одном реализованно на zabbix agent, в другом - сплошь на zabbix trapper.

**oscar** · 15-04-2019, 22:17

Originally posted by dimonprodigy

Большое спасибо за подробнейший ответ.

Уточняющий вопрос №1:
Я правильно понимаю, что тип "zabbix trapper" нужно использовать если:
- связь центра мониторинга и мониторящихся узлов нестабильна;
- если на мониторящихся узлах выполняются некие сложные, дольше нескольких (скольких именно?) секунд, запросы?

Уточняющий вопрос №2:
Я правильно понимаю, что "zabbix trapper" в случае падения мониторящегося узла просто ничего не пришлет и по определению на основе данных "zabbix trapper" нельзя создать триггеры?
...
Собственно, почему я поднял тему. Тестировал несколько Template для мониторинга PostgreSQL, в одном реализованно на zabbix agent, в другом - сплошь на zabbix trapper.

Не совсем...
1.1 Траппер используют если необходимо реализовать более гибкие настройки расписания, например проверки в строго определенное время, а не через равные интервалы
1.2 Логическое продолжение п.1.1: Сервер не может повлиять ни на начало проверки, ни на её ход - например когда прилетает SNMP трап или происходит иное незапланированное событие
1.3 Когда вместо того чтобы обучать какой-нибудь сложной проверке агент, проще к утилите, которая это уже умеет, прикрутить отправлялку в виде zabbix-sender'а

2. Очень даже можно. Только если событие не регулярное то лучше заранее продумать способ тушить триггер - например через nodata...

**Kos** · 16-04-2019, 08:45

Originally posted by dimonprodigy

Уточняющий вопрос №1:
Я правильно понимаю, что тип "zabbix trapper" нужно использовать если:
- связь центра мониторинга и мониторящихся узлов нестабильна;
- если на мониторящихся узлах выполняются некие сложные, дольше нескольких (скольких именно?) секунд, запросы?

- со стабильностью связи это никак не связано (извините за тавтологию), даже, скорее, наоборот - т.е. при стабильной связи эта технология работает прекрасно, а при нестабильной связи нужно ещё дополнительно обрабатывать код завершения утилиты zabbix_sender и, например, сохранять во временный файл нужные данные, если их потеря критична и нужно их как-то перепослать в следующий раз;
- и да, и нет. Максимум, который можно выставить для тайм-аута (как на агенте Zabbix, так и на сервере) - это 30 секунд; да и это не очень хорошо. "Долгоиграющие" метрики могут являться одной из причин использования траппера, но отнюдь не единственной. В некоторых случаях может быть просто удобнее использовать именно траппер, чтобы прислать какой-то признак из скрипта.

Скажем, есть некая задача, запускаемая оператором вручную (например, условная процедура "Конец дня" в банке) - её надо запускать по окончании каждого рабочего дня, и во время этой процедуры часть систем пользователям недоступна. Понятие "конец рабочего дня" весьма расплывчатое: допустим, в конце месяца может позвонить бухгалтер и попросить пока "конец дня" не начинать, т.к. у неё много работы в связи с очередным балансом, и они там посидят ещё часок-другой. Сама процедура тоже длится неопределённое время: иногда может завершиться за 20 минут, а иногда - за 2 часа. В связи с этим написать триггер "подсистема N недоступна" становится затруднительно, т.к. этот триггер не должен срабатывать во время процедуры закрытия дня, а когда это закрытие дня начинается и завершается - неизвестно. Решение простое: в процедуру закрытия дня просто добавляем отсылку (с помощью zabbix_sender-а) признака того, что закрытие дня началось и завершилось, а в триггерах проверяем ещё и значение этого признака.

Другой пример - собираем какую-то статистику, для чего используется некий "тяжёлый" вызов, возвращающий сразу много значений. Скажем, для массивов Hitachi VSP G200 нужно собирать статистику по производительности (всякие IOPS-ы, kbps-ы и прочие TransRate-ы и Response Time-ы). Теоретически, для этой цели есть свой собственный софт (за свои собственные, весьма немалые деньги), и непонятно, как этот софт сопрягать с Zabbix-ом. А есть возможность, используя их штатную утилиту Export Tool, периодически забирать всю эту статистику за некоторый период (она экспортирует их в CSV-файлы). Беда лишь в том, что в этой статистике данных больно много, и делать скрипт, работающий по логике "дай мне Write TransRate для диска NNN" - (сейчас пройдусь по всей статистике, найду, что из них относится именно к данному диску, и именно к Write TransRate), просто нерационально: вслед за этим пойдёт запрос "дай мне Write TransRate для диска XXX", а потом "дай мне Read TransRate для диска NNN" - и каждый раз нужно будет пробегаться по всей собранной статистике. Гораздо эффективнее написать скрипт, который пройдётся по этим CSV-файлам один раз, и всю нужную статистику зашлёт в Zabbix-сервер за один вызов утилиты zabbix_sender, скармливая ей множество значений в её stdin.

Originally posted by dimonprodigy

Уточняющий вопрос №2:
Я правильно понимаю, что "zabbix trapper" в случае падения мониторящегося узла просто ничего не пришлет и по определению на основе данных "zabbix trapper" нельзя создать триггеры?

На первую половину вопроса ответ "да", на вторую - "нет".

Опять же, пример из жизни.
Есть некоторые задания, запускаемые время от времени по мере необходимости. Фактически, это скрипты, которые может запустить соответствующий сотрудник. Надо убедиться, что скрипт после своего запуска: а) завершился успешно, а не с ошибкой; б) завершился вовремя, а не завис.
Решение: в начало скрипта вставляется вызов zabbix_sender-а, отсылающий значение "-1" (как признак того, что скрипт начал работу), а в конец скрипта - ещё один вызов, отсылающий код завершения (ноль, если успешно, и некое положительное число, если была ошибка).
Соответственно, на каждое такое задание создаётся свой элемент данных типа "Zabbix trapper" для приёма этих значений, и два триггера: один реагирует на условие "пришло значение больше нуля" (т.е. Job NNN failed), а другой - не сочетание условий "last()<0 and nodata(нужныйТайм-аут)=1" (т.е. Job NNN has timed out).

Другой пример - с описанной выше статистикой по performance для массивов Hitachi. На любой параметр можно навесить свои триггеры (скажем, если важно видеть, что время отклика стало превышать определённый порог). В то же время, нет необходимости мониторить по nodata() каждый параметр по отдельности, поскольку собираются и отсылаются они в любом случае все вместе (либо придут все значения, либо не придёт ничего). Можно выбрать один из параметров и навесить на него один дополнитлеьный триггер: дескать, если данных давно нет, то надо проверить сам механизм сбора данных (может, где-то скрипт завис или сертификат истёк).

Ad Widget

Item-тип "Zabbix trapper"

Item-тип "Zabbix trapper"

Comment

Comment

Comment

Comment

Comment

Comment