Zabbix мониторинг дисков linux

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

Вряд ли кто-то будет спорить, что наблюдение за производительностью дисковой подсистемы — чуть ли не важнейшая задача для всех высоконагруженных систем хранения и баз данных. Я изначально столкнулся с этим давным-давно, еще когда приходилось наблюдать за PostgreSQL. В последнее время вернулся к этому вопросу в связи с необходимостью тестирования различных хранилищ.

Сегодня хочу поделиться с сообществом своим текущим опытом на реальном примере zabbix и его связке с block stat.

Небольшое отступление

Я являюсь архитектором баз данных и систем хранения очень высокой производительности и больших объемов. Поэтому часто сталкиваюсь с задачами оценки, как те или иные параметры настройки системы влияют на работу СХД, какие железные конфигурации СХД лучше.

Да есть куча утилит, которая позволит протестировать диски, например тот же fio. Но ничто не сравнится с тестированием реальной нагрузкой.

Однако прежде чем подавать реальную и настоящую нагрузку, неплохо бы сначала протестировать на синтетике. А наблюдать за синтетикой лучше теми же средствами, что и за боевой системой, просто потому, что даже если ваши метрики не совсем верны методологически – они будут хотя бы те же самые и по ним можно будет делать выводы лучше/хуже.

Когда то давным-давно для этих целей использовал iostat, лютый парсер к нему и gnuplot, и даже написал статейку habr.com/post/165855. Скажу я вам – это жутко неудобно.

Куда как удобнее натравить на систему zabbix и мониторить. А к zabbix можно прикрутить модную Grafana и мониторить красиво. Сразу скажу – выбор zabbix скорее исторический: «потому что он уже был».

Мониторинг дисков в zabbix

Справедливости ради скажу, что в zabbix уже есть встроенные ключи vfs.dev.*, но увы очень мало: скорость чтения и записи, объем.

А что нужно нам?

Практика показывает что ключевые метрики по которым можно оценивать дисковую подсистему это:

• Количество операций в секунду (ops)
• Пропускная способность (throughput)
• Время обработки запроса (latency или правильней svctime)
• Утилизация дисковой подсистемы (utilization)

Так как эти метрики очень зависят друг от друга, то не зная все нельзя сделать правильные выводы.

Все эти метрики есть в iostat. Но как их положить в zabbix?

Легкое гугление приводит нас к различным парсерам iostat, в том числе и здесь.

Но мне по душе другой вариант, а именно парсинг вывода /sys/class/block/*/stat

• это первоисточник данных — iostat так же использует эти данные
• для разбора показателей можно ограничиться только однострочником в UserParameter без дополнительных скриптов.

Но есть и недостатки:

• Некоторые параметры необходимо вычислять делением дельты одного на дельту другого, причем не простой, а временной (скорости). В zabbix это сделать можно, но это будут не одновременные запросы, как если бы это делал сложный скрипт, а отношение последних значений, что в принципе не совсем верно, но в нашем случае довольно точно.

Итак, кроме самого zabbix и zabbix-agent на наблюдаемой машине нам потребуется awk. Мы используем дистрибутив CentOS 7.4 и zabbix 3.4

Данные в zabbix мы будем собирать при помощи zabbix-agent, создав пользовательские ключи. Для этого в /etc/zabbix/zabbix_agentd.d нужно создать файлик userparameter_custom.vfs.conf примерно со следующим содержимым:

UserParameter=custom.vfs.dev.io.ms[*],cat /sys/class/block/$1/stat | awk ‘‘

Тут все просто — создаем пользовательский ключ custom.vfs.dev.io.ms, в качестве параметра передаем туда имя блочного устройства, значением параметра будет 10 колонка файлика stat.

В этом файлике статистики всего 11 колонок, посмотреть их описание можно вот тут.

Колонка №10 это io_tics — количество миллисекунд затраченным устройством на ввод вывод. Как почти все параметры — эта цифра является аккумулятором и постоянно возрастает. Как же получить из них привычные метрики.

Утилизация дисковой подсистемы

Эта метрика аналогична значению поля utils команды iostat -x. Характеризует загрузку дисковой подсистемы. По сути это сколько процентов реального времени система затратила на операции ввода-вывода за интервал между опросами. Как правило при приближении к 100% система начинает все больше простаивать в ожидании когда диски обработают ваши запросы.

Чтобы получить эту цифру — надо взять значение 10 колонки файла статистики и запомнить его в zabbix как скорость изменения в секунду, не забыв умножить на 0.1 так как значение в статистике в миллисекундах, а нам нужны проценты.

Аналогичным образом можно посчитать нагрузку записью/чтением (колонки write_ticks / read_ticks).

Время обработки запроса

Эта метрика аналогична r_svctime и w_svctime для записи и чтения соответственно. По сути это усредненное время обработки запросов за интервал между опросами.

Данная метрика чуть посложнее. Рассмотрим на примере запросов на запись.

Для этого нам понадобится создать три ключа:

write utils — количество времени потраченное на запись — колонка №8 write_ticks сохраненная, как скорость изменения в секунду между опросами. По сути значение ключа в zabbix будет утилизация записью.

write ops — количество запросов на запись — колонка №5 write I/Os. Так же сохраняем как скорость

svctime или latency — искомый параметр. Создаем как вычисляемое значение: последнее значение write utils / последнее значение write ops. Плюс еще поделить на 1000 чтобы в секунды перейти

Абсолютно также считается время обработки запросов на чтение, только используя колонки №1 read I/Os и №4 read_ticks.

Пропускная способность

Метрика показывающая с какой скоростью данные были записаны или прочитаны

Для этой метрики используются колонки №3 read sectors и №5 write sectors. Значение сколько было прочитано или записано «секторов». Точно так же в zabbix сохраняем как изменение за секунду.

Единственный ньюанс — значение в файле указанно «в попугаях-секторах», причем размер этого «сектора» фиксирован 512 байт и не зависит от реальных значений ни физического ни логического сектора устройства (проверял на нескольких устройствах с реальным размером физического сектора 4к). Так что чтобы пересчитать в байты — не забудьте умножить на 512.

Количество операций ввода-вывода в секунду

Эта метрика — те самые пресловутые IOPS

Самая простая метрика — мы ее уже записывали для подсчета svc time это значение колонок №5 write I/Os и №1 read I/Os также сохраненные как скорость в секунду.

Заключение

Этих метрик мне как правило достаточно для того чтобы я мог делать обоснованные выводы. Конечно это не все цифры которые можно получить из файла статистики. Например там есть и число текущих обрабатываемых запросов, и количество запросов которые были объеденены. Но полагаю при необходимости вам не составит труда добавить их по аналогии с описанным.
И да не претендую на авторство — сам метод был когда-то давно загуглен, но за давностью лет ссылки конечно затерялись.

Увы NDA заставляет кое-что подчистить из них, но надеюсь на работоспособность шаблона это не повлияет.

А в шапке скриншот из Grafana прикрученной поверх zabbix — демонстрирующий реальные цифры с одной из тестовых инсталляций.

Источник