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

Первым решением, которое я сделал чтобы разгрузить 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 P2000G3/2040/2050 можно найти ниже.

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

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

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 9

    +1
    Спасибо за статью, очень познавательно.
    Мониторинг оборудования HPE вообще тот еще геморрой: разные продукты (по бОльшей части перекупленные HP) имеют разные реализации мониторинга, так еще и со внешними системами постоянно проблемы.
    Кстати, как раз используем этот скрипт для мониторинга P2000G3. Хоть она уже и retired, но живучая, зараза…
      0

      Не могу сказать за всё оборудование НР, у нас от них только пачка DL360/380, да вот СХД. Так-то данный кейс не особо и сложен, благо есть варианты получения метрик, но сделать это как-то быстро и красиво у меня получилось только сейчас. =)
      P2000g3 стараюсь поддерживать, но бывали ошибке при парсинге XML, т.к. у меня в парке только 2040 и 2050 и вживую проверить на старом железе не могу.

      0
      Чего хотелось бы от Zabbix, так это возможность использовать один запрос на несколько элементов данных, это бы избавило от использования временных файлов, например как у вас, разгрузило бы в таких случаях сам zabbix, и отсутствовала бы задержка между запросами по таким элементам. И да, зависимые элементы данных — это очень хороший функционал. Сам теперь жду релиза 4.0 для обновления т.к. LTS.
        0
        возможность использовать один запрос на несколько элементов данных

        По сути, зависимые элементы, примерно это и реализуют. Мы делаем один запрос, а в итоге разбираем полученные данные на множество метрик. Есть нюансы, конечно, вроде одинакового времени опроса у всех дочерних айтемов и фактического дублирования информации в БД, но всё же это большой шаг.
        0
        Зависимые элементы данных и в 4 версии имеют массу ограничений по использованию, например не поддерживаются массивы, что жутко не удобно.
        Поэтому чем мучится с ними и придумывать костыли, то лучше для отправки сразу пачки метрик без зависимых элементов данных — использовать zabbix-sender.
          0
          например не поддерживаются массивы

          Я не понял о каких массивах идёт речь.

          использовать zabbix-sender

          Всё равно это своеобразный «костыль» и придется писать какую-то обвязку.
          0
          Я не понял о каких массивах идёт речь.


          О том самом в Json:
          Массив — упорядоченная коллекция значений. Массив начинается с [ (открывающей квадратной скобки) и заканчивается ] (закрывающей квадратной скобкой). Значения разделены, (запятой).


          Если на пальцах, то к примеру у вас есть такие данные:

          	{
          		"hostname": "myserver.ru",
          		"date": "06.08.2018 11:52:18",
          		"msg": [{
          				"error_code": "231",
          				"error_msg": "Error: XXXX not a president"
          			},
          			{
          				"error_code": "232",
          				"error_msg": "Error: XXXX is crab"
          			}
          		]
          	}


          Дак вот зависимый элемент данных не может быть массивом, не работает вот так $.msg[*]
          Можно максимум извлечь из массива какой-нибудь элемент так: $.msg[0].error_code
          Оно и понятно, почему так не будет работать, но хотелось… хотя бы весь массив извлечь, но он не извлекается :(

          Всё равно это своеобразный «костыль» и придется писать какую-то обвязку.


          Вот как раз zabbix-sender — это не костыль. Когда сбор данных и его обработка занимают более 30 сек., тут и приходит на помощь zabbix-sender, т.к. агент столько ждать не может.
            0
            Да, судя по докам Zabbix, поддерживается извлечение только одиночного компонента. Хотя, я не могу найти кейса у себя для извлечения массива в зависимый элемент. Как его потом обрабатывать?
              0
              Например в массиве могут быть логи, можно было бы их извлекать и обрабатывать регуляркой на предмет поиска ключевых сообщений об ошибках.

          Only users with full accounts can post comments. Log in, please.