Мониторинг дисков с помощью zabbix

Мониторинг производительности дисковых подсистем с помощью zabbix. Мониторятся следующие параметры.

• утилизация блочного устройства в % — удобная метрика для отслеживания общей нагрузки на устройстве;
• latency или отзывчивость — доступна как общая отзывчивость, так и отзывчивость на операциях чтения/записи;
• величина очереди (в запросах) и средний размер запроса (в секторах) — позволяет оценить характер нагрузки и степень загруженности устройства;
• текущая скорость чтения/записи на устройство в человекопонятных килобайтах;
• количество запросов чтения/записи (в секунду) объединенных при постановке в очередь на выполнение;
• iops — величина операций чтения/записи в секунду;

Для работы нам потребуется утилита iostat входящая в пакет sysstat. Устанавливаем sysstat

Создаем директорию для скриптов

Создаем первый скрипт для сбора метрик

Копируем в него следующий текст

Создаем второй скрипт для парсинга

Даем права на запуск

Создаем файл с ключами zabbix агента

Копируем в него следующие ключи

Скачиваем шаблон для zabbix сервера и устанавливаем.

В итоге должны получить красивые графики, например загрузка диска

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

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» в интуитивной непонятности обозначений.

Несколько вариантов получить счетчики:

typeperf -qx lodctr /s:perfcount.txt

В «lodctr» мы видим сопоставление цифр и названий счетчиков:

234 — PhysicalDisk 236 — LogicalDisk

В качестве примера, я сделал шаблон для «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 скрипта:

UserParameter=windowsdisk.discovery, powershell -NoProfile -ExecutionPolicy Bypass -File c:\get_disks.ps1

get_disks.ps1:

$drives = Get-WmiObject win32_PerfFormattedData_PerfDisk_PhysicalDisk | ? <$_.name -ne "_Total">| Select Name $idx = 1 write-host «<" write-host " `"data`":[`n" foreach ($perfDrives in $drives) < if ($idx -lt $drives.Count) < $line= "< `"<#DISKNUMLET>`» : `»» + $perfDrives.Name + «`» >,» write-host $line > elseif ($idx -ge $drives.Count) < $line= "< `"<#DISKNUMLET>`» : `»» + $perfDrives.Name + «`» >» write-host $line > $idx++; > write-host write-host » ]» write-host «>»

Результатом будет json с количеством дисков:

На основе данного discovery можно снимать необходимое вам количество метрик и строить графики, но это тема для отдельного поста.

Мониторинг дисков 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-агента

# 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 ‘BEGIN if($1==»Device:»)> END echo 0

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_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-агента:

# 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: 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.

Шаблон

Шаблон экспортирован из версии 3.4.4.
В шаблоне уже присутствуют следующие элементы: модель, семейство, серийный номер, объем диска, статус SMART; а также значения SMART 3, 5, 7, 9, 10, 190(194), 196, 197, 198 ,199. Есть и 3 триггера: два оповещают о высоких температурах и еще один о плохом SMART’е.

Ниже я постараюсь подробно описать что же происходит на каждом этапе.
Первый этап: обнаружение доступных дисков sd* с помощью внешней проверки smartctl.sh с ключами и discovery. В ответ сервер получает JSON с дисками, на которых активирована функция SMART. Диски без SMART’а или не sd* не выводятся.

Этап второй: получение для каждого из найденных дисков двух элементов — Info и Attr. Info — информация о диске, Attr — атрибуты SMART. «Почему не запросить smartctl -a /dev/sd* ?» — спросите вы. Такой вывод получается не полный для части дисков, теряются атрибуты и так далее. Пришлось изобретать на ходу.

Третий этап: Info и Attr разбираются на зависимые элементы с помощью предобработки регулярными выражениями. Это самая простая часть. Собственно, вам только останется подогнать под себя «регулярку».

Вот и все. Не нужно держать в голове что и куда положить, отключить ли политику выполнения скриптов PS, отслеживать ту же версию PS. А в случае необходимости все изменения производятся на самом Zabbix’е в веб-интерфейсе.

В итоге хотелось бы просто сказать спасибо Алексею alexvl и его команде за качественный продукт, который не перестает радовать новым функционалом. Особенно за предобработку. Жизнь с ней администратору станет гораздо легче.