Zabbix 5: сущность и принципы применения

Сегодня знакомимся с архитектурой Zabbix системы и лучшими ее практиками под руководством старшего системного инженера Logrocon Ивана Худорожкова.

Рассматриваемые вопросы:

1. Архитектура Zabbix системы.
2. Основные возможности: Проверки, Триггеры, Действия, Операции, Шаблоны.
3. Низкоуровневое обнаружение.
4. Zabbix за прокси.
5. Веб-интерфейс.
6. Лучшие практики.

Что такое Zabbix?

• Zabbix — это универсальный инструмент мониторинга, способный отслеживать динамику работы серверов и сетевого оборудования, быстро реагировать на внештатные ситуации и предупреждать возможные проблемы с нагрузкой. Система мониторинга Zabbix может собирать статистику в указанной рабочей среде и действовать в определенных случаях заданным образом.
• Систему создал Алексей Владышев на языке Perl. Впоследствии проект подвергся серьезным изменением, которые затронули и архитектуру. Zabbix переписали на C и PHP. Открытый исходный код появился в 2001 г., а уже через три года выпустили первую стабильную версию.
• Веб-интерфейс Zabbix написан на PHP. Для хранения данных используются MySQL, Oracle, PostgreSQL, SQLite или IBM DB2.

Архитектура Zabbix.

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

1. Сервер — ядро, хранящее в себе все данные системы, включая статистические, оперативные и конфигурацию. Дистанционно управляет сетевыми сервисами, оповещает администратора о существующих проблемах с оборудованием, находящимся под наблюдением.
2. Прокси — сервис, собирающий данные о доступности и производительности устройств, который работает от имени сервера. Все собранные данные сохраняются в буфер и загружаются на сервер. Нужен для распределения нагрузки на сервер. Благодаря этому процессу можно уменьшить нагрузку на процессор и жесткий диск. Для работы прокси Zabbix отдельно нужна база данных.
3. Агент — программа (демон), которая активно мониторит и собирает статистику работы локальных ресурсов (накопители, оперативная память, процессор и др.) и приложений.
4. Веб-интерфейс — является частью сервера системы и требует для работы веб-сервер. Часто запускается на том же физическом узле, что и Zabbix.

Схема Zabbix 5

Основные возможности

Функционал включает в себя общие проверки для наиболее распространенных сервисов, в том числе СУБД, SSH, Telnet, VMware, NTP, POP, SMTP, FTP и т.д. Если стандартных настроек системы недостаточно, их можно изменить самостоятельно или же пользоваться дополнением через API.

Стандартные функции системы:

• Контроль нагрузки на процессор, касается и отдельных процессов.
• Сбор данных об объеме свободной оперативной и физической памяти.
• Пинг для проверки доступности узлов в сети.
• Мониторинг активности жесткого диска.
• Мониторинг сетевой активности.

Проверки

Для описания системы мониторинга Zabbix существует два ключевых понятия:

1. Узлы сети — рабочие устройства и их группы (сервера, рабочие станции, коммутаторы), которые необходимо проверять. С создания и настойки узлов сети обычно начинается практическая работа с Zabbix.
2. Элементы данных — набор самостоятельных метрик, по которым происходит сбор данных с узлов сети. Настройка элементов данных производится на вкладке «Элемент данных» или в автоматическом режиме — через подключение шаблона.

Сам Zabbix-агент способен отражать текущее состояние физического сервера, собирая совокупность данных. У него достаточно много метрик. С их помощью можно проверить загруженность ядра (Processor load), время ожидания ресурсов (CPU iowait time), объем системы подкачки (Total swap space) и многое другое.

Агент проверок

Хотя мы и обсуждаем агенты Zabbix в качестве активных или пассивных, некий агент на самом деле не является тем или иным — само направление коммуникации определяется на уровне его элемента. Некий агент способен (и при определении по умолчанию делает это) работать в обоих режимах в одно и то же время. Тем не менее, мы будем вынуждены выбирать какой именно тип элемента применять - активный или пассивный. Говоря кратко — рекомендуется применение активных элементов.

Чтобы понять почему, давайте сопоставим как осуществляется такое подключение. В случае пассивного агента это очень просто:

Одно значение означает одно подключение.

Активный агент слегка более сложный. Помните - в таком активном режиме сам агент подключается к своему серверу; следовательно этот агент вначале подключается к своему серверу Zabbix и запрашивает некий список элементов для мониторинга. Этот сервер затем выдаёт отклик с элементами, их интервалы и всю прочую связанную с этим информации.

Проверки

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

• Zabbix agent (Zabbix-агент) — сервер собирает информацию у агента самостоятельно, подключаясь по определенному интервалу.
• Simple check (Простые проверки) — простые операции, в том числе пинг.
• Zabbix trapper (Zabbix-траппер) — сбор информации с трапперов, представляющих собой мосты между используемыми сервисами и самой системой.
• Zabbix aggregate (Zabbix-комплекс) — процесс, предусматривающий сбор совокупной информации из базы данных.
• SSH agent (SSH-агент) — система подключается по SSH, использует указанные команды.
• Calculate (Вычисление) — проверки, которые система производит, сопоставляя имеющиеся данные, в том числе после предыдущих сборов.

У проверок есть заданные шаблоны (Templates), которые упрощают создание новых. Кроме обычных операций существует возможность регулярно проверять доступность веб-сервера с помощью имитации запросов браузера.

Проверки через пользовательский параметр

Чтобы выполнить проверку через агент, нужно прописать соответствующую команду в конфигурационный файл Zabbix-агента в качестве пользовательского параметра (UserParameter). Сделать это можно с помощью выражения следующего вида:

UserParameter=<ключ>,<команда>
Помимо самой команды, приведенный синтаксис содержит уникальный (в пределах узла сети) ключ элемента данных, который надо придумать самостоятельно и сохранить. В дальнейшем, ключ можно использовать для ссылки на команду, внесенную в пользовательский параметр, при создании элемента данных.

UserParameter=ping,echo 1
С помощью данной команды можно настроить агент на постоянное возвращение значения «1» для элемента данных с ключем «ping».

А так же через дополнительный пакет Zabbix_get мы можем проверить сразу закинув на сервер запрос:
./zabbix_get -s 127.0.0.1 -p 10050 -k "UserParameter"

Тригеры

Это логические выражения со значениями FALSE, TRUE и UNKNOWN, которые используются для обработки данных. Их можно создать вручную. Перед использованием триггеры возможно протестировать на произвольных значениях.

У каждого триггера существует уровень серьезности угрозы, который маркируется цветом и передается звуковым оповещением в веб-интерфейсе.

• Не классифицировано (Not classified) — серый.
• Информация (Information) — светло-синий.
• Предупреждение (Warning) — жёлтый.
• Средняя (Average) — оранжевый.
• Высокая (High) — светло-красный.
• Чрезвычайная (Disaster) — красный.

avg — среднее значение за определенный интервал в секундах или количество отсчетов.
Delta — разность между максимумом и минимумом с определенным интервалом или количеством отсчетов.
change — разница между последним и предпоследним значением.
count — количество отсчетов, удовлетворяющих критерию.
date — дата.
dayofweek — день недели от 1 до 7.
diff — у параметра есть значения, где 0 — последнее и предпоследнее значения равны, 1 — различаются.
last — любое (с конца) значение элемента данных.
max\min — максимум и минимум значений за указанные интервалы или отсчеты.
now — время в формате UNIX.
prev — предпоследнее значение.
sum — сумма значений за указанный интервал или количество отсчетов.
time — текущее время в формате HHMMSS.

Триггеры обладают еще одной важной функцией для мониторинга — прогнозированием. Она предугадывает возможные значения и время их возникновения. Прогноз составляется на основе ранее собранных данных.

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

Функционал прогнозирования добавили с обновлением системы 3.0, вышедшим в феврале 2016 года.

Действия

Действие (Action) – представляет собой заданную реакцию на событие (Event).
Действие может устанавливаться автоматически или вручную как для одного из событий, так и для целой группы.

Параметры действий

• Name — имя действия.
• Event source — источник события. Источниками событий служат обнаружение (Discovery Events), авторегистрация (Auto registration Events) или заданный триггер (Trigger Events).
• Enable escalations — разрешение на эскалацию событий.
• Period — период времени для шага эскалации, указывается в секундах.
• Default subject — указывается, кто извещается по умолчанию.
• Default message — стандартный текст сообщения.
• Recovery message — текст уведомления после решения проблемы.
• Recovery subject — субъект, которого извещают после операции.
• Status — статус действия, может быть «активно» и «запрещено».

Операции

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

Параметры операций

• Step — при эскалации событий.
• Operation type — действия на определенном шаге, например, «Send message» или «Execute command».
• Event Source — источник событий.
• Send message to — отдельное сообщение (Single user) или групповое (User group).
• Default message — текст по умолчанию.
• Subject — кого оповещает система.
• Message — текст сообщения.
• Remote command — команда для удаленного управления.

Операции

Шаблоны

Zabbix стремится поставлять растущий список полезных готовых шаблонов. Готовые шаблоны заранее настроены и, таким образом, являются полезным способом ускорения развертывания задач мониторинга. Шаблоны хранятся в xml файле. Есть несколько типов шаблонов:

• Стандартизованные шаблоны для сетевых устройств
• Настройка шаблонов HTTP
• Настройка шаблонов IPMI
• Настройка шаблонов ODBC

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

Функция Низкоуровневого обнаружения (LLD) автоматически создает элементы и триггеры, которые позволяют отслеживать системы сервера, находящимся под наблюдением. Включение функции происходит через настройку атрибутов, которую можно сделать, пройдя по пути: «Настройка» → «Шаблоны» → «Обнаружение» (вкладка в строке с шаблоном) → вкладки «Правила обнаружения»/«Фильтры».

Что можно обнаружить:

• Распространённые OID, используемые SNMP.
• Сетевые интерфейсы.
• Процессоры, их ядра.
• Файловые системы.
• Службы Windows.
• ODBC

Дополнительные типы

Задать собственные типы низкоуровневого обнаружения возможно с применением формата JSON. Типы проверок, для которых можно указать список портов и интервал для них:

• SSH, LDAP, SMTP, FTP, HTTP, POP, NNTP, IMAP, TCP

Если хост пропадает или обнаруживается, для события можно привязать любое действие — условия и операцию для них.

Прокси

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

Прокси используется еще в нескольких случаях — если агенты находятся далеко друг от друга или ограничены локальной сетью. Это сказывается на доступности агентов и величине пингов.

Zabbix прокси функционирует как демон. Для его использования обязательно наличие отдельной базы данных.

Особенности веб-интерфейса

Система мониторинга Zabbix располагает удобным веб-интерфейсом, в котором сгруппированы элементы управления. Консоль предусматривает просмотр собранных данных, их настройку. Для безопасности входа и работы осуществляется автоматическое отсоединение через 30 минут пользовательского бездействия.

На главном экране всегда представлена информация о состоянии узлов сети и триггеров.

Лучшие практики

Настраивайте панели под себя и под требования проекта. Ищите узкие места заранее, стройте на них триггеры и оповещения, выводите информацию о них на панели.

Разбирайте проблемы при поступлении, от маленьких до больших.

Всегда после подключения нового шаблона проверяйте поступление данных.

Используем комплексные экраны для большего обхвата и понимания происходящего с инфраструктурой на проекте.

Не брезгуйте пользоваться Zabbix, как дополнительной инвентаризационной книжной.

А использование обнаружения сервисов даст таблицу с работающими ресурсами прямо сейчас.

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

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

Используем комплексные экраны для большего обхвата и понимания происходящего с инфраструктурой на проекте.

Проверяйте последние 100 триггеров, обрабатывайте самые частые и продумывайте пути решения новых проблем.

Так же очень хорошо использовать мониторинг появления проблем с безопасностью в открытом коде и коде самой системы. Можно использовать данные открытые источники о проблемах, по типу https://vulners.com/.

Стройте карты сетей для большего понимания куда ходит трафик и где может понадобиться помощь монтажников :)

Так же стоит изредка, но верно проверять журнал действий системы оповещения, тут можно обнаружить проблему с доставкой уведомления или работы скрипта.

Список литературы

Реферальные ссылки:
https://www.zabbix.com/documentation/current/ru/manual