Есть у меня в парке серверов множество различных рейд-контроллеров, в том числе софтовых(mdadm). У каждого из них имеются различные средства мониторинга, но хотелось бы все это отслеживать централизовано, например через zabbix, а в случае изменения состояния любого из массивов - получать уведомления, например по почте. Данная статья не является пошаговым руководством, а представляет из себя набор заметок на память для различных контроллеров. В каждом подразделе описана техника получения информации о состоянии массивов zabbix-агентом.
Большинство утилит управления рейд-контроллером требуют root-привелегий, создаем файл /etc/sudoers.d/zabbix:
Defaults:zabbix !requiretty Cmnd_Alias ZABBIX_CMD = /usr/sbin/tw_cli, /usr/sbin/MegaCli64, /usr/sbin/arcconf zabbix ALL = (other_user) NOPASSWD: ALL zabbix ALL = (root) NOPASSWD: ZABBIX_CMD
В Linux mdadm есть файл /proc/mdstat, в котором содержится информаци о всех массивах и их состоянии. У каждого массива есть вот такое текстовое обозначение: [UU] (кол-во букв U зависит от кол-ва дисков в массиве). Если один или более дисков выходит из строя, то вместо буквы U появляется знак подчеркивания: _ Соответственно ищем подобные массивы и подсчитываем их кол-во, если их больше 0, то поднимаем панику. В конфиге агента добавляем такой пользовательский параметр:
UserParameter=custom.softraid.status,egrep -c "\[.*_.*\]" /proc/mdstat
И тестируем:
# zabbix_agentd -t custom.softraid.status custom.softraid.status[egrep -c "\[.*_.*\]" /proc/mdstat] [t|0]
Как видно, параметр вернул ноль( [t|0] ), все нормально.
Для мониторинга контроллеров 3ware (теперь уже LSI) понадобится утилита 3w_cli, скачать ее можно с оф. сайта производителя контроллера, либо поставить из стороннего репозитория(в случае с debian): hwraid.
Теперь добавляем в конфиг забикса пользовательский параметр:
UserParameter=custom.3ware.status,sudo tw_cli /c0 show allunitstatus | grep "Not Optimal" | awk '{print $6}'
Этот параметр аналогичным образом подсчитывает кол-во массивов(на первом контроллере), которое имеет статус «Not Optimal». Если в сервере установлено несколько контроллеров, то можно будет сделать скрипт с несколькими подобными командами и в конце сумировать результат.
Проверяем работоспособность:
# zabbix_agentd -t custom.3ware.status custom.3ware.status[sudo /opt/3ware/CLI/tw_cli /c0 show allunitstatus | grep "Not Optimal" | awk '{print $6}'] [t|0]
Все массивы в норме ([t|0]).
Для мониторинга контроллеров Adaptec понадобится утилита arcconf, скачать ее можно с оф. сайта производителя контроллера, либо поставить из стороннего репозитория(в случае с debian): hwraid. Делаем симлинк на arcconf в /usr/sbin/arcconf.
В конфиг zabbix-агента добавляем следующий пользовательский параметр:
UserParameter=custom.adaptec.status,sudo arcconf GETCONFIG 1 | grep -i "Status of logical device" | grep -cv Optimal
Этот параметр производит подсчет кол-ва массивов первого контроллера, статус которых отличается от «Optimal». Если в системе более одного контроллера, то нужно создать скрипт, который будет выполнять подобную команду для каждого контроллера и суммировать результат.
Проверяем:
# zabbix_agentd -t custom.adaptec.status custom.adaptec.status[/opt/adaptec/arcconf GETCONFIG 1 | grep "Status of logical device" | grep -cv Optimal] [t|0]
Все нормально, кол-во отказавших массивов ноль ([t|0]).
Со стороны сервера:
# zabbix_get -s X.X.X.X -k "custom.adaptec.status" 0
Контроллеры LSI можно мониторить с помощью утилиты MegaCLI, в том числе контроллеры, которые установлены в серверах IBM серии X, например x3650 ставят контроллеры LSI. Скачать ее можно с сайта IBM(например ibm_utl_sraidmr_megacli-8.04.10_linux_32-64.zip), но проще с сайта производителя последнюю версию, это универсальный установщик для любого дистрибутива.
На сайте IBM есть пакеты только для redhat и suse, но не составляет труда конвертировать их в deb с поомщью alien. Делается это командой:
# alien --scripts _pakage_name_.rpm
После конвертирования устанавливаем пакеты и добавляем пользовательский параметр в zabbix-агент:
UserParameter=custom.lsi.status,sudo MegaCli64 -LDInfo -Lall -aAll | grep State | grep -vc Optimal
Этот параметр выполняет подсчет всех массивов со статусом отличным от «Optimal».
Проверяем:
# zabbix_agentd -t custom.lsi.status custom.lsi.status[MegaCli64 -LDInfo -Lall -aAll | grep State | grep -vc Optimal] [t|0]
В некоторых сервера с мат. платами intel устанавливали интегрированные контроллеры axx4sasmod. Управлять и мониторить их можно с помощью RAID Web Console 2(не понятно, почему она называется Web, когда работает не через браузер, а требует установки на клиенте), либо с помощью snmp. Команднострочная утилита CmdTool2 почему-то контроллер не обнаружила. Корректно настроить работу через snmp на Debian мне не удалось, как это сделать на редхат-подобных описано в статье, ссылка на которую дана ниже.
Создадим тригер отслеживания состояния массивов на примере mdadm.
Создаем шаблон Configuration → Templates → Create template, задаем имя и добавляем в группу Templates:
В шаблоне открываем вкладку Items и создаем элемент. Указываем ключ(имя пользовательского параметра в zabbix-агенте) и уменьшаем кол-во дней хранения значений:
Дальше переходим во вкладку Triggers и создаем тригер, в поле Expression нажимаем на конпке Add и в появившемся окне в поле Item нажимаем Select, в появившемся окне выбираем группу Templates и только что созданый шаблон, там у нас один единственный элемент(Item), выбираем его. В выпадающем меню Function выбираем «Last (most recent) T value is NOT N» и проверяем, что в поле N стоит ноль, таким образом трегер будет проверять, что полученное значение от zabbix-клиента(кол-во отказавших массивов) равняется нолю, если это не так - он сработает. Вот что должно получиться(если все нормально, нажимаем Insert):
Ну и в заключении задаем имя тригера и уровень серъезности произшествия, я оценил его как Hight:
Нажимаем сохранить(Save).
Если сервер не получает данные по рейду(в веб-интерфейсе в разделе latest data ничего нет, а должен быть 0), то в первую очередь нужно проверить что файл /etc/sudoers.d/zabbix создан и симлинк из /opt/… сделан в /usr/sbin/… Иначе будет такая ошибка:
Мы полагаем, что ваш системный администратор изложил вам основы безопасности. Как правило, всё сводится к трём следующим правилам: №1) Уважайте частную жизнь других. №2) Думайте, прежде что-то вводить. №3) С большой властью приходит большая ответственность. sudo: нет tty и не указана программа askpass
Также была проблема с arcconf, он очень долго выполняется(5-6 секунд) и срабатывает таймаут сервера, по-умолчанию он 4 секунды. Ошибка очень не очевидная, потому как при тестировании через командную строку все срабатывает штатно, увидеть это я смог только при тестировании через веб-интерфейс: в разделе «Configuration → Templates» выбираем нужный темплат и заходим в «Items → Number of faild Adaptec devices», внизу нажимаем кнопку «Test» и в появившемся окне указываем адрес хоста, порт и нажимаем «Get Value». Если все в порядке, мы должны получить в поле Value 0, если нет, там будет сообщение об ошибке, либо как на скрине ниже, сообщение о таймауте.
Чтобы это избежать на стороне клиента и сервера увеличиваем Timeout хотя бы до 10 секунд.