Zabbix: установка и настройка мониторинга серверов

Zabbix Server работает как диспетчерская: сюда стекаются показания всех датчиков-агентов, здесь загораются лампочки тревоги-триггеры и отсюда же оповещается дежурный по нужному каналу. Это зрелая система мониторинга с открытым ядром, которую выбирают под корпоративный парк серверов и ЦОД. Разберем архитектуру Zabbix 7.0 LTS, установку сервера и агентов, работу с шаблонами и триггерами, настройку алертов в Telegram и типовые ошибки, на которых спотыкаются при первом внедрении.

Zabbix — система мониторинга с полностью открытым исходным кодом: ее можно поставить и использовать бесплатно без ограничений по числу хостов, а разработчик зарабатывает на технической поддержке и обучении, а не на лицензиях. Для бизнеса это означает отсутствие платы за масштаб при сохранении возможности купить поддержку. Релизы с пометкой LTS получают пятилетний жизненный цикл — сначала три года с полным сопровождением, затем еще два с ограниченным. Ветку 7.0 выпустили в середине 2024 года, и закрытие приходится на лето 2029-го, поэтому в боевой среде ее разворачивают однажды и несколько лет живут на правках безопасности, не затевая мажорный апгрейд.

От соседей по рынку Zabbix отличает подход «все в одном»: сбор, хранение, триггеры, оповещения и веб-интерфейс идут единым продуктом. Prometheus устроен иначе — это движок сбора метрик, к которому отдельно подключают Grafana и Alertmanager; Checkmk ближе к Zabbix по идее, но строится вокруг готовой библиотеки проверок. Zabbix выбирают, когда нужен один инструмент под железо, сеть и приложения сразу.

Система состоит из нескольких компонентов, и понимание их связей экономит время при установке. Под СУБД с историей метрик подбирают сервер баз данных с быстрыми дисками: именно БД становится узким местом при росте числа метрик. Ядро образуют три части — Zabbix Server принимает и обрабатывает данные, считает триггеры и шлет оповещения; Frontend дает веб-интерфейс на PHP для настройки и просмотра; Database хранит конфигурацию и историю метрик. Их разводят по разным машинам или собирают на одной в зависимости от масштаба. Сам агент на хосте работает в двух режимах: в passive сервер опрашивает его по расписанию, в active агент сам забирает список проверок и отправляет данные, что разгружает сервер и проходит через firewall в одну сторону — для крупных инсталляций предпочтителен именно active.

Для распределенной сети ставят Zabbix Proxy: он собирает метрики локально в удаленной площадке или филиале и пересылает их на главный сервер пакетами, снимая нагрузку с центрального узла и переживая обрывы связи — данные копятся на прокси и догружаются после восстановления канала. Java-приложения по JMX опрашивают через отдельный Java Gateway. Помимо агентов система собирает данные по SNMP, IPMI и через прямые запросы к базам, поэтому одним инструментом закрываются и серверы, и сетевое оборудование.

Перед развертыванием определяют конфигурацию железа и стек ПО, и от этого выбора зависит, как система переживет рост числа хостов, поэтому под Zabbix Server мы подбираем серверы с запасом по памяти и дисковой подсистеме. Парк в пределах пятисот хостов обслуживает машина на четыре ядра, до 16 ГБ оперативной памяти и накопитель NVMe под СУБД. Узким местом тут оказывается не процессор, а диск: поток истории метрик идет непрерывно, и на медленном носителе проседает все. Когда хостов уже тысячи, память наращивают, а базу уносят на отдельный узел.

Zabbix работает с PostgreSQL и MySQL либо MariaDB. Под крупные объемы метрик предпочтителен PostgreSQL с расширением TimescaleDB: оно нарезает историю на партиции по времени и ускоряет очистку старых данных, тогда как для небольших инсталляций разница между базами некритична. Frontend разворачивают на Apache или на связке Nginx с PHP-FPM — второй вариант экономнее по ресурсам. Сама система ставится на Ubuntu и Debian, а также на российские Astra Linux и ALT, для которых есть готовые пакеты; перед установкой обновляют ОС и синхронизируют время.

Развертывание идет по предсказуемой последовательности из официального репозитория. Первый шаг — прописать в системе фирменный репозиторий проекта под вашу версию дистрибутива. После этого ставят серверную часть в сборке под нужную СУБД (для связки с PostgreSQL это пакет с суффиксом pgsql), а вместе с ней веб-интерфейс и агента; остальные зависимости пакетный менеджер вытянет сам. Затем заводят пустую базу с отдельным пользователем и заливают в нее стартовую схему из комплекта поставки — так появляются таблицы под настройки и под историю наблюдений, а на крупных стендах партиционирование через TimescaleDB включают сразу.

Дальше настраивают сервер: в его конфиге указывают параметры подключения к базе, число процессов-сборщиков и кеши под нагрузку, после чего запускают и проверяют журнал на ошибки старта. Завершают установку через веб-мастер — задают параметры БД и часовой пояс. Первый вход выполняют стандартной учетной записью Admin, пароль которой меняют сразу, и после этого интерфейс готов к заведению хостов.

Чтобы сервер увидел машину, на нее ставят агента, а для контроля сетевых узлов вместо агента используют опрос по протоколам — здесь помогает совместимое сетевое оборудование с поддержкой SNMP. Классический Zabbix Agent проверен годами, но Agent 2, написанный на Go, умеет плагины и параллельные проверки и собирает метрики сложных сервисов из коробки, поэтому для новых внедрений рекомендуется именно он. На Linux агент ставят из того же репозитория через apt или dnf, на Windows используют MSI-установщик с указанием адреса сервера, а затем службу запускают и добавляют в автозагрузку. Канал между агентом и сервером закрывают шифрованием — проще всего через предразделяемый ключ PSK; в конфиге агента указывают адрес сервера и метаданные хоста, после чего машину регистрируют в интерфейсе вручную или через автообнаружение по этим метаданным.

Руками заводить сотни проверок на каждый хост никто не станет — для этого есть шаблоны. Template это набор метрик, триггеров и графиков, который привязывают к хосту одним действием. Zabbix идет с библиотекой шаблонов для типовых систем: Linux by Zabbix Agent, Windows by Zabbix Agent и десятки других с сайта templates.zabbix.com. Привязали шаблон к хосту — и базовый мониторинг ОС работает без ручной настройки отдельных метрик. Поверх системных подключают прикладные шаблоны: для PostgreSQL и MySQL через Agent 2, для Nginx и Apache по HTTP — они снимают специфические показатели вроде числа соединений к базе или статуса воркеров веб-сервера.

Динамику закрывает механизм Low-Level Discovery: LLD автоматически заводит проверки по обнаруженным сущностям — файловым системам, сетевым интерфейсам, процессам. Добавили в сервер новый диск — система сама создаст для него метрики занятости без правки конфигурации, что экономит массу ручной работы на меняющихся хостах.

Метрики сами по себе молчат — реакцию задают триггеры и действия. Trigger описывает условие проблемы выражением, которое становится активным при выполнении условия: например, занятость диска выше 90% в течение пяти минут. Синтаксис выражений позволяет учитывать средние значения и динамику, а не только мгновенный замер, что снижает число ложных срабатываний. Каждому триггеру задают уровень важности — от информационного до чрезвычайного, а зависимости между триггерами подавляют дочерние срабатывания: если упал сам хост, нет смысла слать отдельные алерты по каждому его сервису.

Оповещения настраивают через Actions: при срабатывании триггера система выполняет операцию — отправку уведомления. Самый популярный канал в РФ это Telegram через webhook и bot API, настройка которого занимает около десяти минут; параллельно подключают email через SMTP-relay и при необходимости Mattermost.

Собранные данные показывают через встроенные дашборды Zabbix без сторонних инструментов. Экран собирают из виджетов: графики метрик, индикаторы-gauges, карты сети, список текущих проблем — последний выводит активные срабатывания в реальном времени и служит основным экраном для дежурного. Готовые дашборды дают разным группам с нужным уровнем доступа: дежурным экран проблем, инженерам детальные графики. Разграничение прав не дает случайно сломать чужую настройку и держит у каждого экрана своего владельца.

Развернутая система требует регулярного обслуживания, иначе база разрастается и тормозит. Встроенный housekeeping чистит устаревшую историю и тренды по заданной политике хранения, но на больших инсталляциях штатной очистки мало — подключают партиционирование через TimescaleDB, иначе удаление старых записей само становится нагрузкой на базу. Переход между LTS-версиями, например с 6.0 на 7.0, проходит штатно: останавливают сервер, обновляют пакеты, при первом запуске база мигрирует на новую схему автоматически, но перед этим обязательно снимают резервную копию.

Бэкапят два объекта — конфигурацию и базу данных. Конфигурацию хостов и шаблонов выгружают штатным экспортом, базу стандартными средствами СУБД. Без копии восстановление после сбоя превращается в перенастройку всей системы заново.

Развертывание Zabbix в РФ имеет свою специфику. Сам продукт создан зарубежной компанией и в реестр российского ПО не входит, но для заказчиков с требованием реестра существуют отечественные продукты на его базе — «Пульт» и форк Glaber, которые сохраняют логику Zabbix, но имеют реестровую запись. Пакеты при этом ставят из российских зеркал, чтобы не зависеть от доступности зарубежного репозитория, а для отечественных ОС Astra Linux и ALT доступны проверенные сборки под их версии.

Техническую поддержку и внедрение получают через локальных интеграторов, в том числе для шаблонов под российские системы — Postgres Pro и платформу 1С. Это закрывает вопрос сопровождения без прямого контракта с зарубежным вендором.

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

Сводка по ключевым развилкам при настройке Zabbix.

Чтобы Zabbix реально ловил инциденты, а не превращался в источник шума, проходят несколько контрольных точек:

Пройденный чек-лист отличает рабочую систему от той, что тихо разрастается и однажды встает.

Текущая LTS-версия — Zabbix 7.0, вышедшая в июне 2024 года с поддержкой до июня 2029-го. Для production берят именно ее. Параллельно развивается более свежая mainline-ветка с новыми функциями, но без длинной поддержки.

Для 100-500 хостов хватает 2-4 ядер, 8-16 ГБ RAM и NVMe SSD под базу. Диск важнее процессора: история метрик пишется непрерывно. Под тысячи хостов память увеличивают и выносят БД на отдельную машину, а на 5000+ хостов сбор распределяют через Zabbix Proxy.

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

Agent 2 написан на Go, поддерживает плагины и параллельные проверки, собирает метрики сложных сервисов из коробки. Классический агент проще, но менее гибок. Для новых хостов рекомендуется Agent 2.

Создают бота через BotFather, получают токен, заводят в Zabbix медиатип с webhook и привязывают его к действию по триггеру. Настройка занимает около десяти минут и стала массовым стандартом оповещений в РФ.

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

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

Да, через Zabbix Agent для Windows с MSI-установщиком и готовый шаблон Windows by Zabbix Agent. Система снимает метрики служб, процессов, дисков и журналов событий наравне с Linux-хостами.

Разворачиваете Zabbix на парк серверов? Инженеры Serverzilla подберут сервер под Zabbix Server и базу, развернут агенты на Linux и Windows, настроят шаблоны, триггеры и алерты в Telegram. Поможем с партиционированием базы и прокси для филиалов. Начнем с аудита ИТ-инфраструктуры. Оставьте заявку.