Мониторинг: Часть 4 — Zabbix

Zabbix — система мониторинга «всё в одном»: сбор данных, хранение, триггеры, оповещения, панели и управление доступом собраны в одном продукте. Её выбирают, когда нужно наблюдать за серверами, сетевым оборудованием, базами данных и сайтами из единого интерфейса, не собирая систему из отдельных компонентов.

Версии и лицензия

• Zabbix 7.0 LTS (июнь 2024 года) — ветка с долгосрочной поддержкой: полная поддержка до 30 июня 2027 года, исправления безопасности до 30 июня 2029 года. Для рабочих систем разумно выбирать её.
• Zabbix 7.4 (июнь 2025 года) — текущий стандартный выпуск с новыми возможностями и коротким сроком поддержки.
• Zabbix 6.0 LTS получает только исправления безопасности до февраля 2027 года — пора планировать обновление.

С версии 7.0 Zabbix распространяется под лицензией AGPLv3; до этого с 2001 года использовалась GPLv2. Для компании, которая использует Zabbix у себя, разницы нет. Условия AGPL важны, если вы изменяете код и предоставляете Zabbix как сервис другим.

Из чего состоит Zabbix

• Zabbix Server — центральный процесс: принимает данные, проверяет триггеры, запускает действия и оповещения.
• База данных — хранит конфигурацию и историю. Zabbix 7.4 поддерживает MySQL и Percona (8.0.30 и новее), MariaDB (10.5 и новее), PostgreSQL (13 и новее) и расширение TimescaleDB для PostgreSQL. Oracle больше не поддерживается, SQLite допускается только для прокси.
• Веб-интерфейс на PHP — настройка, панели, отчёты.
• Агенты на наблюдаемых узлах.
• Прокси — промежуточные сборщики для удалённых площадок.

Zabbix agent 2

Есть два агента. Классический написан на C. Zabbix agent 2 — агент нового поколения на Go, который постепенно заменяет первый:

• все проверки выполняются плагинами, причём проверки разных плагинов идут параллельно;
• готовые плагины для PostgreSQL, MySQL, Redis, MongoDB, Docker и других систем не требуют дополнительных скриптов;
• постоянный буфер (EnablePersistentBuffer) сохраняет данные активных проверок при перезапуске и обрыве связи.

Минимальная конфигурация /etc/zabbix/zabbix_agent2.conf:

Server=192.0.2.10
ServerActive=192.0.2.10
Hostname=web01.example.ru

Server — адреса, с которых разрешены пассивные проверки (сервер опрашивает агент). ServerActive — куда агент сам отправляет данные в активном режиме. Hostname должен совпадать с именем узла в веб-интерфейсе. Пакеты агента, сервера и веб-интерфейса устанавливают из официального репозитория по инструкции на zabbix.com/download: там команды подбираются под версию Zabbix, дистрибутив и СУБД.

Шаблоны

Шаблон — готовый набор элементов данных, триггеров, графиков и правил обнаружения. К узлу подключают, например, шаблон «Linux by Zabbix agent», и он сразу получает десятки метрик и разумные триггеры: мало места на диске, высокая загрузка, перезагрузка, недоступность агента.

Правила низкоуровневого обнаружения (LLD) сами находят файловые системы, сетевые интерфейсы, службы и создают для каждого свои метрики. Официальные шаблоны есть для операционных систем, СУБД, веб-серверов, сетевого оборудования по SNMP и облачных сервисов.

Собственные шаблоны стоит строить поверх стандартных и хранить в экспорте (YAML), чтобы переносить между установками.

Прокси

Zabbix Proxy собирает данные вместо сервера и передаёт их пачками. Он нужен, когда:

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

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

Другие возможности

• Сбор данных разными способами: агент, SNMP, IPMI, HTTP-запросы, SSH, ODBC, JMX для Java-приложений.
• Сетевое обнаружение и авторегистрация: новые устройства и агенты добавляются автоматически по правилам.
• Веб-сценарии и браузерные проверки: в 7.0 появился синтетический мониторинг через браузер со снимками экрана.
• Эскалации: если проблема не решена за заданное время, оповещение уходит следующему уровню.
• Двухфакторная аутентификация в веб-интерфейсе (TOTP и Duo) с версии 7.0.

Достоинства

• Всё в одном продукте, с единым интерфейсом и управлением правами.
• Сотни готовых шаблонов, в том числе для сетевого оборудования.
• Зависимости между триггерами: при падении коммутатора не приходят оповещения обо всех серверах за ним.
• Зрелая документация и большое сообщество.

Недостатки

• Нагрузка на базу данных. На больших установках история занимает основной объём и основную нагрузку. Помогают TimescaleDB, разумные сроки хранения истории и трендов, а для редких данных — увеличенный интервал сбора.
• Сложность первоначальной настройки. Нужно разобраться в узлах, элементах данных, триггерах и действиях.
• Менее гибкая работа с данными, чем PromQL: сложную аналитику по меткам удобнее строить в связке Prometheus и Grafana. Grafana при этом умеет подключать Zabbix как источник данных через плагин.

Типичные ошибки

• Один узел — один набор проверок вручную. Проверки настраивают на каждом узле, а не в шаблоне; через полгода конфигурация расходится.
• История хранится вечно. Размер базы растёт до сотен гигабайт. Храните подробную историю недели, а для долгих периодов — тренды.
• Все триггеры с одним уровнем важности. Дежурный получает поток «катастроф» и перестаёт на них реагировать.
• Обновление без проверки. Переход между мажорными версиями меняет схему базы данных; перед обновлением нужна резервная копия и проверка на тестовой копии.