[Из песочницы] Использование Dependent items в Zabbix 4.0 на примере HPE MSA 2040/205004.08.2018 22:18

Введение

Все, кто пользуется системой мониторинга Zabbix и следит за её развитием, знают, что с выходом Zabbix 3.4 у нас появилась замечательная функциональная возможность — Dependent Items (зависимые элементы данных), о который уже был соответствующий пост в блоге Zabbix. Однако, в том виде, в котором она была представлена в 3.4, использовать её «на всю катушку» было проблематично ввиду того, что макросы LLD не поддерживались для использования в правилах препроцессинга (ZBXNEXT-4109), а так же в качестве «родительского» элемента данных можно было выбрать только тот, что создан самим правилом LLD (ZBXNEXT-4200). Короче говоря, приходилось делать всё ровно так, как рассказывается по ссылке выше — работать руками, что при большом количестве метрик доставляло много неудобств. Однако, с выходом Zabbix 4.0alpha9 всё изменилось.

Немного истории

Для меня описанный функционал был важен в связи с тем, что на нашем предприятии используется несколько СХД от HP, а именно HP MSA 2040/2050, метрики с которых снимаются запросами к их XML API с использованием Python-скрипта.

В самом начале, когда встала задача наблюдения за обозначенным оборудованием и был найден вариант с использованием API, выяснилось, что в самом простом случае, чтобы узнать, скажем, состояние здоровья одного компонента СХД, требовалось сделать два запроса:

Запрос токена аутентификации (session key);
Сам запрос, возвращающий информацию по компоненту.

Теперь представьте, что хранилище состоит из 24 дисков (а может и больше), двух блоков питания, пары контроллеров, вентиляторов, нескольких дисковых пулов и пр. — умножаем всё это на 2 и получаем более 50 элементов данных, что равно стольким же запросам к API при ежеминутных проверках. Если попробовать пойти по такому пути, API быстро «ложится», а ведь мы говорим только о запросе «здоровья» компонентов, не учитывая остальные возможные и интересные метрики — температура, наработка на часы для жестких дисков, скорость вращения вентиляторов и т.д.

Первым решением, которое я сделал чтобы разгрузить API, еще до выхода Zabbix версии 3.4, было создание кэша для получаемого токена, значение которого записывалось в файл и хранилось N-минут. Это позволило снизить количество обращений к API ровно в два раза, однако, ситуацию сильно не изменило — что-то помимо состояния здоровья получать было проблематично. Примерно в это время я посетил Zabbix Moscow Meetup 2017, устроенный компанией Badoo, где и узнал о упомянутом выше функционале зависимых элементов данных.

Скрипт был доработан до возможности отдавать подробные JSON объекты, содержащие интересующую нас информацию по различным компонентам хранилища и вывод его стал выглядеть примерно так вместо одиночных строковых или числовых значений:

{"1.1":{"health":"OK","health-num":"0","error":"0","temperature":"24","power-on-hours":"27267"},"1.2":{"health":"OK","health-num":"0","error":"0","temperature":"23","power-on-hours":"27266"},"1.3":{"health":"OK","health-num":"0","error":"0","temperature":"24","power-on-hours":"27336"}, ... }

Это пример с отдаваемыми данными по всем дискам хранилища. По остальным компонентам картина схожая — ключом является ID компонента, а значением — объект JSON, содержащий нужные метрики.

Всё было хорошо, но быстро всплыли нюансы, описанные в начале статьи — все зависимые метрики приходилось создавать и обновлять вручную, что было довольно мучительно (порядка 300 метрик на одну СХД плюс триггеры и графики). Нас могло бы спасти LLD, но тут, при создании прототипа, оно не позволяло нам указывать в качестве родительского айтема тот, что не был создан самим правилом, а грязный хак с созданием фиктивного айтема через LLD и подменой его itemid в БД на нужный, ронял сервер Zabbix. В багтрекере Zabbix быстро появились упомянутые фичреквесты, что указывало на то, что данный функционал важен не только мне.

Т.к. все подготовительные операции с моей стороны были завершены, я решил потерпеть и не плодить временных решений, таких как динамическая генерация шаблона и ждал только закрытия указанных в начале статьи ZBXNEXT’ов и вот совсем недавно это было сделано.

Как всё выглядит теперь

Для демонстрации новых возможностей Zabbix мы возьмем:

СХД HPE MSA 2040 доступную по протоколу HTTP/HTTPS;
Сервер Zabbix 4.0alpha9, установленный из официального репозитория на CentOS 7.5.1804;
Скрипт, написанный на Python третьей версии и предоставляющий нам возможность обнаруживать компоненты СХД (LLD) и возвращать данные в формате JSON для парсинга на стороне сервера Zabbix с использованием JSON Path.

Родительский элемент данных будет представлять собой «внешнюю проверку» (external check), вызывающую скрипт с необходимыми аргументами и хранить полученные данные как текст.

Подготовка

Python-скрипт устанавливается в соответствии с документацией и имеет в зависимостях Python библиотеку «requests». Если у вас RHEL-based дистрибутив, установить её можно с помощью пакетного менеджера yum:

[root@zabbix]# yum install python3-requests

Или с помощью pip:

[root@zabbix]# pip install requests

Протестировать работу скрипта можно из оболочки, запросив, например, данные LLD о дисках:

[root@zabbix]# ./zbx-hpmsa.py -m MSA_DNS_NAME_OR_IP -d -c disks
{"data":[{"{#DISK.ID}":"1.1","{#DISK.SN}":"KFGY7LVF"},{"{#DISK.ID}":"1.2","{#DISK.SN}":"Z0K02QVG0000C4297CH3"},{"{#DISK.ID}":"1.3","{#DISK.SN}":"KLK7XG0F"}, ... }

Настройка хоста

Для начала нужно создать родительские элементы данных, которые будут содержать все необходимые нам метрики. В качестве примера создадим такой элемент для физических дисков:

Имя — указываем произвольно;
Тип — внешняя проверка;
Ключ — вызов скрипта с нужными параметрами (см. документацию скрипта на GitHub);
Тип информации — текст;
Интервал обновления — в примере используется пользовательский макрос {$UPDATE}, разворачивающийся в значение »1m»;
Период хранения истории — один день. Думаю, что хранить родительский элемента данных дольше смысла не имеет.
Проверяем последние данные по созданному элементу:

Приходит JSON, значит всё сделано правильно.

Следующим будет настройка правил обнаружения, которые отыщут все доступные для мониторинга компоненты и создадут зависимые айтемы и триггеры. Продолжая пример с физическими дисками, выглядеть оно будет так:

После создания правила LLD потребуется создать прототипы элементов данных. Создадим такой прототип, на примере данных о температуре:

Имя — указываем произвольно;
Тип — зависимый. В качестве родительского элемента данных выбираем соответствующий созданный ранее элемент;
Ключ — проявим фантазию, но нужно учесть, что каждый ключ должен быть уникальным, поэтому включим в него макрос LLD;
Тип информации — в данном случае числовой;
Период хранения истории — в примере это пользовательский макрос, указывается по вашему усмотрению;
Период хранения трендов — опять же, пользовательский макрос;

Так же я добавил прототип «Приложения» — к нему можно удобно привязывать метрики, относящиеся к одному компоненту.

На вкладке «Препроцессинг» создадим шаг типа «JSON Path» с правилом, извлекающим показания температуры:

Выражение шага выглядит так: $['{#DISK.ID}']['temperature']

Обратите внимание, что теперь в выражении можно использовать макросы LLD, что не просто значительно упрощает нам работу, но и вообще дает проделывать подобные штуки довольно просто (раньше вас бы направили в Zabbix API).

Далее, по аналогии с температурой, создадим оставшиеся прототипы элементов данных:

На этом этапе можно проверить получаемый результат, зайдя в «Последние данные» по хосту. Если там вас всё устраивает, продолжаем работу дальше. Я в итоге получил следующую картину:

Ждем пока обновится конфигурационный кэш или толкаем его обновление вручную:

[root@zabbix]# zabbix_server -R config_cache_reload

После этого можно воспользоваться еще одной крутейшей «фишкой» версии 4.0 — кнопкой «Check now» для запуска созданных правил LLD:

У меня получился следующий результат:

Заключение

В итоге, всего девятью запросами к XML API мы смогли получить более трехсот метрик с одного узла сети, затратив на это минимум времени и получив максимум гибкости. LLD даст нам возможность автоматически обнаруживать новые компоненты или обновлять старые.

Спасибо, что читали, ссылки на используемые материалы, а там же на актуальный шаблон для HPE MSA P200G3/2040/2050 можно найти ниже.

P.S. Кстати, в версии 4.0 так же представлен новый тип проверок — HTTP агент, который в паре с препроцессингом и XML Path, потенциально может избавить нас от использования внешних скриптов — нужно только решить вопрос получения токена аутентификации, который всё-таки должен периодически обновляться. Одним из вариантов я вижу использование глобального макроса с этим токеном, который можно обновлять через Zabbix API по крону, т.ч. заинтересованные люди могут развить эту идею. =)

Скрипт
Шаблон на Zabbix Share
Зависимые элементы данных
JSON Path
Zabbix 4.0alpha9