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

Статистика ввода-вывода iostat во FreeBSD через Zabbix

Для оценки производительности дисковой подсистемы FreeBSD можно воспользоваться утилитой iostat. Однако полную картину нагрузки на дисковую подсистему можно получить только собирая статистику за достаточно долгий срок. Как минимум это сутки, а лучше всего собрать статистику за неделю. По недельной статистике можно легко найти периоды максимальной нагрузки и связать их с периодически выполняющимися в системе задачами. Имея статистику за неделю, можно подобрать оптимальное время запуска процедуры резервного копирования. В этой статье речь пойдёт о том, как собирать статистику от утилиты iostat в Zabbix.

Для начала изучим документацию на саму команду iostat из состава FreeBSD. Простой вызов команды iostat отображает статистику дисковых устройств вместе со статистикой процессора и терминала. К счастью, у команды iostat имеется несколько опций, полезных для наших целей:
  • -d - отображать только статистику по дисковым устройствам,
  • -x - отобразить расширенную статистику,
  • -I - отображать счётчики нарастающим итогом, а не среднюю статистику за период времени.
Последняя опция - самая полезная. В интернете можно встретить шаблоны, в которых для сбора статистики команда iostat запускается на определённый интервал времени. У такого подхода есть как минимум два недостатка. Во-первых, в промежутках между запусками iostat статистика не собирается. Во-вторых, из-за того, что команда выполняется долго, используют промежуточный файл, в который периодически сохраняют собранную статистику, а потом извлекают из этого файла с помощью команд grep или awk. В общем, увидев в какой-нибудь очередной статье в интернете такой способ съёма статистики, я морщусь и перехожу к другой статье.

Команда iostat, вызванная со всеми этими опциями, выведет примерно такой результат:
# iostat -dxI
extended device statistics  
device     r/i   w/i    kr/i    kw/i wait svc_t  %b  
mfid0    6994332913.0 13128877288.0 544161035422.5 493573917948.0    0   5.1  18
Смысл столбцов такой:
  • device - имя файла устройства в файловой системе /dev,
  • r/i - количество операций чтения за период времени,
  • w/i - количество операций записи за период времени,
  • kr/i - прочитано килобайт за период времени,
  • kw/i - записано килобайт за период времени,
  • wait - длина очереди транзакций,
  • svc_t - средняя длительность транзакций в миллисекундах,
  • %b - процент времени, когда на устройстве была одна или более невыполненных транзакций.
Несмотря на то, что указана опция -I, предписывающая выводить накопленные значения счётчиков, числа в последних трёх колонках являются текущими средними значениями. Если судить по страницам руководства на официальном сайте, эти колонки стали показывать накопленные значения счётчиков только начиная с FreeBSD 10: FreeBSD 10.0-RELEASE iostat(8). У меня FreeBSD 10 пока нигде нет, поэтому отладить шаблон для соответствующих версий iostat пока возможности не было.

Добавим в файл конфигурации Zabbix-агента /usr/local/etc/zabbix24/zabbix_agentd.conf следующие строки:
UserParameter=iostat.discovery,iostat -dxI | awk 'BEGIN { printf "{\"data\":["; } { if (NR > 3) printf ","; if (NR > 2) printf "{\"{#DEVNAME}\":\"" $1 "\"}"; } END { printf "]}"; }'
UserParameter=iostat.read.ops[*],/usr/sbin/iostat -dxI | awk '$$1 == "$1" { print $$2; }'
UserParameter=iostat.write.ops[*],/usr/sbin/iostat -dxI | awk '$$1 == "$1" { print $$3; }'
UserParameter=iostat.read.bytes[*],/usr/sbin/iostat -dxI | awk '$$1 == "$1" { print 1024 * $$4; }'
UserParameter=iostat.write.bytes[*],/usr/sbin/iostat -dxI | awk '$$1 == "$1" { print 1024 * $$5; }'
UserParameter=iostat.queue.length[*],/usr/sbin/iostat -dxI | awk '$$1 == "$1" { print $$6; }'
UserParameter=iostat.transactions.duration[*],/usr/sbin/iostat -dxI | awk '$$1 == "$1" { print $$7; }'
UserParameter=iostat.busy.duration[*],/usr/sbin/iostat -dxI | awk '$$1 == "$1" { print $$8; }'
После внесения изменений в файл конфигурации Zabbix-агента, не забудьте его перезапустить:
# /usr/local/etc/rc.d/zabbix_agentd restart
Я подготовил два варианта шаблона:
В шаблоне имеется правило низкоуровневого обнаружения, которое находит все дисковые устройства, статистику по которым выдаёт iostat:

Для каждого найденного устройства создаётся семь элементов данных, соответствующих колонкам из вывода iostat:

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

Элемент данных с названием "Загрузка диска" показывает процент времени, в течение которого диск занимается обработкой хотя бы одной транзакции.

воскресенье, 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 и отличаются от них только именами.