1. Архитектура Zabbix и фундаментальные принципы работы системы
Архитектура Zabbix и фундаментальные принципы работы системы
В 2012 году крупная европейская авиакомпания пережила сбой системы бронирования билетов, который длился четыре часа. Причиной стало переполнение жесткого диска на одном из серверов баз данных. Сервер продолжал работать, сеть функционировала, но транзакции не записывались. Инженеры узнали о проблеме только после шквала звонков от разгневанных клиентов. Этот инцидент обошелся компании в миллионы евро упущенной выгоды. Подобные ситуации возникают, когда ИТ-инфраструктура существует как «черный ящик»: серверы гудят, индикаторы мигают, но никто не знает, что происходит внутри операционных систем и приложений. Мониторинг — это нервная система ИТ-инфраструктуры, которая превращает этот черный ящик в прозрачную, управляемую среду.
Zabbix является одним из самых популярных решений корпоративного уровня для построения такой нервной системы. Он способен отслеживать состояние миллионов метрик в секунду, масштабироваться на распределенные дата-центры и автоматически реагировать на инциденты. Чтобы научиться строить такие системы, необходимо понимать, как Zabbix устроен на фундаментальном уровне.
Три столпа архитектуры Zabbix
В отличие от простых утилит мониторинга, которые запускаются на одном компьютере и пишут логи в текстовый файл, Zabbix изначально спроектирован как распределенная многокомпонентная система. Его ядро состоит из трех независимых, но тесно связанных сущностей: сервера, базы данных и веб-интерфейса.
Zabbix Server: вычислительное ядро
Zabbix Server — это центральный процесс (написанный на языке C), который выполняет всю тяжелую работу. Его можно сравнить с мозгом системы мониторинга. Сервер работает в фоновом режиме (как демон в Unix-системах) и выполняет три ключевые задачи:
Внутри себя Zabbix Server распараллеливает эти задачи между десятками специализированных процессов. Например, процессы poller занимаются активным опросом устройств, trapper слушают входящие соединения, а alerter отвечают за рассылку уведомлений. Такая многопоточность позволяет серверу обрабатывать огромные потоки данных без задержек.
База данных: долгосрочная память
Zabbix Server не хранит данные в своей оперативной памяти постоянно. Вся конфигурация (какие серверы мониторить, кому отправлять письма) и все собранные метрики (загрузка процессора за последний год) хранятся в реляционной базе данных. Zabbix поддерживает MySQL/MariaDB, PostgreSQL и Oracle.
База данных Zabbix концептуально разделена на три логических блока:
Frontend: панель управления
Zabbix Frontend — это веб-интерфейс, написанный на PHP. Важно понимать: веб-интерфейс напрямую не управляет процессом сбора данных. Он взаимодействует исключительно с базой данных и, в некоторых случаях, с API Zabbix Server (например, для проверки статуса самого сервера).
Когда вы создаете новый узел сети в браузере, Frontend просто записывает новую строку в таблицу базы данных. Zabbix Server, благодаря процессу configuration syncer, замечает изменения в базе и начинает мониторинг нового устройства. Разделение сервера и интерфейса позволяет вынести Frontend на отдельную физическую машину, чтобы тяжелые запросы пользователей при построении графиков не отнимали ресурсы у процесса сбора критически важных метрик.
!Архитектура компонентов Zabbix
Агенты и безагентный мониторинг
Чтобы Zabbix Server мог узнать, сколько оперативной памяти свободно на конкретном сервере базы данных, ему нужен способ заглянуть внутрь операционной системы этого сервера. Для этого используются методы сбора данных, которые делятся на агентские и безагентные.
Zabbix Agent — это легковесная программа (демон/служба), которая устанавливается на целевой хост (Linux, Windows, macOS). Агент имеет прямой доступ к системным вызовам ОС, поэтому он может собрать максимально детальную информацию: от загрузки ядер процессора до состояния конкретного процесса в памяти.
Взаимодействие между сервером и агентом строится на двух принципиально разных моделях: пассивных и активных проверках.
Пассивные проверки (Pull-модель)
При пассивной проверке инициатором связи всегда выступает Zabbix Server.
Эта модель проста в настройке, но имеет два существенных недостатка при масштабировании. Во-первых, сервер тратит свои ресурсы на поддержание тысяч сетевых соединений и ожидание ответов. Во-вторых, если агент находится за NAT (преобразованием сетевых адресов) или строгим файрволом, сервер просто не сможет до него «достучаться».
Активные проверки (Push-модель)
При активной проверке инициатором выступает сам Zabbix Agent.
Активные проверки радикально снижают нагрузку на Zabbix Server. Серверу больше не нужно держать таймеры и инициировать опросы — он просто работает как приемник данных. Кроме того, активному агенту не нужны открытые входящие порты на файрволе, ему достаточно иметь возможность отправить исходящий трафик на сервер. В высоконагруженных инфраструктурах Big Tech компаний абсолютное большинство метрик собирается именно через активные проверки.
!Сравнение активных и пассивных проверок
Безагентный мониторинг
Не на каждое устройство можно установить агента. Маршрутизаторы Cisco, коммутаторы, источники бесперебойного питания или сетевые принтеры работают на закрытых прошивках. Для них Zabbix использует стандартные сетевые протоколы. Самый частый из них — SNMP (Simple Network Management Protocol). Сервер отправляет SNMP-запрос сетевому устройству, и оно отвечает стандартизированным набором метрик (например, объем трафика на конкретном порту).
Конвейер данных: от метрики к инциденту
Понимание того, как данные проходят через Zabbix, требует знания базового словаря системы. Весь процесс мониторинга строится вокруг пяти логических сущностей, которые образуют единый конвейер.
1. Узел сети (Host)
Узел сети — это любой логический или физический объект, который мы мониторим. Это может быть физический сервер, виртуальная машина, Docker-контейнер, коммутатор или даже веб-сайт. Узел сети всегда имеет IP-адрес или DNS-имя.2. Элемент данных (Item)
Элемент данных — это конкретная метрика, которую мы собираем с узла сети. У одного сервера (Host) могут быть сотни элементов данных (Items):system.cpu.load, vfs.fs.size[/,free], net.if.in[eth0].
Каждый элемент данных определяет:
3. Триггер (Trigger)
Сам по себе собранный элемент данных (например, значение «95% загрузки диска») — это просто число в базе. Система не знает, хорошо это или плохо. Триггер — это логическое выражение, которое оценивает полученные данные и определяет состояние системы.Триггер всегда находится в одном из двух состояний: OK или PROBLEM. Логика работы триггера описывается математической функцией. В общем виде вычисление состояния можно представить формулой:
Где — итоговое состояние (True для проблемы, False для нормы), — функция оценки (например, среднее значение), — последние собранные значения метрики, а — пороговое значение (threshold).
Например, триггер может быть настроен так: «Если последнее значение свободного места на диске C: меньше 5 гигабайт, перевести триггер в состояние PROBLEM». Как только приходит новое значение элемента данных, Zabbix Server мгновенно пересчитывает все триггеры, зависящие от этой метрики.
4. Событие (Event)
Каждый раз, когда триггер меняет свое состояние (сOK на PROBLEM или обратно с PROBLEM на OK), Zabbix генерирует Событие. Событие — это историческая запись, фиксирующая факт того, что в конкретную секунду времени произошел инцидент. События формируют ленту проблем, которую инженеры видят на дашбордах.5. Действие (Action)
Генерация события — это лишь констатация факта. Действие — это алгоритм реакции Zabbix на появление события. Действие состоит из условий («Если событие произошло на серверах из группы "Базы данных" и его важность "Высокая"») и операций («Отправить email администратору» или «Выполнить SSH-команду для перезапуска службы»).Пример работы конвейера: Представим мониторинг веб-сервера Nginx.
web-server-01.1 означает, что процесс запущен, 0 — остановлен.0.Масштабирование архитектуры
Описанная выше схема отлично работает для десятков и сотен серверов. Но когда инфраструктура вырастает до тысяч узлов, распределенных по разным странам, классическая схема начинает давать сбои. Сетевые задержки между континентами замедляют сбор данных, а центральный сервер задыхается от миллионов входящих соединений.
Для решения этой проблемы архитектура Zabbix включает еще один фундаментальный компонент — Zabbix Proxy.
Прокси — это промежуточный сервер сбора данных. Он устанавливается в удаленном дата-центре или филиале. Все агенты в этом филиале отправляют свои метрики не на центральный сервер, а на локальный прокси. Прокси собирает данные, буферизирует их в своей собственной небольшой базе данных и затем отправляет на центральный Zabbix Server единым сжатым потоком.
Это решает сразу несколько проблем:
Использование связки Server + Database + Frontend + Proxy позволяет строить системы мониторинга, обрабатывающие десятки тысяч новых значений в секунду (NVPS — New Values Per Second). Понимание того, как эти компоненты передают данные друг другу — от локального процесса агента до записи в таблице history и отображения красного алерта на экране дежурного — является главным фундаментом для дальнейшего изучения логики триггеров, шаблонов и автоматизации.