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

За системой закрепилась репутация тяжеловеса, и напрасно. Связка из официальных пакетов на Ubuntu поднимается меньше чем за час, дальше инфраструктура прирастает машинами почти сама. Ниже разобран полный путь: репозиторий, пакеты, база PostgreSQL, веб-интерфейс, агент на первой наблюдаемой машине и шаблон, после которого метрики начинают течь без ручной работы.

Из чего состоит Zabbix Server и какие версии стоит выбирать

Развёртка складывается из четырёх частей. Служба zabbix-server принимает данные, слушает порт 10051 и пишет историю в базу. База хранит всё, PostgreSQL или MySQL, для материала выбран PostgreSQL. Веб-фронтенд на PHP с Nginx показывает интерфейс. Агенты на наблюдаемых машинах отдают метрики, обычно агент второй версии zabbix-agent2 с модульными плагинами. Для распределённых сетей существует отдельный узел сбора метрик, на первом этапе он не понадобится.

Логика работы прямая: сервер опрашивает агентов по расписанию, либо агент сам подключается и забирает список нужных метрик. Значения падают в базу, триггеры сравнивают их с порогами, сработавшие образуют раздел проблем. Фронтенд просто читает готовое.

С версиями ситуация спокойная. Линейка 7.4 сейчас актуальна, патч 7.4.15 доступен в официальном репозитории на момент подготовки материала. Ветка 7.0 носит пометку LTS и обновляется годами без смены мажорной версии, её берут в консервативные производственные среды. Восьмая линия в репозитории уже открыта, но зеркало исходников пока показывает лишь релиз-кандидат 8.0.0rc1, финального тега нет. Для рабочей установки разумно взять 7.4 или LTS 7.0, ниже команды для 7.4. На других линиях меняется только цифра версии в адресе репозитория.

Подключение официального репозитория и установка пакетов на Ubuntu

Установка идёт из фирменного репозитория, пакеты в базовых дистрибутивах устаревают на годы. Для Ubuntu 22.04 последовательность выглядит так:

wget https://repo.zabbix.com/zabbix/7.4/release/ubuntu/pool/main/z/zabbix-release/zabbix-release_7.4-0.1+ubuntu22.04_all.deb
dpkg -i zabbix-release_7.4-0.1+ubuntu22.04_all.deb
apt update

Для Ubuntu 24.04 имя файла меняется на zabbix-release_7.4-0.1+ubuntu24.04_all.deb, для Debian 12 на zabbix-release_7.4-0.1+debian12_all.deb, остальное без изменений. Нужный deb всегда лежит в каталоге ветки на сервере репозитория, там же видны и поддерживаемые выпуски систем.

Основной набор ставится одной строкой:

apt install zabbix-server-pgsql zabbix-frontend-php zabbix-nginx-conf zabbix-sql-scripts zabbix-agent2

В списке не случайно оказался и агент: серверу тоже полезно наблюдать за самим собой, а отдельный агент на первой рабочей машине ставится тем же способом. Пакет zabbix-sql-scripts содержит дамп начальной схемы базы, без него серверу просто не с чем работать. Пакет zabbix-nginx-conf приносит готовую конфигурацию фронтенда, возиться с виртуальным хостом вручную не придётся.

Создание базы PostgreSQL и импорт стартовой схемы сервера

База создаётся штатными средствами. PostgreSQL ставится из репозитория дистрибутива, дальше три команды:

sudo -u postgres createuser --pwprompt zabbix
sudo -u postgres createdb -O zabbix -E Unicode -T template0 zabbix
zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | sudo -u zabbix psql zabbix

Первая команда создаёт пользователя и просит пароль, его стоит сохранить: пароль понадобится ещё дважды. Вторая создаёт базу с владельцем zabbix и строгой кодировкой. Третья разворачивает схему, дамп занимает десятки мегабайт, импорт идёт минуты, на медленных дисках дольше. Поток строк CREATE TABLE и ALTER TABLE в терминале это норма, а не признак ошибки.

Серверу нужно сообщить пароль. В файле /etc/zabbix/zabbix_server.conf находится строка DBPassword, по умолчанию она пустая:

DBPassword=пароль_из_первого_шага

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

systemctl restart zabbix-server
systemctl enable zabbix-server

Если служба не стартует, причину подскажет журнал:

journalctl -u zabbix-server -n 50

Почти всегда дело в пароле: опечатка в DBPassword даёт классический отказ соединения с базой, строка об этом прямо пишется в журнал.

Запуск панели управления и мастер первичной настройки с нуля

Фронтенд работает через Nginx, конфигурация лежит в файле /etc/zabbix/nginx/conf.d/zabbix.conf. Строки listen и server_name раскомментировываются и приводятся к виду:

listen 8080;
server_name example.com;

Рядом в этом же файле указан сокет PHP. Путь должен совпадать с установленной версией: php8.3-fpm.sock для Ubuntu 24.04, php8.1-fpm.sock для 22.04. Проверить несложно:

ls /run/php/

После правки перезапускаются все участники цепочки:

systemctl restart php8.3-fpm nginx zabbix-agent2
systemctl enable php8.3-fpm nginx zabbix-agent2

В браузере открывается страница на порту 8080 по адресу сервера, дальше работает мастер. Проверка требований выводит список строк PHP, все должны гореть зелёным; ругань на часовой пояс лечится строкой date.timezone в конфиге фронтенда и перезапуском php-fpm. На шаге базы выбирается PostgreSQL, хост localhost, имя базы zabbix, пользователь zabbix, сохранённый пароль. Затем задаётся видимое имя инсталляции, и мастер заканчивается. Занимает всё это минуты три.

Вход выполняется под учётной записью Admin с паролем zabbix. Менять его нужно сразу, пароль по умолчанию у суперпользователя живёт ровно до первого входа. Красная плашка Zabbix server is not running поверх интерфейса означает, что фронтенд не видит службу: сначала проверяется статус systemctl, потом журнал сервера, потом пароль в конфиге.

Установка Zabbix Agent2 на машину и регистрация первого хоста в панели

На наблюдаемой машине повторяется та же процедура с репозиторием, после чего ставится агент:

apt install zabbix-agent2

Конфигурация живёт в файле /etc/zabbix/zabbix_agent2.conf, нужны три строки:

Server=10.0.0.5
ServerActive=10.0.0.5
Hostname=web-01

Первый параметр разрешает опрашивать агент только указанному серверу, второй задаёт адрес, куда агент сам ходит за задачами активных проверок, третий назначает имя, под которым машина станет известна внутри Zabbix. Имя обязано совпасть с будущим хостом в интерфейсе, иначе метрики не найдут получателя. Агент перезапускается, добавляется в автозагрузку, на машинах с активным файрволом открывается его порт:

systemctl restart zabbix-agent2
systemctl enable zabbix-agent2
ufw allow 10050/tcp

Сам сервер уже сидит в списке хостов под именем Zabbix server, агент на нём слушает локальный интерфейс и работает без правок. Для удалённой машины последовательность действий в веб-интерфейсе выглядит так:

  1. Открыть раздел Data collection и пункт Hosts;
  2. Нажать Create host и ввести имя web-01, совпадающее с Hostname агента;
  3. Добавить интерфейс типа Agent с адресом 10.0.0.9 и портом 10050;
  4. Отнести хост в группу Linux servers и присоединить шаблон Linux by Zabbix agent;
  5. Сохранить форму и через минуту увидеть зелёный значок ZBX в колонке Availability.

Значок загорается, когда сервер успешно обменялся с агентом хотя бы одним значением. Поток данных удобно проверять в разделе Monitoring, пункт Latest data: фильтр по хосту выводит метрики процессора, памяти, дисков и сети, клик по строке открывает график. С этой секунды наблюдение за машиной больше не требует SSH.

Отдельно стоит сказать про активные проверки. Параметр ServerActive разрешает агенту самому инициировать соединение с сервером, наружу открывается только порт 10051 на стороне мониторинга. Для машин за NAT это спасение: ничего не нужно публиковать в сеть, агент подключается к серверу сам и забирает очередь метрик. Активный вариант работы настраивается теми же тремя строками конфига, меняется только присоединяемый шаблон, у него в имени есть слово active.

Шаблоны мониторинга и настройка триггеров на первые события

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

Пороги срабатывания спрятаны в макросах с фигурными скобками: {$CPU.UTIL.CRIT} отвечает за критическую нагрузку процессора, {$VFS.FS.PUSED.MAX.CRIT} за заполнение файловых систем. Значения переопределяются на уровне конкретного хоста, сам шаблон остаётся нетронутым: большим архивным томам поднимают порог диска с 90 до 95 процентов, слабым машинам ужесточают порог процессора, чтобы триггер стрелял раньше.

Сработавший триггер появляется в разделе Monitoring, пункт Problems, с уровнем важности от информационного до катастрофического. Условия обычно сдержаны от мигания: триггеру задаётся выдержка в несколько минут, чтобы единичный всплеск не будил инженера ночью. Для плановых работ есть окна обслуживания, внутри них шум гасится, а история инцидентов остаётся честной.

Красивые картинки собираются на отдельном экране. Раздел Dashboards принимает виджеты: график по любому элементу данных, список проблем, карта узлов сети, часы доступности. Готовые графики из шаблона уже на месте, свои собираются за минуты перетаскиванием. Типовая практика: один экран на команду, сверху проблемы, снизу загрузка ключевых машин.

Осталась доставка уведомлений. В настройках профиля задаётся медиа, например адрес почты, а в разделе Alerts создаётся действие: при событии с высоким уровнем важности отправить письмо ответственному. Без действия метрики копятся молча, поэтому первый алерт стоит настроить в тот же вечер, когда поднялся сервер.

Типичные ошибки после установки и тонкая настройка службы сервера

Серые иконки у нового хоста это самая частая жалоба новичков. Причин три: в конфиге агента указан чужой адрес в параметре Server, файрвол режет порт 10050, имя Hostname не совпадает с именем хоста в интерфейсе. Проверка на самой машине:

journalctl -u zabbix-agent2 -n 30

Вторая по частоте ситуация это тишина в разделе проблем при очевидных неполадках. Чаще всего не настроено действие в разделе Alerts, и события просто некому отправлять. Третья ситуация, растущая база: без настройки хранения история копится бесконечно, диск кончается внезапно и в неудобный момент. Срок жизни сырых значений и трендов задаётся в Administration, пункт General, вкладка Housekeeping: часы и дни для детальной истории, годы для агрегированных трендов.

Когда хостов становится десятки, серверу тесно в стартовых настройках. В zabbix_server.conf растут кэши: CacheSize по умолчанию занимает 8 мегабайт, для пары сотен хостов объём поднимают, заодно увеличивают кэш истории и число потоков опроса:

CacheSize=128M
HistoryCacheSize=64M
StartPollers=10

После правки служба перезапускается, предупреждения о переполнении кэша из журнала исчезают.

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

Итоговая картина после часа работы: служба на 10051 собирает метрики, интерфейс на 8080 рисует их графиками, первый хост мигает зелёным, а на почту уходит тестовое уведомление. Однажды триггер сработает раньше, чем неполадку заметит человек. Ради такого момента вся установка и затевалась.