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

Контроль параметров S.M.A.R.T. жёстких дисков через Zabbix

Специально для контроля исправности жёстких дисков была придумана технология S.M.A.R.T.. Если все жёсткие диски компьютера включены в состав RAID-массива с избыточностью, то следить за параметрами S.M.A.R.T. обычно не имеет особого смысла - о выходе из строя одного из жёстких дисков можно узнать по факту. Однако, не всегда бывает оправдано использовать RAID-массивы. Иногда это бывает малокритичный сервер, на котором не хранится никаких данных и который можно довольно быстро настроить с нуля на новом компьютере. А может быть это один из однотипных серверов, между которыми распределяется общая нагрузка. В таких случаях может оказаться полезным отслеживать состояние жёсткого диска через S.M.A.R.T., чтобы устранить проблему не в режиме аварийно-восстановительных, а в режиме планово-профилактических работ, заранее подготовив замену, с минимальным перерывом в обслуживании и во время наименьшей нагрузки (или её отсутствия).

Для контроля параметров S.M.A.R.T. на компьютере понадобится настроенный Zabbix-агент, а также установленные пакеты sudo и smartmontools.

Во-первых, при помощи команды visudo, разрешим пользователям из группы zabbix выполнять команды для контроля состояния диска от имени пользователя root:
%zabbix    ALL=(ALL) NOPASSWD:/usr/sbin/smartctl --scan, \
                              /usr/sbin/smartctl -i *, \
                              /usr/sbin/smartctl -H *, \
                              /usr/sbin/smartctl -A *
Во-вторых, добавим в файл конфигурации Zabbix-агента /etc/zabbix/zabbix_agentd.conf следующие "пользовательские параметры":
UserParameter=smartctl.list,/usr/bin/sudo /usr/sbin/smartctl --scan | awk 'BEGIN { printf "{\"data\": ["; } { if (NR != 1) printf ","; printf "{\"{#SMART}\": \"%s\"}", $1; } END { printf "]}"; }'
UserParameter=smartctl.model[*],/usr/bin/sudo /usr/sbin/smartctl -i $1 2>& | /usr/bin/awk -F: '$$1 ~ /^Device Model$/ { gsub(/(^ +| +$)/, "", $$2); print $$2; }'
UserParameter=smartctl.serial[*],/usr/bin/sudo /usr/sbin/smartctl -i $1 2>& | /usr/bin/awk -F: '$$1 ~ /^Serial Number$/ { gsub(/(^ +| +$)/, "", $$2); print $$2; }'
UserParameter=smartctl.health[*],/usr/bin/sudo /usr/sbin/smartctl -H $1 2>& | /usr/bin/awk 'BEGIN { h = 0; } / (OK|PASSED)$/ { h = 1; } END { print h; }'
UserParameter=smartctl.reallocated[*],/usr/bin/sudo /usr/sbin/smartctl -A $1 2>& | awk '/^  5 / { print $$10; }'
UserParameter=smartctl.pending[*],/usr/bin/sudo /usr/sbin/smartctl -A $1 2>& | awk '/^197 / { print $$10; }'
UserParameter=smartctl.temperature[*],/usr/bin/sudo /usr/sbin/smartctl -A $1 2>& | awk '/^194 / { print $$10; }'
После внесения изменений в конфигурацию Zabbix-агента, не забудьте его перезапустить:
# /etc/init.d/zabbix-agent restart
Я подготовил два шаблона для контроля параметров S.M.A.R.T.:
В обоих шаблонах имеется элемент данных для низкоуровневого обнаружения, который находит все имеющиеся в системе диски, поддерживающие S.M.A.R.T.:

Есть прототипы элементов данных, с помощью которых контролируется: статус здоровья диска, количество перемещённых секторов, секторов, ожидающих перемещения, температура жёсткого диска. Значения этих данных для каждого из жёстких дисков снимаются раз в 10 минут. Раз в час для каждого жёсткого диска запрашивается модель и серийный номер - они могут пригодиться, когда понадобится заменить один из жёстких дисков:

Имеется три прототипа триггеров, который будут созданы для каждого обнаруженного жёсткого диска. Самый главный триггер срабатывает в том случае, когда S.M.A.R.T. явным образом сообщает о неисправности диска. Два других триггера срабатывают при превышении лимита неисправных секторов или секторов, ожидающих перемещения:

Лимиты для двух последних триггеров можно задать через соответствующие макросы - {$SMART_REALLOCATED_LIMIT} и {$SMART_PENDING_LIMIT}:

На картинке заданы нулевые лимиты, поэтому триггеры будут срабатывать при появлении хотя бы одного подозрительного сектора на диске. Если вы посчитали, что проблемных секторов не так уж и много, то можно задать новые значения макросов индивидуально в самом наблюдаемом узле Zabbix. К сожалению, нельзя задать разные лимиты для разных жёстких дисков - макросы действуют на все диски в наблюдаемом узле. С другой стороны, если лимит повысили для одного жёсткого диска, то логично что и на другом жёстком диске не стоит бить тревогу, пока этот лимит не будет достигнут.

S.M.A.R.T. умеет отдавать массу другой информации о состоянии диска. Довольно подробный список параметров есть на уже упомянутой странице в Wikipedia: S.M.A.R.T. Не всегда S.M.A.R.T. успевает сообщить о неисправности жёсткого диска до того, как им и в самом деле становится невозможно пользоваться. Именно для этого я и добавил контроль двух выбранных мной параметров - количества перемещённых секторов и количества секторов, ожидающих перемещения. В случае роста этих счётчиков, можно заранее понять, что скоро S.M.A.R.T. может сообщить о неисправности диска. Иногда, правда, жёсткие диски продолжают исправно работать долгие годы, даже если на них уже есть десятки или даже сотни неисправных секторов. Поэтому вместо использования конкретных значений порогов срабатывания триггеров я и предусмотрел в шаблоне макросы, чтобы пороги можно было настраивать по месту. Лучше, всё же, не ждать появления десятков или сотен неисправных секторов, а менять диск заранее.

Наконец, снимаемые данные выглядят следующим образом:

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

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

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

При помощи команды visudo разрешим пользователям из группы zabbix выполнять от имени пользователя root команды для проверки состояния RAID-массивов и батареи RAID-контроллера:
%zabbix     ALL=(ALL) NOPASSWD:/usr/sbin/mfiutil show volumes, \
                               /usr/sbin/mfiutil show adapter, \
                               /usr/sbin/mfiutil show battery
Впишем в файл конфигурации Zabbix-агента /usr/local/etc/zabbix24/zabbix_agentd.conf соответствующие строки:
UserParameter=raid.mfiutil,sudo /usr/sbin/mfiutil show volumes | fgrep RAID | fgrep -vc OPTIMAL
UserParameter=raid.mfiutil.battery.present,sudo /usr/sbin/mfiutil show adapter | fgrep 'Battery Backup' | grep -vc present
UserParameter=raid.mfiutil.battery.status,sudo /usr/sbin/mfiutil show battery | fgrep Status | fgrep -vc normal
Первая команда возвращает количество неисправных RAID-массивов, вторая - количество контроллеров без установленной батареи, третья - количество батарей, не находящихся в статусе normal. То есть, если любое из значений отличается от нуля, то имеются проблемы.

После внесения изменений в конфигурацию Zabbix-агента, не забудьте его перезапустить:
# /etc/init.d/zabbix-agent restart
Я подготовил два шаблона для контроля состояния RAID-контроллера:
В шаблоне есть три элемента данных. Один контролирует целостность RAID-массивов, второй - наличие батарей в контроллерах, третий - состояние каждой из батарей:

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

Почему я оговорился о том, что использовал описанную схему только "некоторое время"? Потому что через некоторое время команда mfiutil переставала работать, выводя в ответ такие вот ошибки:
# mfiutil show volumes
mfiutil: Failed to get volume list: No such file or directory
# mfiutil show battery
mfiutil: Failed to get capacity info: No such file or directory
Это при том, что драйвер загружен в ядро и файлы устройства на месте:
# kldstat -v | grep mfi
  153 mfi/mfisyspd
  152 mfi/mfid
  151 pci/mfi
# ls /dev/mfi*
/dev/mfi0 /dev/mfid0 /dev/mfid0s1 /dev/mfid0s1a /dev/mfid0s1b
При каждом запуске команды mfiutil в журнале /var/log/messages появляются ошибки такого вида:
kernel: mfi0: IOCTL 0xc0404366 not handled
Возможно дело в том, что я использую не официальный драйвер, а с официальными драйверами, которые были добавлены в систему в последующих релизах, такой проблемы нет.

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

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

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

Контроль программного RAID-массива FreeBSD через Zabbix

Совсем короткая статья про контроль программных RAID-массивов FreeBSD, созданных средствами gmirror. На этот раз кроме установленного и настроенного в системе Zabbix-агента не понадобится более никаких дополнительных пакетов.

Впишем в файл конфигурации Zabbix-агента /usr/local/etc/zabbix24/zabbix_agentd.conf всего одну строчку:
UserParameter=raid,/sbin/gmirror status -s 2>/dev/null | fgrep -vc COMPLETE
Команда gmirror status с ключом -s выводит состояние каждого диска, состоящего в каком-либо RAID-массиве, в одной строке. Команда fgrep -vc COMPLETE считает количество строчек, в которых нет статуса COMPLETE, который соответствует исправному состоянию диска в массиве. В итоге, если элемент данных raid равен нулю, то все RAID-массивы исправны.

После внесения изменений в конфигурацию Zabbix-агента, не забудьте его перезапустить:
# /etc/init.d/zabbix-agent restart
Я подготовил два шаблона для контроля параметров исправности RAID-массивов:
В шаблоне есть всего один элемент данных, контролирующий количество неисправных элементов RAID-массивов:

И всего один триггер, который срабатывает при наличии хотя бы одного неисправного элемента хотя бы одного RAID-массива:

По сути, оба шаблона полностью аналогичны шаблонам для контроля программных RAID-массивов Linux и отличаются от них только именами.