Zabbix: LLD-мониторинг железа под Windows на PowerShell
Пришло время и мне собрать свой велосипед для мониторинга физического состояния Windows-железок. Готового решения или хоть более или менее работающего найти не удавалось с момента моего знакомства с Zabbix, а это более 3 лет. А тем более, чтобы оно было… элегантно что ли. Лично мне даже в таких вещах хочется видеть стройность и максимальную функциональность. Именно поэтому далее рассматривается только LLD и PowerShell. Ну и конечно же только бесплатное ПО.
Итак, мониторинг чего будет производиться:
- S.M.A.R.T. дисков (информация, общее состояние и отдельные показатели)
- Температуры, напряжение, обороты кулеров (на ваш выбор)
А выглядеть это все будет примерно так:
Суммарно понадобятся:
Шаблон
Под спойлером находится актуальный шаблон. Просто сохраните содержимое в формате xml и импортируйте в свой Zabbix.
Шаблон создан в Zabbix версии 3.2, возможно, будет работать и в более ранних версиях. Ключи стандартны и имеют вид ZScript[имя_скрипта, параметр1. параметрN]. Параметры передаются непосредственно в сам скрипт.
Надеюсь, шаблон получился максимально простым и понятным.
Скрипты PS
Ниже приведены необходимые скрипты. Внутри уже находятся и обнаружение, и запрос отдельных элементов. Работа проверена на Windows от XP SP3 до 2016. Само собой, решение с Execution Policy остается за вами.
Обнаруживаются только диски с задействованным СМАРТом. Параметры запрашиваются из столбца «RAW_VALUE». Хотите мониторить другой параметр? Просто укажите его номер. По умолчанию скобки и их содержимое отбрасываются. Если нужный вам параметр диск не отдает, то возвращается пустое поле.
По умолчанию скрипт не обнаруживает названия датчиков, в которых есть #. Для чего это нужно, смотрите ниже.
Также зарезервировано одно имя датчика — Vbat. Это напряжение аккумулятора БИОС. Его значение вынесено в отдельный элемент для триггера (срабатывает если менее 2,9V).
Значения температур и оборотов кулеров на выходе целочисленные, значения напряжений передаются как есть.
Теоретически, можно обнаруживать и другие показатели (нагрузки, частоты. ). Используйте для этого соответствующий второй параметр в ключе. К примеру: ZScript[hard,discovery,load].
Подготовка Zabbix-агента
Для максимальной унификации я использую следующий и единственный параметр для своих скриптов:
Это дает максимальную гибкость и однообразность. Если нужно будет добавить еще параметров для каких-либо скриптов, можно просто добавить переменных в кавычках. На текущие работающие скрипты это никак не повлияет. Префикс windows я использую на всякий случай, мне так удобно хранить шаблоны для гарантированной идентификации.
smartmontools
Для мониторинга состояния дисков используется smartmontools (версия 6.5 на момент написания статьи). При установке ПО по умолчанию ставится утилита smartctl-nc — именно она используется в скрипте для облегчения жизни вашего сервера. Также потребуется прописать пусть к папке bin в переменных средах.
Путь просто добавляем в конец переменной Path через точку с запятой. По умолчанию — C:\Program Files\smartmontools\bin
OpenHardwareMonitor
Для датчиков же используется OHM. Софт бесплатный с открытым кодом. Установка тривиальна, но для полноценной работы необходимо запускать программу в качестве службы. Для подобных вещей есть NSSM, я бы все же советовал качать последнюю сборку. А здесь можно посмотреть синтаксис.
Обещанный выбор датчиков обеспечивается за счет того, что названия датчиков можно изменять! Изменяете имена на удобочитаемые (они будут использованы в именах элементов), а ненужные датчики комментируете #.
Не забывайте перезапустить программу/службу для применения переименования.
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 с ключами
Этап второй: получение для каждого из найденных дисков двух элементов — Info и Attr. Info — информация о диске, Attr — атрибуты SMART. «Почему не запросить smartctl -a /dev/sd* ?» — спросите вы. Такой вывод получается не полный для части дисков, теряются атрибуты и так далее. Пришлось изобретать на ходу.
Третий этап: Info и Attr разбираются на зависимые элементы с помощью предобработки регулярными выражениями. Это самая простая часть. Собственно, вам только останется подогнать под себя «регулярку».
Вот и все. Не нужно держать в голове что и куда положить, отключить ли политику выполнения скриптов PS, отслеживать ту же версию PS. А в случае необходимости все изменения производятся на самом Zabbix’е в веб-интерфейсе.
В итоге хотелось бы просто сказать спасибо Алексею alexvl и его команде за качественный продукт, который не перестает радовать новым функционалом. Особенно за предобработку. Жизнь с ней администратору станет гораздо легче.
Мониторинг производительности дисковой подсистемы при помощи 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 будет утилизация записью.
Абсолютно также считается время обработки запросов на чтение, только используя колонки №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 — демонстрирующий реальные цифры с одной из тестовых инсталляций.