Низкоуровневое обнаружение в ZABBIX: прототипы элементов данных

http://www.zabbix.com/

Пришло время заняться получением конкретных метрик производительности и в этом нам помогут прототипы элементов данных. В прошлой статье Низкоуровневое обнаружение в ZABBIX: правила LLD мы пока что добились только выдачей списка дисков со стороны агента Zabbix, но это явно не то, на чем хотелось бы остановиться.


Если вам интересна тематика ZABBIX, рекомендую обратиться к основной статье – Система мониторинга ZABBIX, в ней вы найдете дополнительную информацию.


Прототипы элементов данных

Для “отсутствующих на прошлом занятии” небольшое введение сразу ниже.

Введение

В прошлой статье (Низкоуровневое обнаружение в ZABBIX: правила LLD) мы добились того, что агент Zabbix возвращал набор отслеживаемых объектов в формате json. В моем примере это просто список имен дисков. Сам по себе этот список не представляет никакой ценности. Для целей мониторинга значимыми являются лишь метрики производительности каждого из этих дисков.

А вот как получить эти метрики, читайте ниже.

Метрики производительности

Напомню, что данные я вытаскиваю с помощью утилиты iostat:

Столбцы rrqm/s, wrqm/s, r/s, etc… как раз и являются метриками (которые надо ещё уметь правильно читать и расшифровывать, но это другая история).

Скрипт

Задача немного проясняется – нужно написать скрипт, который бы принимал как аргумент следующие параметры:

  • Имя файла с выводом программы iostat (например iostat -d -x >/tmp/iostat.output);
  • Имя диска (например sda, как на скриншоте выше);
  • Имя столбца данных, в котором находится значение нужной метрики (в качестве примера пусть будет последний столбец %util).

Вот одна из вариаций (скрипт iostat.data.sh):

Использовать скрипт очень просто:

Он возвращает численный параметр на пересечении столбца (%util) и строки с именем диска (sda). Теперь дело за малым, нужно просто в агенте Zabbix добавить пользовательский параметр:

Первый позиционный параметр для скрипта – это имя файла с выводом iostat, а в параметры $1 и $2 будут передаваться имя диска и имя столбца вывода iostat соответственно как в примере выше.

Обновление данных

Данные утилиты iostat я вывожу во временный файл /tmp/iostat.data.output, но, как вы можете догадаться, они будут устаревать. Важно своевременно их обновлять, чтобы получать актуальные метрики производительности.

Сделать это можно двумя путями. Первый из них – реализовать обновление файла внутри скрипта. Именно это я и сделал.

Примечание: в строчках кода с 11 по 22 сравнивается текущее время с временем создания файла и, если отличие >60 сек, то в файл закидываются новые данные iostat.

Второй способ более интересный – организовать обновление данных через другой скрипт, вызываемый через UserParameter обычным элементом данных в шаблоне. Например именно так реализовано в шаблоне мониторинга Iostat-Disk-Utilization-Template 1, который уже давно ходит по просторам интернета (кстати, по его установке у меня есть отдельная статья – Мониторинг дисков ZABBIX – но она немного устарела).

Примечание: возможно вы спросите зачем изобретать велосипед заново писать шаблон, когда один уже давно изобретен и успешно используется? Вполне справедливый вопрос. Дело в том, что Iostat-Disk-Utilization-Template изначально рассчитан на выдачу усредненных результатов и можно гибко указать количество секунд, за которые пойдет усреднение данных. Мне никакое усреднение было не нужно, поскольку iostat и так усредняет данные. Да и средние значения – это худшее, что может получить человек, который занимается траблшутингом; гораздо интереснее и информативнее анализировать каким образом сервер отрабатывает пики по нагрузкам. Второй момент – меня сильно смущал механизм обновления данных производительности. Для меня проще сделать все в одном скрипте, ведь в плане быстродействия это будет скорее всего ничуть не хуже (по сути если вы используете оболочку, вы уже проигрываете в быстродействии).

Вариант интересен прежде всего тем, что позволяет не переполнять основной скрипт, но он скрывает в себе несколько подводных камней:

  • Появляется дополнительный UserParameter с отдельным скриптом со всеми вытекающими (сложнее отлаживать, поддерживать, вникать в работу);
  • Нет железной гарантии, что данные от iostat будут всегда самые свежие;
  • Придется отслеживать дополнительный элемент данных на предмет получения самой актуальной статистики по производительности.

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

Создание прототипов

К каждому правилу низкоуровневого обнаружения добавляются один или несколько прототипов элементов данных. Чтобы лучше понимать – каждому элементу прототипа данных соответствует один столбец вывода iostat.

Рассмотрим пример создания прототипа. Необходимо зайти в ваш шаблон, далее Правила обнаружения – Прототипы элементов данных – Создать прототип элемента данных.

Обратите внимание на макрос {#BLKDEV} – он автоматически заменится именем диска. Напомню, что имена дисков в формате json я вытаскивал в предыдущей статье. То есть, если у нас три диска, то после создания этого прототипа элемента данных мы получим три метрики %util по одной для каждого диска. Всего iostat выводит 13 метрик (у вас будет 13 прототипов элементов данных в шаблоне).

Уже после создания первого прототипа данных вы можете зайти в Мониторинг – Последние данные и выбрать нужный хост, чтобы понаблюдать как появится по одной метрике для каждого диска.

Яндекс.Метрика