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
Вводная статья по шаблонам мониторинга 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.
Кому интересно, можно почитать немного отличающиеся варианты реализации мониторинга нагрузки на жесткие диски:
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: 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: LLD-мониторинг дисков без UserParameter и скриптов на агентах
В предыдущей статье я описал низкоуровневый мониторинг дисков для Windows-машин. Считаю, что статья получилась достаточно успешная. Поэтому пришло время ее фактически уничтожить. Ниже будет описан универсальный прием для Windows- и Linux-машин, для которых вообще не нужны скрипты и UserParameter’ы.
Идея простая: все необходимое от smartmontools Zabbix-сервер будет получать через внешнюю обработку и zabbix_get, парсить и передавать далее в зависимые элементы (появились в Zabbix 3.4). Такие образом не только сокращается количество обращений к наблюдаемому серверу, но и не расходуются его ресурсы, так как парсинг происходит на стороне Zabbix-сервера.
Одно ограничение на данный момент: мониторинг дисков только формата /dev/sd*. Формат /dev/csmi*,* (Intel Matrix RAID) не поддерживается ввиду того, что zabbix_get считает запятую вторым аргументом. Поправьте меня, если я ошибаюсь.
Что понадобится для реализации:
Настройка агента
Единственное, что заслуживает здесь внимания, это необходимость раскомментировать строку EnableRemoteCommands = 1, иначе агент не сможет принимать команды.
Smartmontools
Установка тривиальна и рассматриваться не будет, однако для Linux есть одна необходимость: для того, чтобы запуск проходил без sudo, необходимо установить бит SUID на файл smartctl. Для Ubuntu это — sudo chmod u+s /usr/sbin/smartctl.
Скрипт
В зависимости от вашего файла конфигурации zabbix_server.conf этот скрипт нужно положить в соответствующую директорию на Zabbix-сервер. По умолчанию для Ubuntu это — /usr/lib/zabbix/externalscripts. Не забывайте дать на файл права на выполнение — sudo chmod 775 /usr/lib/zabbix/externalscripts/smartctl.sh.
Шаблон
Ниже я постараюсь подробно описать что же происходит на каждом этапе.
Первый этап: обнаружение доступных дисков sd* с помощью внешней проверки smartctl.sh с ключами
Третий этап: Info и Attr разбираются на зависимые элементы с помощью предобработки регулярными выражениями. Это самая простая часть. Собственно, вам только останется подогнать под себя «регулярку».
Вот и все. Не нужно держать в голове что и куда положить, отключить ли политику выполнения скриптов PS, отслеживать ту же версию PS. А в случае необходимости все изменения производятся на самом Zabbix’е в веб-интерфейсе.
В итоге хотелось бы просто сказать спасибо Алексею alexvl и его команде за качественный продукт, который не перестает радовать новым функционалом. Особенно за предобработку. Жизнь с ней администратору станет гораздо легче.