Мониторинг LSI MegaRAID по SNMP

Начнем с небольшой предыстории, поломки дисков на двух-трех десятках серверов дело нечастое и что бы этот процесс контролировать вполне достаточно прислушиваться к крикам юзеров, типа что-то притормаживает, и хоть иногда заглядывать в серверную. И все было бы хорошо пока дело не коснулось старенького сервера Intel SR2500, в который недавно засунули контроллер LSI 9260 и новые жесткие диски по 3Тб. Самое печальное то, что лампочки на его дисках не сигнализируют фактически ни о чем, разве что о изъятии диска из корзины, да и падение производительности при поломке одного диска на не сильно нагруженном сервере мало заметно.

Обычно при необходимости мониторить RAID я брал утилиту для управления контроллером с сайта производителя и писал небольшой bash-скрипт, который в случае появления слова Failed или Degraded слал на почту письмо с криком о помощи. Сейчас же стараюсь уходить от ситуации когда сервер монтиорит сам себя, и контролировать все через центральную систему мониторинга, поэтому мой выбор пал на SNMP.

В статье используется CentOS 6.3 i386.

1. Установка

В первую очередь идем на сайт производителя и скачиваем оттуда MegaRAID Storage Manager для Linux, распаковываем архив и достаем оттуда файлы подходящие для нашей системы. В архиве есть два типа SNMP агентов один для встроенных контроллеров содержащий в названии IR (Integrated RAID), другой для обычных поставляемых в виде платы PCIe.

Устанавливаем необходимые пакеты и LSI SNMP агент из архива.

2. Настройка

По умолчанию snmpd настроен на отдачу только SNMPv2-MIB::system и HOST-RESOURCES-MIB::hrSystemUptime, поэтому для того что бы можно было читать группу OID относящуюся к LSI SNMP агенту придется добавить разрешения на отдачу ветки .1.3.6.1.4.1.3582, или можно воспользоваться готовым файлом настроек от LSI.

Теперь открываем /etc/snmp/snmpd.conf для редактирования, удаляем не нужные и дописываем адреса с которых можно читать данные из public, например адрес сервера Zabbix.

Включаем в автозагрузку и перезапускаем сервис snmpd.

3. SELinux

Как оказалось, LSI SNMP агент не умеет работать с SELinux включенным в принудительном enforcing режиме. Если использовать LSI SNMP агент на локальном файловом сервере, то проще и правильнее всего будет просто отключить SELinux. Для этого открываем в редакторе файл /etc/sysconfig/selinux и меняем в нем параметр SELINUX=enforcing на SELINUX=disabled, а за тем презапускаем систему.
Другой вариант написать дополнительный модуль политики SELinux, он больше подходит для случая когда необходима большая защищенность, например для почтового или веб-сервера. В первую очередь меняем защитный контекст запускаемого файла, который обрабатывает ветку .1.3.6.1.4.1.3582.

Создаем текстовый файл описания модуля политики с именем lsi_snmp.te

Компилируем, собираем и устанавливаем бинарный модуль для SELinux.

Готово, теперь LSI SNMP агент может работать в принудительном режиме SELinux.

4. SNMP

По умолчанию системе установлены только базовые MIB, все параметры которые в них не включены будут отображаться в виде длинных цифровых OID, выискивать среди них при помощи snmpwalk нужные параметры очень не удобно. Добавляем MIB контроллера LSI.

Запускаем snmptranslate для просмотра древовидной структуры.

Если все правильно должна получиться следующая картинка.

Запускаем snmpwalk для просмотра всех параметров

Для настройки мониторинга в Zabbix вполне достаточно добавить всего один параметр LSI-MegaRAID-SAS-MIB::pdDiskFailedCount (.1.3.6.1.4.1.3582.4.1.4.1.2.1.24), и добавить триггер срабатывающий при отличном от нуля значении. Более интересную схему можно построить при помощи низкоуровневого обнаружения появившегося в Zabbix 2.0, подробнее в статье “Настройка низкоуровневого обнаружения в Zabbix”.

8 Коммент. : “Мониторинг LSI MegaRAID по SNMP”

Zabbix lsi megaraid windows

Zabbix template for Intel/LSI/Symbios RAID Controllers

Topic on zabbix forum

Zabbix value mappings for «Template LSI RAID». Should be imported before template via «Administration» -> «General» -> «Value mapping» -> «Import».

LSI RAID BBU & LD Status

LSI RAID PhysDrv Status

• 0 -> (Online|Hostpare|Unconfigured good)
• 1 -> Failed
• 2 -> Rebuild

Zabbix template «Template LSI RAID». Should be imported after Zabbix value mappings via «Configuration» -> «Templates» -> «Import».

Adapter

• Adapter model
• Firmware version

Battery Backup Unit

• BBU State (+trigger)
• BBU State of charge (+trigger)
• BBU manufacture date (disabled by default)
• BBU design capacity (disabled by default)
• BBU current capacity (disabled by default)

Physical drives

• Firmware state (+trigger)
• Predictive errors (+trigger)
• Media errors (+trigger)
• Size
• Model

Logical volumes

• Volume state (+trigger)
• Volume size

3 scripts are available for windows (powershell) and unix (perl) servers

RAID Discovery script

This script is used for Low Level Discovery of RAID configuration. Scripts uses zabbix_sender and agent configuration file to report RAID configuration to zabbix.

RAID checks script

This script is used by zabbix agent to check «non critical» items, such as adapter model, physical drive size, etc. But this script also supports checking of all items from template (i.e. you can change type for all items from ‘Zabbix trapper’ to ‘Zabbix Agent’). I’ve created «trapper» version of this script, because zabbix agent very often reports that some item is not supported (I noticed that problem only on Windows servers). Probably there are some locking occurs, when zabbix agent checks a lot of items at the same time.

RAID «trapper» check script

This scrips reports all values for «critical» items at once. Currently it reports BBU state and state of charge, physical drives state, predictive and media erros, logical volumes states. All other checks are performed by zabbix agent using RAID checks scripts and userparameters.

Discovery and «trapper» scripts are executed by system scheduler.

Agent userparameters:

for agents on unix servers RAID tool should be executed via sudo, add this to sudoers file:

I’m not a programmer, so code review will be appreciated 🙂

Ещё один блог сисадмина

воскресенье, 14 мая 2017 г.

Контроль аппаратного RAID-контроллера LSI MegaRAID SAS во FreeBSD через Zabbix

В этой статье речь пойдёт о RAID-контроллерах FreeBSD, которые управляются драйвером mfi(4). На указанной странице руководства написано, что это драйвер контроллера LSI MegaRAID SAS. На самом же деле я некоторое время использовал описанную ниже схему для RAID-контроллера Intel RS2WC040. Об этом контроллере я ранее уже писал в трёх других статьях:

• Intel RS2WC040 во FreeBSD 8.2
• Сборка RAID-массива на контроллере LSI MegaSAS во FreeBSD
• Решение проблемы с остановкой загрузки из-за RAID-контроллера Intel RS2WC040

Для проверки состояния RAID-контроллера нам понадобятся настроенный Zabbix-агент и пакет sudo.

При помощи команды visudo разрешим пользователям из группы zabbix выполнять от имени пользователя root команды для проверки состояния RAID-массивов и батареи RAID-контроллера:
Впишем в файл конфигурации Zabbix-агента /usr/local/etc/zabbix24/zabbix_agentd.conf соответствующие строки:
Первая команда возвращает количество неисправных RAID-массивов, вторая — количество контроллеров без установленной батареи, третья — количество батарей, не находящихся в статусе normal. То есть, если любое из значений отличается от нуля, то имеются проблемы.

После внесения изменений в конфигурацию Zabbix-агента, не забудьте его перезапустить:
Я подготовил два шаблона для контроля состояния RAID-контроллера:

• Template_App_RAID_mfiutil.xml — шаблон с элементами данных типа «Zabbix-агент»,
• Template_App_RAID_mfiutil_Active.xml — шаблон с элементами данных типа «Zabbix-агент (активный)».

В шаблоне есть три элемента данных. Один контролирует целостность RAID-массивов, второй — наличие батарей в контроллерах, третий — состояние каждой из батарей:

Каждому из упомянутых элементов данных соответствует один триггер:

Почему я оговорился о том, что использовал описанную схему только «некоторое время»? Потому что через некоторое время команда mfiutil переставала работать, выводя в ответ такие вот ошибки:
Это при том, что драйвер загружен в ядро и файлы устройства на месте:
При каждом запуске команды mfiutil в журнале /var/log/messages появляются ошибки такого вида:
Возможно дело в том, что я использую не официальный драйвер, а с официальными драйверами, которые были добавлены в систему в последующих релизах, такой проблемы нет.

Есть сервер, где используется RAID-контроллер немного другой модели — Intel RS2BL040. Эта модель RAID-контроллера поддерживается официальным драйвером и на этом сервере многократные вызовы команды mfiutil не приводят к подобным ошибкам. Но в чём точно дело — в драйвере или в модели контроллера, я с уверенностью сказать не могу. Полагаю, что дело всё же в драйвере. В таком случае, скорее всего, описанная выше схема контроля не будет приводить к проблемам на системах, использующих официальный драйвер mfi.

После того, как я столкнулся с этой проблемой, вместо команды mfiutil я стал использовать команду megacli, собранную из порта sysutils/megacli. Утилита megacli работает безотказно. Правда, описывать контроль RAID-массива с её помощью я не стану — результат получился слишком неуклюжим.

Навигация

Мониторинг LSI MegaRAID в Zabbix

В моем варианте я рассчитываю мониторинг только Adapter #0 т.е. когда в система только одна плата raid контроллера (опция -a0)

Установка скрипта

Создание папки для скриптов:

Создадим сам скрипт:

Настройка прав пользователю zabbix в sudo

Вы должны получить данные, если этого не произошло, то конфигурация выполнена не правильно.

Настройка Zabbix сервера

Вызов скрипта через zabbix-agent

Для контролируемых данных в Zabbix нужно создать соответствующее элементы с типом «Zabbix агент» и ключом типа:

где disk — имя виртуального диска VirtualDrive или слота физического диска DriveSlot
key — контролируемая метрика

Готовый Шаблон для мониторинга LSI MegaRAID (agent) с уже настроенными элементами и графиками.

Результат

Обсуждение

Обнаружил, что не все megacli выдают megacli -LDInfo -LAll -a0 -NoLog|grep «Bad Blocks Exist» В результате этого, происходят алармы для некоторых хостов — LSIMegaRaid: VirtualDrive0 Bad Blocks Exist on hostname. Сможете сделать отдельную проверку на наличие строки в выхлопе megacli?

и дезактивируйте элемент для таких хостов

Второй вариант, который я предложил предпочтителен, серверов очень много, везде править это дикий костыль. Спасибо.

Спасибо за скрипт и шаблон !

Правда что то не хочет работать 🙁

Ошибка в заббиксе. Value should be a JSON object.

Мониторинг различных RAID массивов с помощью Zabbix

Есть у меня в парке серверов множество различных рейд-контроллеров, в том числе софтовых(mdadm). У каждого из них имеются различные средства мониторинга, но хотелось бы все это отслеживать централизовано, например через zabbix, а в случае изменения состояния любого из массивов — получать уведомления, например по почте. Данная статья не является пошаговым руководством, а представляет из себя набор заметок на память для различных контроллеров. В каждом подразделе описана техника получения информации о состоянии массивов zabbix-агентом.

mdadm

В Linux mdadm есть файл /proc/mdstat, в котором содержится информаци о всех массивах и их состоянии. У каждого массива есть вот такое текстовое обозначение: [UU] (кол-во букв U зависит от кол-ва дисков в массиве). Если один или более дисков выходит из строя, то вместо буквы U появляется знак подчеркивания: _ Соответственно ищем подобные массивы и подсчитываем их кол-во, если их больше 0, то поднимаем панику. В конфиге агента добавляем такой пользовательский параметр:

Как видно, параметр вернул ноль( [t|0] ), все нормально.

3Ware

Для мониторинга контроллеров 3ware (теперь уже LSI) понадобится утилита 3w_cli, скачать ее можно с оф. сайта производителя контроллера, либо поставить из стороннего репозитория(в случае с debian): hwraid.

Утилита 3w_cli работает только из под рута, поэтому нужно установить sudo и в конфиге разрешить забиксу без пароля запуск утилиты, добавляем в конец /etc/sudoers:

Теперь добавляем в конфиг забикса пользовательский параметр:

Этот параметр аналогичным образом подсчитывает кол-во массивов(на первом контроллере), которое имеет статус «Not Optimal». Если в сервере установлено несколько контроллеров, то можно будет сделать скрипт с несколькими подобными командами и в конце сумировать результат.

Все массивы в норме ([t|0]).

Adaptec

Для мониторинга контроллеров Adaptec понадобится утилита arcconf, скачать ее можно с оф. сайта производителя контроллера, либо поставить из стороннего репозитория(в случае с debian): hwraid.

В конфиг zabbix-агента добавляем следующий пользовательский параметр:

Этот параметр производит подсчет кол-ва массивов первого контроллера, статус которых отличается от «Optimal». Если в системе более одного контроллера, то нужно создать скрипт, который будет выполнять подобную команду для каждого контроллера и суммировать результат.

Все нормально, кол-во отказавших массивов ноль ([t|0]).

LSI(IBM)

В серверах IBM серии X, например x3650 ставят контроллеры LSI, которые управляются утилитой megacli, скачать ее можно с сайта IBM(например ibm_utl_sraidmr_megacli-8.04.10_linux_32-64.zip). Есть пакеты только для redhat и suse, но не составляет труда конвертировать их в deb с поомщью alien. Делается это командой:

После конвертирования устанавливаем пакеты и добавляем пользовательский параметр в zabbix-агент:

Этот параметр выполняет подсчет всех массивов со статусом отличным от «Optimal».

LSI(Intel)

Пример создания тригера

Создадим тригер отслеживания состояния массивов на примере 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: