Автоматизация системы мониторинга с помощью Zabbix LLD

zabbix lld

В этой статье поговорим о важной части системы мониторинга Zabbixнизкоуровневом обнаружении, или Low Level Discovery. Я познакомлю вас с интересной функцией Zabbix LLD, которая поможет автоматизировать твою систему мониторинга и вывести ее на новый уровень.

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

Не секрет, что правильно настроенный мониторинг в 99 случаях из 100 позволяет избежать крупной аварии в информационной системе. Авария может быть любого типа: от простых пятисотых ошибок на фронтенде до ужасающих отставаний репликации на серверах баз данных и до еще более ужасного выхода железа из строя. Во всех этих случаях нас спасает система мониторинга. Как показывает практика, грамотно настроенный мониторинг творит чудеса, бережет нервы и греет душу.

Низкоуровневое обнаружение (Low Level Discovery)

На начальном этапе развития системы все просто. Есть от двух до десяти серверов, и все настройки можно проставить вручную. А как быть, когда система постепенно, но неумолимо растет? Когда серверов уже не десять, а пятьдесят или сто? Справиться как раз и помогает механизм Low Level Discovery.

Низкоуровневое обнаружение (я буду сокращать до LLD) дает возможность автоматизировать создание метрик (элементов данных), хостов, триггеров и графиков для разных объектов в системе мониторинга. Как пример можно привести мониторинг файловых систем и разделов в Linux — низкоуровневое обнаружение уже идет в поставке Zabbix для этой ОС. Делать тут ничего не надо, достаточно завести нужные хосты в группу, и все.

Мониторинг сетевых интерфейсов в Zabbix — это тоже низкоуровневые обнаружения. Кстати, можно настроить автоматическое удаление объектов из мониторинга по результатам проводимых обнаружений. И администратор может определить собственные типы обнаружения — достаточно описать их в виде файла JSON.

РЕКОМЕНДУЕМ:
Система обнаружения вторжений Snort

Но вернемся к обещанной истории из практики. Работал со мной один коллега, начинающий администратор. Ему дали задачу: завести под мониторинг около 270 объектов в Zabbix и настроить по ним триггеры. Казалось бы, все просто. В тот же день спрашиваю его: «Ну как, успел завести, сколько осталось? Готовы ли триггеры?» В ответ слышу: «Сегодня заведу метрики! А завтра сделаю триггеры!»

Задачу при этом нужно было закрыть в тот же день и отчитаться перед начальством. Как оказалось, коллега делал эти объекты вручную по одному. Сказать, что я опешил, — ничего не сказать. Спросил его про LLD, и выяснилось, что он даже не знал о существовании такой вещи. После небольшого экскурса мы закрыли задачу за час вместо двух дней ручной работы.

Низкоуровневые обнаружения в теории

LLD появился в Zabbix где-то с версии 2.0. Эта техника применяется не только для автообнаружения на хостах, LLD еще очень хорошо разгружает работу сервера Zabbix. В случае активной проверки сервер Zabbix сам отправляет запрос на хост, чтобы получить метрику. Обычно запрос ставится в очередь наряду со всеми остальными запросами и обрабатывается в порядке очереди, но, если метрик много, сервер будет серьезно загружен. В случае с LLD в режиме проверки хост zabbix-trapper сам отправляет серверу список метрик, а спустя небольшое время — и сами метрики со значениями. То есть нагрузка выходит минимальная. Сервер сам решает, что принимать, а что нет, исходя из настроек.

Реализация технологии LLD на хосте следующая: используется связка «приложение — скрипт — сендер Zabbix — сервер Zabbix». Давайте пройдемся по всем этапам, чтобы было понятнее.

  1. Инициализация скрипта.
  2. Запрос от скрипта к приложению на получение метрик.
  3. Обработка запроса от скрипта приложением.
  4. Ответ скрипту от приложения с передачей данных.
  5. Формирование скриптом JSON LLD для передачи имен метрик на сервер Zabbix.
  6. Выдача JSON при вызове скрипта.
  7. Обработка полученных от приложения данных путем формирования метрик и их значений (к примеру, с записью в файл).
  8. Вызов сендера Zabbix скриптом и инициализация отправки метрик на сервер.
  9. Сендер передает запрос на сервер Zabbix. Режим проверки на сервере zabbix-trapper.
  10. Сервер Zabbix считывает метрики и отправляет ответ для сендера.
  11. Сендер получает ответ от сервера и логирует его на экран или в файл.

Чтобы было наглядней, я подготовил для вас небольшую графическую схему взаимодействия компонентов. Надеюсь, она вам поможет.

Схема взаимодействия компонентов Zabbix LLD
Схема взаимодействия компонентов Zabbix LLD

В остальных вопросах вы можете смело обращаться к документации Zabbix. Русскоязычная документация лежит в открытом доступе.

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

Автоматизация системы мониторинга с Zabbix LLD

Что можно мониторить с помощью LLD? Да все что угодно! Главное — чтобы на хосте было большое количество объектов. Также желательно, чтобы объекты имели структуру. Хороший пример — мониторинг количества сообщений в очередях на сервере RabbitMQ. Общее количество очередей на сервере может быть больше ста штук. А из структуры объектов нам понадобятся только имя очереди на сервере и количество сообщений за последнюю минуту.

Итак, ставим себе задачу.

  1. Собирать количество сообщений в очереди AMQP на сервере.
  2. В том случае, если в очереди скопилось больше пяти сообщений за пять минут, вывести триггер предупреждения. Если свыше 100 за 30 минут, то триггер повышается до статуса чрезвычайного.

В этом примере сервер и хост Zabbix развернуты на системе Linux CentOS 7.2. Версия хоста и сервера — 3.4. Вы можете использовать любой другой дистрибутив операционной системы на свое усмотрение. Версию Zabbix советую использовать выше 2.0.

Переходим к настройке LLD на сервере Zabbix. Необходимо будет настроить шаблон, а внутри него — обнаружение. Все просто.

Настраиваем шаблон AMQP: «Настройка → Шаблоны → Создать шаблон». Заполняем поля «Имя шаблона» и «Видимое имя» (к примеру, Template App AMQP). Переходим в только что созданный шаблон. Создаем группу элементов данных, назовем ее AMQP service. Добавим нужные хосты или группы хостов в шаблон.

Настройка шаблона Zabbix
Настройка шаблона Zabbix

Создаем правила обнаружения для метрик: «Настройка → Шаблоны → Имя созданного шаблона → Правила обнаружения → Создать правило обнаружения».

Создание правила обнаружения Zabbix
Создание правила обнаружения Zabbix

Создаем прототип данных (прототип метрики): «Настройка → Шаблоны → Имя созданного шаблона → Правила обнаружения → Имя созданного правила → Прототипы элементов данных → Создать прототип элементов данных».

Создание прототипа данных Zabbix
Создание прототипа данных Zabbix

Создаем прототип графика для метрик. «Настройка → Шаблоны → Имя созданного шаблона → Правила обнаружения → Имя созданного правила → Прототипы графиков → Создать прототип графика». Все как при создании обычного графика для хоста, только вместо элемента данных выбираем прототип данных. Теперь по каждой метрике будет создаваться отдельный график.

Создание прототипа графика Zabbix
Создание прототипа графика Zabbix

Создаем прототипы триггеров по прототипам данных. «Настройка → Шаблоны → Имя созданного шаблона → Правила обнаружения → Имя созданного правила → Прототипы триггеров → Создать прототип триггеров». Все как обычно при создании триггера, только выбираем прототип элемента данных. Пример можете посмотреть на скриншоте.

Создание прототипа триггера Zabbix
Создание прототипа триггера Zabbix

Далее идет настройка хоста для отправки метрик на сервер. Устанавливаем на хосте пакет zabbix-sender для отправки данных с хоста на сервер Zabbix.

Проверить разрешение у юзера zabbix на использование командной строки — в нашем случае RabbitMQ, то есть /usr/sbin/rabbitmqctl. Если разрешения нет, то обязательно добавить в SUDO.

Теперь пишем примитивный скрипт мониторинга очередей на хосте zabbix. Скрипты для получения метрик идут /etc/zabbix/scripts/. Логика работы будет следующая.

  1. Задаем переменные имени хоста (который отправляет метрики), имя сервера (который принимает метрики), номер порта (который будет слушать сервер).
  2. Чистим системные файлы скрипта, чтобы не переполняли место на разделе.
  3. Запрашиваем список виртуальных хостов на сервере очередей и пишем их в файл /etc/zabbix/scripts/zamqp_vhosts.list.
  4. Проходим весь файл /etc/zabbix/scripts/zamqp_vhosts.list и запрашиваем список очередей по виртуальным хостам. Зашиваем имена очередей и их значения в файл /etc/zabbix/scripts/zamqp_queues.list.
  5. Начинаем формирование JSON для передачи всех значений имен очередей с хоста.
  6. Проходим файл /etc/zabbix/scripts/zamqp_queues.list, при этом разбиваем каждую читаемую строку на две переменные, используя двоеточие как разделитель.
  7. В этом же цикле начинаем формирование списка метрик, отправляемых на сервер Zabbix, в формате имя_хоста имя_метрики значение_метрики. Все данные складируем в файл /etc/zabbix/scripts/zamqp_data.list.
  8. После завершения цикла заканчиваем формировать JSON специальным значением QUEUENAME (заглушкой, она не будет использоваться), иначе JSON получится кривой.
  9. Выдаем JSON в вывод cat.
  10. Отправляем все собранные метрики из файла /etc/zabbix/scripts/zamqp_data.list на сервер Zabbix, вывод команды перенаправляем в файл /etc/zabbix/scripts/zsender.log, чтобы не запороть JSON.

Для написания скрипта я использовал Bash, но вы можете писать на любом языке, который вам ближе. Далее — код скрипта.

Как видите, код не требует глубоких познаний в программировании. Но вы можете его усложнить на свое усмотрение.

Настроим агент и убедимся, что метрики отправляются на сервер. Добавим новый пользовательский параметр в конфигурацию клиента zabbix-agent.

Перезапустим агент и проверим его статус.

Если все хорошо, то в логе отправки метрик вы увидите все метрики, уходящие на сервер Zabbix.

Проверяем, что метрики успешно доходят до сервера. На сервере запускаем команду zabbix_get. Если на экран будет выведен JSON, значит, все в порядке. Если нет, то проверяем скрипт хоста на ошибки.

На этом настройка мониторинга очередей закончена.

В завершение

Как вы видите, автоматизация системы мониторинга не такая уж и сложная вещь и Zabbix LLD легок и прост в освоении! Никаких сверхспособностей не требуется, иногда нужно лишь желание автоматизировать сбор метрик и чуть-чуть свободного времени.

РЕКОМЕНДУЕМ:
Мониторинг в Linux с помощью командой строки

Надеюсь, моя статья поможет вам с изучением Zabbix и вы откроете для себя новые возможности при настройке мониторинга. А если подсядете на эту штуку, то не ленитесь иногда заглядывать в документацию по Zabbix. Разработчики оставили там для вас много интересного и полезного.

Понравилась статья? Поделиться с друзьями:
Добавить комментарий