Всем привет, меня зовут Андрей. И я люблю «железо». А еще люблю мониторинг. И наконец в моей жизни появился настоящий сервер с IPMI и прочими взрослыми технологиями. И я надеюсь, что появятся еще. Именно это сподвигает меня на поиск универсальных решений. Итак: LLD-обнаружение IPMI датчиков.
Что вы получите «из коробки»:
- Обнаружение датчиков температуры, напряжения, оборотов
- Триггеры, основанные на показаниях SDR
Ну и выглядит это так:
Суммарно понадобятся:
- Скрипт на Bash
- Шаблон
- Документация или Интернет для переименования элементов
Для начала уточню, что у вас должен быть подготовленный рабочий сервер Zabbix 3.2 с установленной утилитой ipmitool, настроенный узел IPMI.
Скрипт
Он выполняется на сервере как внешняя проверка, поэтому должен находиться в папке externalscripts, которая указана в конфигурации сервера. По умолчанию в Ubuntu это /usr/lib/zabbix/externalscripts. Не забывайте установить соответствующие права на выполнение этого скрипта.
ipmi.sh
Шаблон
Для каждого подключаемого узла необходимо указать 4 макроса, а именно: {$IPMIIP}, {$IPMIPRIV}, {$IPMIUSER}, {$IPMIPASS}. Значения их интуитивно понятны, кроме только что {$IPMIPRIV} — это роль пользователя (ADMIN, USER и т.д.). Вносить их нужно, так как в Заббиксе нет стандартных макросов на этот счет. Возможно, в будущем они появятся.
Особенность шаблона, как и в прошлой статье, состоит в двойном преобразовании макросов {${#X}}. Оно позволяет заменять имена сенсоров на читаемые. Согласитесь, приятнее выглядит «Напряжение батареи BIOS», а не «Напряжение BB_3.3V_VBAT».
Все что вам нужно сделать для этого — внести соответствующий макрос в список шаблона в виде:
{$CPU1_TEMPERATURE} = CPU1
В списке уже есть несколько преобразований для Intel S1200 и Asus RS300.
Немного сокращений
BB — BaseBoard
VR — Voltage Regulator
SSB — Server South Bridge
VR — Voltage Regulator
SSB — Server South Bridge
Шаблон
Немного о фильтрации
Не все датчики нужно считывать, это факт. К примеру, зачем мне суммарный запас (Agg Margin) по температуре? Для таких случаев для каждого обнаружения есть свой фильтр. Но увы, переключить его в режим «не совпадает» нельзя. Возможное решение — использовать глобальные регулярные выражения (Результат ЛОЖЬ). В фильтр же добавляется имя выражения с символом @.
Для каждого из обнаружений для себя я сделал: IPMI-FAN, IPMI-VOLT, IPMI-TEMP (в шаблон они не попадают).
IPMI-FAN, IPMI-VOLT, IPMI-TEMP
Немного о триггерах
Значения для условий триггеров берутся из SDR, то есть из самого контроллера. Поля SDR содержат 6 колонок порогов: нижний опасный, нижний критичный, нижний некритичный, верхний некритичный, верхний критичный, верхний опасный. Если значение одного из полей отсутствует, то триггер не создается. ИМХО, самый логичный способ изменить триггер — изменить поля SDR устройства под свои нужды. Как это сделать — читайте инструкцию к вашему контроллеру или МП.
Итого
Свои zabbix-
Поделиться с друзьями
Комментарии (8)
TaHKucT
17.06.2017 20:07Для таких случаев для каждого обнаружения есть свой фильтр. Но увы, переключить его в режим «не совпадает» нельзя.
Ну не знаю, законом вроде пока не запрещено
ddPechkin
Добрый день! Вижу, для каждого итема дергаете отдельно IPMI модуль железки. Нет ли у Вас проблемы, что многие IPMI итемы уходят в статус unsupported/supported, когда модуль «забивается» запросами. На supermicro видем подобную картину. Из-за этого графики IPMI получаются дырявыми (данные по запросу не приходят).
AcidVenom
На указанных серверах проблем нет. Если вы используете шаблон без обнаружения на разное железо, то это вполне нормальная реакция на поток запросов несуществующих датчиков.
Обнаружение как раз и позволяет не дергать несуществующие датчики. Ну и, конечно, фильтрация уменьшает нагрузку.
ddPechkin
Так вот в том то и дело, что используем обнаружение и запрос идет к существующим элементам-датчикм. Просто если итемов много — на каждый запрос создается своя сессия, у супермикро есть ограничение на 15 сессий. Соответственно, если запросов больше — какие то из них не пропускаются модулем.
AcidVenom
Если мониторите много всего и такой метод не подходит, то можно переделать обнаружение на захват значений (этот же скрипт, только подобрать «cut -c xx-xx»). Вызывать обнаружение, скажем, каждую минуту; в сумме получите 3-5 сессий в минуту. А элементы доставать как внутренний Zabbix.
В принципе особых проблем это должно вызвать. Ну только нагрузка на сервер возрастет.
Lelik13a
Я, когда приходится мониторить множество метрик, чтобы не форкать большое количество процессов и не нагружать zabbix-сервер и клиента, переделываю мониторинг на zabbix_sender.
В скрипте за один проход получаем как можно больше информации, затем её разбираем и засылаем на сервер в один заход. Этот подход можно комбинировать с предварительным обнаружением необходимых метрик через LLD и запросом у сервера, что-же мы именно будем отсылать. Питон и zabbix api это всё позволяют.
throttle
У меня такое встречается, но КМК, из-за таймаута на получение айтема. IPMI долго отвечает. Начал городить свой велосипед с автообнаружением и кэшированием, да все времени нет закончить.