zabbix disk utilization что это
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.
Где взять:
Итак, мониторинг состоит из файла конфигурации для агента, двух скриптов для сбора/получения данных и шаблон для веб-интерфейса. Все это доступно в репозитории на Github, поэтому любым доступным способом (git clone, wget, curl, etc. ) скачиваем их на машины которые хотим замониторить и переходим к следующему пункту.
Таким образом, проверяем с сервера мониторинга что 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: Windows IOPS
Сегодня мы попробуем сделать тоже самое, но уже в windows окружении.
Windows в фоновом режиме самостоятельно обсчитывает определенный набор метрик, делается это через «Perfomance Monitor» доступ к которому в zabbix реализуется через функцию «perf_counter».
На вход perf_counter получает «имя» счетчика, и это первый подводный камень.
В Интернете можно найти несколько вариантов обозначения одного и того же счетчика, например:
perf_counter[\PhysicalDisk(_Total)\Disk Reads/sec] perf_counter[\Физический диск(_Total)\Обращений чтения с диска/с] perf_counter[\234(_Total)\214]
Несмотря на различия, это действительно один и тот же счетчик.
Первый два характерны для разных локаций windows и использовать их в мониторинге мы не будем, т.к. под русской windows не будут работать английские счетчики и наоборот.
Третий вариант стоит назвать универсальным, т.к. он работает везде, но «overhead» в интуитивной непонятности обозначений.
Несколько вариантов получить счетчики:
В «lodctr» мы видим сопоставление цифр и названий счетчиков:
В качестве примера, я сделал шаблон для «Disk I/O Operations» и «File I/O Operations» диска «Total». Особенность шаблона, что он не требует никаких изменений конфигурации zabbix на клиентах.
Disk I/O Operations
График показывает общее количество операций ввода\вывода, обработанных (завершенных) диском в течении 1 секунды (Input/Output Operations Per Second, IOPS). Этот счетчик позволяет примерно оценить, насколько нагрузка на диски близка к предельной.
File I/O Operations
Если нужна расшифровка по всем дискам, то уже потребуется изменение конфигурации zabbix, путем добавления нового UserParameter: объявляем переменную windowsdisk.discovery с запуском powershell скрипта:
get_disks.ps1:
Результатом будет json с количеством дисков:
На основе данного discovery можно снимать необходимое вам количество метрик и строить графики, но это тема для отдельного поста.
Zabbix: Linux IOPS при помощи iostat
IOPS (аббревиатура от англ. input/output operations per second — количество операций ввода-вывода в секунду; произносится как «ай-опс») — количество операций ввода-вывода, выполняемых системой хранения данных, за одну секунду. Один из параметров, используемых для сравнения систем хранения данных (жёстких дисков (НЖМД), твердотельных накопителей (SSD), сетевых хранилищ SAN, NAS) и оценки их производительности. (с) https://ru.wikipedia.org/wiki/IOPS
Про мониторинг дисковой системы при помощи Zabbix написано достаточно много материала (например хабр). Независимо от степени влияния, мониторить надо не только для отслеживания роста систем, но чтобы избежать системных ошибок, там где их быть не должно.
Ниже график одного балансировщика на windows у которого снесло крышу: слева было — справа стало (экономия 3000 iops):
На github выложил переделанный шаблон для zabbix и манифест для puppet: zabbix Linux IOPS Iostat
Для работы требуется Linux пакет «sysstat«. Переделка заключается в добавлении агрегированного диска с названием «total», к сожалению делать агрегат по «items» в grafana достаточно дорогая операция для zabbix и выполнить агрегат на клиенте скриптами оказывается в итоге дешевле.
Мониторинг производительности дисковой подсистемы при помощи zabbix и block stat
Вряд ли кто-то будет спорить, что наблюдение за производительностью дисковой подсистемы — чуть ли не важнейшая задача для всех высоконагруженных систем хранения и баз данных. Я изначально столкнулся с этим давным-давно, еще когда приходилось наблюдать за PostgreSQL. В последнее время вернулся к этому вопросу в связи с необходимостью тестирования различных хранилищ.
Сегодня хочу поделиться с сообществом своим текущим опытом на реальном примере zabbix и его связке с block stat.
Небольшое отступление
Я являюсь архитектором баз данных и систем хранения очень высокой производительности и больших объемов. Поэтому часто сталкиваюсь с задачами оценки, как те или иные параметры настройки системы влияют на работу СХД, какие железные конфигурации СХД лучше.
Да есть куча утилит, которая позволит протестировать диски, например тот же fio. Но ничто не сравнится с тестированием реальной нагрузкой.
Когда то давным-давно для этих целей использовал iostat, лютый парсер к нему и gnuplot, и даже написал статейку habr.com/post/165855. Скажу я вам – это жутко неудобно.
Куда как удобнее натравить на систему zabbix и мониторить. А к zabbix можно прикрутить модную Grafana и мониторить красиво. Сразу скажу – выбор zabbix скорее исторический: «потому что он уже был».
Мониторинг дисков в zabbix
Справедливости ради скажу, что в zabbix уже есть встроенные ключи vfs.dev.*, но увы очень мало: скорость чтения и записи, объем.
Практика показывает что ключевые метрики по которым можно оценивать дисковую подсистему это:
Все эти метрики есть в iostat. Но как их положить в zabbix?
Легкое гугление приводит нас к различным парсерам iostat, в том числе и здесь.
Но мне по душе другой вариант, а именно парсинг вывода /sys/class/block/*/stat
Данные в zabbix мы будем собирать при помощи zabbix-agent, создав пользовательские ключи. Для этого в /etc/zabbix/zabbix_agentd.d нужно создать файлик userparameter_custom.vfs.conf примерно со следующим содержимым:
В этом файлике статистики всего 11 колонок, посмотреть их описание можно вот тут.
Колонка №10 это io_tics — количество миллисекунд затраченным устройством на ввод вывод. Как почти все параметры — эта цифра является аккумулятором и постоянно возрастает. Как же получить из них привычные метрики.
Утилизация дисковой подсистемы
Чтобы получить эту цифру — надо взять значение 10 колонки файла статистики и запомнить его в zabbix как скорость изменения в секунду, не забыв умножить на 0.1 так как значение в статистике в миллисекундах, а нам нужны проценты.
Аналогичным образом можно посчитать нагрузку записью/чтением (колонки write_ticks / read_ticks).
Время обработки запроса
Эта метрика аналогична r_svctime и w_svctime для записи и чтения соответственно. По сути это усредненное время обработки запросов за интервал между опросами.
Данная метрика чуть посложнее. Рассмотрим на примере запросов на запись.
Для этого нам понадобится создать три ключа:
Пропускная способность
Метрика показывающая с какой скоростью данные были записаны или прочитаны
Для этой метрики используются колонки №3 read sectors и №5 write sectors. Значение сколько было прочитано или записано «секторов». Точно так же в zabbix сохраняем как изменение за секунду.
Количество операций ввода-вывода в секунду
Эта метрика — те самые пресловутые IOPS
Самая простая метрика — мы ее уже записывали для подсчета svc time это значение колонок №5 write I/Os и №1 read I/Os также сохраненные как скорость в секунду.
Заключение
Этих метрик мне как правило достаточно для того чтобы я мог делать обоснованные выводы. Конечно это не все цифры которые можно получить из файла статистики. Например там есть и число текущих обрабатываемых запросов, и количество запросов которые были объеденены. Но полагаю при необходимости вам не составит труда добавить их по аналогии с описанным.
И да не претендую на авторство — сам метод был когда-то давно загуглен, но за давностью лет ссылки конечно затерялись.
Увы NDA заставляет кое-что подчистить из них, но надеюсь на работоспособность шаблона это не повлияет.
А в шапке скриншот из Grafana прикрученной поверх zabbix — демонстрирующий реальные цифры с одной из тестовых инсталляций.
Мониторинг дисков ZABBIX
Вводная статья по шаблонам мониторинга ZABBIX — Шаблоны ZABBIX.
Если вам интересна тематика ZABBIX, рекомендую обратиться к основной статье — Система мониторинга ZABBIX, в ней вы найдете дополнительную информацию.
Исходные данные
Настройка zabbix-агента будет проводиться на самом zabbix-сервере, ОС — Debian 7.7. Все необходимые скрипты и файлы конфигураций можно найти тут. Небольшое «введение» можно прочитать в статье «Zabbix + Iostat: мониторинг дисковой подсистемы«.
Мониторинг дисков ZABBIX — Настройка
Необходимо поставить пакет «sysstat», в котором находится необходимая нам утилита «iostat»:
root@debian7:
# apt-get install sysstat
Вспомним где у нас лежат конфигурационные файлы zabbix-агента:
root@debian7:
Перейдем в папку с конфигурационными файлами:
root@debian7:
# cd /usr/local/etc/
Вернемся в корневую директорию:
root@debian7:/usr/local/etc# cd
Создадим файл iostat.conf в директории с конфигурационными файлами zabbix-агента
# nano /usr/local/etc/zabbix_agent_configs/iostat.conf
… со следующим содержанием:
root@debian7:/usr/local/etc# nano /usr/local/etc/zabbix_agent_scripts/iostat-parse.sh
#!/usr/bin/env bash
# Description: Script for disk monitoring
# Author: Epikhin Mikhail michael@nomanlab.org
# Revision 1: Lesovsky A.V. lesovsky@gmail.com
NUMBER=0
FROMFILE=$1
DISK=$2
METRIC=$3
Выставим на оба скрипта необходимые права:
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-сервер через web-интерфейс. Для этого проходим в Настройка>Шаблоны, нажимаем справа вверху «Импорт» и загружаем шаблон «iostat-disk-utilization-template.xml». Подцепляем шаблон к узлам мониторинга — Узлы сети > выбираем нужный узел > вкладка «Шаблоны» > соединяем с новым шаблоном > нажимаем «Добавить» > нажимаем «Обновить».
У автора скриптов есть одна непримечательная заметка:
Attention: Second parameter in iostat.collect must be less than Timeout option in zabbix_agentd.conf
Игнорировать её не стоит, иначе работать скрипты не будут. Для исправления заходим в конфигурационный файл zabbix-агента:
# nano /usr/local/etc/zabbix_agentd.conf
Ищем опцию «Timeout» и задаем ей значение больше, чем в скрипте, например:
То же самое делаем в файле конфигурации zabbix-сервера:
# 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.
Кому интересно, можно почитать немного отличающиеся варианты реализации мониторинга нагрузки на жесткие диски: