Главная » Хабрахабр » [Из песочницы] Использование Dependent items в Zabbix 4.0 на примере HPE MSA 2040/2050

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

Введение

Все, кто пользуется системой мониторинга 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 быстро «ложится», а ведь мы говорим только о запросе «здоровья» компонентов, не учитывая остальные возможные и интересные метрики — температура, наработка на часы для жестких дисков, скорость вращения вентиляторов и т.д.

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

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

,"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, содержащий нужные метрики.

Нас могло бы спасти LLD, но тут, при создании прототипа, оно не позволяло нам указывать в качестве родительского айтема тот, что не был создан самим правилом, а грязный хак с созданием фиктивного айтема через LLD и подменой его itemid в БД на нужный, ронял сервер Zabbix. Всё было хорошо, но быстро всплыли нюансы, описанные в начале статьи — все зависимые метрики приходилось создавать и обновлять вручную, что было довольно мучительно (порядка 300 метрик на одну СХД плюс триггеры и графики). В багтрекере 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» с правилом, извлекающим показания температуры:

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

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

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

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

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

[root@zabbix]# zabbix_server -R config_cache_reload

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

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

Заключение

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

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

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

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] Учёные вырастили универсальные стволовые клетки при помощи CRISPR инженерии

Клетки сердечной мышцы человека, полученные из новых универсальных стволовых клеток Учёные из University of California San Francisco впервые вырастили универсальные стволовые клетки, используя технологию редактирования генов CRISPR в целях получения плюрипотентных стволовых клеток, которые могут быть трансплантированы любому пациенту, не ...

[Перевод] Шесть историй, как код переписали с нуля

Новый взгляд на извечный вопрос: следует ли переписывать приложение с нуля или это «самая худшая стратегическая ошибка, которую может сделать разработчик программного обеспечения»? Оказывается, при работе со зрелой кодовой базой есть более двух вариантов ответа. «Исходный код словно заржавел!» — Джоэл ...