Zabbix + Iostat: мониторинг дисковой подсистемы
Zabbix + Iostat: мониторинг дисковой подсистемы.
Зачем?
Дисковая подсистема одна из важных подсистем сервера и от уровня нагрузки на дисковую подсистему зачастую зависит очень многое, например скорость отдачи контента или то как быстро будет отвечать база данных. Это в большей степени относится к почтовым или файловым серверам, серверам БД. Вобщем, показатели дисковой производительности отслеживать нужно. На основании графиков производительности дисковой подсистемы мы можем принять решение о необходимости наращивания мощностей задолго до того как петух клюнет. Да и вобще полезно поглядывать от релиза к релизу как работа разработчиков сказывается на уровне нагрузки.
Под катом, о мониторинге и о том как настроить.
Зависимости:
Мониторинг реализован через zabbix агента и две утилиты: awk и iostat (пакет sysstat). Если awk идет в дистрибутивах по умолчанию, то iostat требуется установить с пакетом sysstat (тут отдельное спасибо Sebastien Godard и сотоварищи).
Известные ограничения:
Для мониторинга нужен sysstat начиная с версии 9.1.2, т.к. там есть очень важное изменение: «Added r_await and w_await fields to iostat’s extended statistics». Так что следует быть внимательным, в некоторых дистрибутивах, например в CentOS немного «стабильная» и менее фичастая версия sysstat.
Если же отталкиваться от версии zabbix (2.0 или 2.2) то тут вопрос не принципиален, работает на обоих версиях. На 1.8 не заработает т.к. используется Low level discovery.
- Low level discovery (далее просто LLD) для автоматического обнаружения блочных устройств на наблюдаемом узле;
- утилизация блочного устройства в % — удобная метрика для отслеживания общей нагрузки на устройстве;
- latency или отзывчивость — доступна как общая отзывчивость, так и отзывчивость на операциях чтения/записи;
- величина очереди (в запросах) и средний размер запроса (в секторах) — позволяет оценить характер нагрузки и степень загруженности устройства;
- текущая скорость чтения/записи на устройство в человекопонятных килобайтах;
- количество запросов чтения/записи (в секунду) объединенных при постановке в очередь на выполнение;
- iops — величина операций чтения/записи в секунду;
- усредненное время обслуживания запросов (svctm). Вообще она deprecated, разработчики обещают ее давно спилить, но все никак руки не доходят.
- Disk await — отзывчивость устройства (r_await, w_await);
- Disk merges — операции слияния в очереди (rrqm/s, wrqm/s);
- Disk queue — состояние очереди (avgrq-sz, avgqu-sz);
- Disk read and write — текущие значения чтения/записи на устройство (rkB/s, wkB/s);
- Disk utilization — утилизация диска и значение IOPS (%util, r/s, w/s) — позволяет неплохо отслеживать скачки в утилизации и чем, чтением или записью они были вызваны.
Где взять:
Итак, мониторинг состоит из файла конфигурации для агента, двух скриптов для сбора/получения данных и шаблон для веб-интерфейса. Все это доступно в репозитории на Github, поэтому любым доступным способом (git clone, wget, curl, etc. ) скачиваем их на машины которые хотим замониторить и переходим к следующему пункту.
- iostat.conf — содержимое этого файла следует поместить в файл конфигурации zabbix агента, либо положить в каталог конфигурации который указан в Include опции основной конфигурации агента. Вобщем зависит от политики партии. Я использую второй вариант, для кастомных конфигов у меня отдельная директория.
- scripts/iostat-collect.sh и scripts/iostat-parse.sh — эта два рабочих скрипта следует скопировать в /usr/libexec/zabbix-extensions/scripts/. Тут также можно использовать удобное вам размещение, однако в таком случае не забудьте поправить пути в параметрах определенных в iostat.conf. Не забудьте проверить что они исполняемы (mode=755).
# zabbix_get -s agent_ip -k iostat.discovery
Таким образом, проверяем с сервера мониторинга что iostat.conf подгрузился и отдает информацию, заодно смотрим что LLD работает. В качестве ответа вернется JSON с именами обнаруженных устройств. Если ответа не пришло, значит что-то сделали не так.
Также есть такой момент, что zabbix server не дожидается выполнения некоторых item’ов со стороны агентов (iostat.collect). Для этого следует увеличить значения Timeout.
Как настроить в web интейрфейс:
Теперь остался шаблон iostat-disk-utilization-template.xml. Через веб интерфейс импортируем его в раздел шаблонов и назначем на наш хост. Тут все просто. Теперь остается ждать примерно один час, такое время установлено в LLD правиле (тоже настраивается). Или можно поглядывать в Latest Data наблюдаемого хоста, в раздел Iostat. Как только там появились значения, можно перейти в раздел графиков и понаблюдать за первыми данными.
И напоследок тройка скринов графиков c локалхоста))):
Непосредственно данные в Latest Data:
Графики отзывчивости (Latency):
График утилизации и IOPS:
Вот и собственно и все, спасибо за внимание.
Ну и по традиции, пользуясь случаем передаю привет Федорову Сергею (Алексеевичу) 🙂
Мониторинг дисков ZABBIX
Рано или поздно у вас появится необходимость отслеживать производительность дисковой подсистемы серверов, как виртуальных, так и физических. Если вы все ещё это не делаете, то обязательно скоро придется . Почему? — если оперативную память, процессорную мощность и объем долговременной памяти можно считать константами, то этого нельзя сказать о производительности дисковой подсистемы. Во-первых, потому что рабочая нагрузка на серверы обычно растет со временем (даже если взять за основу постоянное количество сотрудников компании), а производительность дисков со временем деградирует и их надо менять, во-вторых, традиционно большинство администраторов учитывают лишь мощность cpu и объем ram и никто не утруждает себя подсчетом необходимых iops-ов. Если с windows-системами все достаточно просто и работает что называется «из коробки» (я о счетчиках производительности), то с Unix-системами все обстоит сложнее. Благо в сети есть достаточно объемные и подробные инструкции с готовыми скриптами для постановки на мониторинг показателей производительности дисковой подсистемы. Использование одной из них я планирую максимально подробно описать в этой статье.
Вводная статья по шаблонам мониторинга ZABBIX — Шаблоны ZABBIX.
Если вам интересна тематика ZABBIX, рекомендую обратиться к основной статье — Система мониторинга ZABBIX, в ней вы найдете дополнительную информацию.
Исходные данные
Настройка zabbix-агента будет проводиться на самом zabbix-сервере, ОС — Debian 7.7. Все необходимые скрипты и файлы конфигураций можно найти тут. Небольшое «введение» можно прочитать в статье «Zabbix + Iostat: мониторинг дисковой подсистемы«.
Мониторинг дисков ZABBIX — Настройка
Необходимо поставить пакет «sysstat», в котором находится необходимая нам утилита «iostat»:
root@debian7:~# apt-get install sysstat
Вспомним где у нас лежат конфигурационные файлы zabbix-агента:
root@debian7:~# find / -name «zabbix_agentd.conf»
/usr/local/etc/zabbix_agentd.conf
Перейдем в папку с конфигурационными файлами:
root@debian7:~# cd /usr/local/etc/
Создадим папки для будущих скриптов и файлов конфигураций и сразу установим к ним права:
root@debian7:/usr/local/etc# mkdir -m 755 zabbix_agent_configs
root@debian7:/usr/local/etc# mkdir -m 755 zabbix_agent_scripts
Вернемся в корневую директорию:
root@debian7:/usr/local/etc# cd
Создадим файл iostat.conf в директории с конфигурационными файлами zabbix-агента
root@debian7:~# nano /usr/local/etc/zabbix_agent_configs/iostat.conf
# Disk statistics via iostat (sysstat)
# Attention: Second parameter in iostat.collect must be less than Timeout option in zabbix_agentd.conf
UserParameter=iostat.discovery, iostat -d | awk ‘BEGINif($1==»Device:»)> END \»:\»%s\»>», array[i]); if(i+1 > printf(«]>\n»);>’
UserParameter=iostat.collect,/usr/local/etc/zabbix_agent_scripts/iostat-collect.sh /tmp/iostat.out 8 || echo 1
UserParameter=iostat.metric[*],/usr/local/etc/zabbix_agent_scripts/iostat-parse.sh /tmp/iostat.out $1 $2
root@debian7:~# nano /usr/local/etc/zabbix_agent_scripts/iostat-collect.sh
#!/usr/bin/env bash
# Description: Script for iostat monitoring
# Author: Epikhin Mikhail michael@nomanlab.org
# Revision 1: Lesovsky A.V. lesovsky@gmail.comSECONDS=$2
TOFILE=$1
IOSTAT=»/usr/bin/iostat»[[ $# -lt 2 ]] &&
DISK=$($IOSTAT -x 1 $SECONDS | awk ‘BEGIN
if(check==1 && $1!=»»)if($1==»Device:»)>’ | tr ‘\n’ ‘|’)
echo $DISK | sed ‘s/|/\n/g’ > $TOFILE
echo 0
root@debian7:/usr/local/etc# nano /usr/local/etc/zabbix_agent_scripts/iostat-parse.sh
Выставим на оба скрипта необходимые права:
root@debian7:~# chmod 755 /usr/local/etc/zabbix_agent_scripts/iostat-collect.sh
root@debian7:~# chmod 755 /usr/local/etc/zabbix_agent_scripts/iostat-parse.sh
Отредактируем файл конфигурации агента:
root@debian7:~# nano /usr/local/etc/zabbix_agentd.conf
Нам нужен параметр «Include«, задаем ему следующее значение:
Include=/usr/local/etc/zabbix_agent_configs
Структура каталогов должна выглядеть примерно следующим образом, если вы настраивали все точно также как и я:
Перезапускаем агента:
root@debian7:~# service zabbix-agent restart
Проверяем подцепляется ли конфигурационный файл с пользовательскими параметрами (можно воспользоваться любой командой):
root@debian7:~# zabbix_agentd -t iostat.discovery
root@debian7:~# zabbix_get -s 127.0.0.1 -p 10050 -k iostat.discovery
Должно получиться что-то на подобии этого:
Дальше необходимо добавить шаблон мониторинга на наш zabbix-сервер через web-интерфейс. Для этого проходим в Настройка>Шаблоны, нажимаем справа вверху «Импорт» и загружаем шаблон «iostat-disk-utilization-template.xml». Подцепляем шаблон к узлам мониторинга — Узлы сети > выбираем нужный узел > вкладка «Шаблоны» > соединяем с новым шаблоном > нажимаем «Добавить» > нажимаем «Обновить».
У автора скриптов есть одна непримечательная заметка:
Attention: Second parameter in iostat.collect must be less than Timeout option in zabbix_agentd.conf
Игнорировать её не стоит, иначе работать скрипты не будут. Для исправления заходим в конфигурационный файл zabbix-агента:
root@debian7:~# nano /usr/local/etc/zabbix_agentd.conf
Ищем опцию «Timeout» и задаем ей значение больше, чем в скрипте, например:
То же самое делаем в файле конфигурации zabbix-сервера:
root@debian7:~# nano /usr/local/etc/zabbix_server.conf
На этом настройка завершена, данные должны приходить. Чтобы не быть голословным, приведу пару скриншотов, свидетельствующих хотя бы то, что у меня все работает:
Подробнее о параметрах «iostat» можно прочитать в «манах», но на всякий случай опубликую описания тут:
avgqu-sz — The average queue length of the requests that were issued to the device.
avgrq-sz — The average size (in sectors) of the requests that were issued to the device.
await — The average time (in milliseconds) for I/O requests issued to the device to be served. This includes the time spent by the requests in queue and the time spent servicing them.
r_await — The average time (in milliseconds) for read requests issued to the device to be served. This includes the time spent by the requests in queue and the time spent servicing them.
rsec/s (rkB/s, rMB/s) — The number of sectors (kilobytes, megabytes) read from the device per second.
r/s — The number (after merges) of read requests completed per second for the device.
rrqm/s — The number of read requests merged per second that were queued to the device.
%util — Percentage of CPU time during which I/O requests were issued to the device (bandwidth utilization for the device). Device saturation occurs when this value is close to 100%.
w_await — The average time (in milliseconds) for write requests issued to the device to be served. This includes the time spent by the requests in queue and the time spent servicing them.
w/s — The number (after merges) of write requests completed per second for the device.
wrqm/s — The number of write requests merged per second that were queued to the device.
wsec/s (wkB/s, wMB/s) — The number of sectors (kilobytes, megabytes) written to the device per second.
Кому интересно, можно почитать немного отличающиеся варианты реализации мониторинга нагрузки на жесткие диски: