Как установить Zabbix 7.4 в Docker на AlmaLinux 10: полная инструкция по установке и настройке

Zabbix остаётся одной из самых распространённых open-source систем мониторинга, а Docker — самым быстрым способом развернуть её без ручной сборки зависимостей из репозиториев дистрибутива. В этой статье — весь путь по шагам: от чистой виртуальной машины с AlmaLinux 10 до рабочего Zabbix-сервера, который мониторит локальную сеть и внешние сайты, а его веб-панель опубликована в интернете через Nginx Proxy Manager с SSL и двухфакторной аутентификацией.

Инструкция написана по следам реального развёртывания на VMware-виртуалке, поэтому кроме «идеального» пути в ней разобраны и настоящие ошибки, с которыми пришлось столкнуться — с точными текстами из логов и рабочими решениями. Если вы попали на эту страницу через поиск по конкретному сообщению об ошибке (например, «Zabbix agent is not available» или «missing kernel module») — используйте оглавление, чтобы перейти сразу к нужному разделу.

Коротко о статье

Стек: AlmaLinux 10.2, Docker Engine + Compose plugin, PostgreSQL 16, Zabbix Server/Web/Agent 7.4 в отдельных контейнерах. Результат: рабочий Zabbix, доступный из интернета по HTTPS через Nginx Proxy Manager, с 2FA (TOTP), настроенным хранением истории и защитой от перебора паролей. По пути разобраны три реальные сетевые ошибки контейнерного мониторинга «самого себя», ограничение Zabbix на включение MFA для группы администраторов и особенность конфигурации новых образов Zabbix.

Что понадобится

Виртуальная машина с AlmaLinux 10.2, от 2 ГБ RAM для тестового стенда (в этой инструкции — 15 ГБ) и от 20 ГБ диска под данные. Доступ по SSH/консоли с правами root. Исходящий доступ в интернет для скачивания пакетов Docker и образов Zabbix. Если планируется публикация панели наружу — уже развёрнутый Nginx Proxy Manager (NPM) на отдельном хосте и домен с настроенной DNS-записью.

Подготовка ОС

Первое, от чего зависит, будет ли Docker нормально работать сразу или придётся разбираться с ошибками сети — порядок обновления системы. Правильно — обновить ОС и перезагрузиться до установки Docker, а не после:

dnf update -y
reboot

Причина в том, что установка пакетов Docker сама по себе может подтянуть более новое ядро как зависимость, и если сделать это на уже работающей системе, она продолжит работать на старом ядре, пока не случится следующая перезагрузка — а Docker в этот момент попытается использовать сетевые модули ядра, которых там ещё нет. Ниже, в разделе про установку Docker, разобрано, что произойдёт, если пропустить этот шаг.

После перезагрузки стоит проверить, что система и сеть в порядке:

cat /etc/os-release
hostnamectl
free -h
df -h /
ip a

Установка Docker Engine

AlmaLinux 10 не поставляет Docker CE в своих штатных репозиториях, поэтому подключаем официальный репозиторий Docker (ветка для RHEL — совместима с AlmaLinux по ABI):

dnf remove -y podman buildah runc 2>/dev/null
 
dnf install -y dnf-plugins-core
dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
 
dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
 
echo "xt_addrtype" > /etc/modules-load.d/docker.conf
modprobe xt_addrtype
 
systemctl enable --now docker
docker run --rm hello-world

Проблема: Docker не стартует, ошибка «missing kernel module»

Если пропустить обновление ОС из предыдущего раздела и установить Docker на систему, которая тут же подтянула новое ядро как зависимость (но продолжает работать на старом), демон Docker уйдёт в цикл рестарта. В journalctl -xeu docker.service — характерная ошибка:

failed to add jump rules to ipv4 NAT table: ... '/usr/sbin/iptables -t nat -A PREROUTING ... -j DOCKER' failed:
Warning: Extension addrtype revision 0 not supported, missing kernel module?
iptables v1.8.11 (nf_tables): RULE_APPEND failed (No such file or directory)

Причина — недоступен модуль ядра xt_addrtype, который nftables-бэкенд iptables использует для NAT-правил, создаваемых Docker. Решение — перезагрузка на актуальное ядро, затем загрузка модуля и рестарт демона:

reboot
modprobe xt_addrtype
systemctl restart docker
docker run --rm hello-world

Строка echo «xt_addrtype» > /etc/modules-load.d/docker.conf из блока установки выше как раз и нужна, чтобы модуль подгружался автоматически при каждой последующей загрузке — без неё придётся повторять modprobe вручную после каждого ребута.

Настройка firewalld

Если панель Zabbix будет доступна из интернета через прокси (Nginx Proxy Manager), правильная схема — сразу открывать 8080 только для IP прокси-сервера, а не для всех подряд. Порты 10050/10051 (обмен данными агент↔сервер) наружу вообще не публикуются — они нужны только внутри локальной сети:

firewall-cmd --permanent --new-zone=npm-only
firewall-cmd --permanent --zone=npm-only --add-source=10.5.5.5/32
firewall-cmd --permanent --zone=npm-only --add-port=8080/tcp
firewall-cmd --reload
firewall-cmd --zone=npm-only --list-all

(10.5.5.5 — IP хоста Nginx Proxy Manager в локальной сети, замените на свой.) Если панель нужна только во внутренней сети без публикации наружу — просто откройте 8080 без ограничения по source: firewall-cmd —permanent —add-port=8080/tcp.

Предупреждения про ip6tables в статусе firewalld при старте демона — фоновый шум, связанный с IPv6 NAT chains, на работу не влияет.

docker-compose.yml для Zabbix

mkdir -p /opt/zabbix-docker && cd /opt/zabbix-docker
services:
  postgres-server:
    image: postgres:16-alpine
    container_name: zbx-postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: zabbix
      POSTGRES_PASSWORD: замените_на_свой_пароль
      POSTGRES_DB: zabbix
    volumes:
      - zbx_db_data:/var/lib/postgresql/data
 
  zabbix-server:
    image: zabbix/zabbix-server-pgsql:alpine-7.4-latest
    container_name: zbx-server
    restart: unless-stopped
    environment:
      DB_SERVER_HOST: postgres-server
      POSTGRES_USER: zabbix
      POSTGRES_PASSWORD: замените_на_свой_пароль
      POSTGRES_DB: zabbix
      ZBX_TIMEOUT: 15
      ZBX_STATSALLOWEDIP: "10.5.5.0/24"
    ports:
      - "10051:10051"
    depends_on:
      - postgres-server
    volumes:
      - zbx_server_data:/var/lib/zabbix
 
  zabbix-web:
    image: zabbix/zabbix-web-nginx-pgsql:alpine-7.4-latest
    container_name: zbx-web
    restart: unless-stopped
    environment:
      DB_SERVER_HOST: postgres-server
      POSTGRES_USER: zabbix
      POSTGRES_PASSWORD: замените_на_свой_пароль
      POSTGRES_DB: zabbix
      ZBX_SERVER_HOST: zabbix-server
      PHP_TZ: Europe/Moscow
    ports:
      - "8080:8080"
    depends_on:
      - zabbix-server
 
  zabbix-agent:
    image: zabbix/zabbix-agent:alpine-7.4-latest
    container_name: zbx-agent
    network_mode: "service:zabbix-server"
    restart: unless-stopped
    environment:
      ZBX_HOSTNAME: "Zabbix server"
      ZBX_SERVER_HOST: "zabbix-server,127.0.0.1"
    depends_on:
      - zabbix-server
 
volumes:
  zbx_db_data:
  zbx_server_data:

Замените «замените_на_свой_пароль» на реальный пароль — он одинаков во всех трёх сервисах, так как все они работают с одной базой.

Обратите внимание на секцию zabbix-agent — три параметра в ней (network_mode, ZBX_HOSTNAME, второй адрес в ZBX_SERVER_HOST) подобраны не произвольно, а решают конкретную проблему мониторинга самого Zabbix-сервера контейнером агента — она подробно разобрана в разделе «Мониторинг самого Zabbix-сервера» вместе с тремя реальными ошибками, которые возникают без этих параметров.

Запуск:

docker compose up -d
docker compose ps

Запуск и проверка

База данных инициализируется дольше остальных контейнеров, веб-контейнер первые 15-20 секунд может показывать статус health: starting:

sleep 20
docker compose ps
curl -I http://localhost:8080

Все четыре контейнера — Up, zbx-web — (healthy), ответ curl — HTTP/1.1 200 OK. Строки вида «host […] not found» или «connector is not initialized» в логе zabbix-server на этом этапе — норма для только что поднятого сервера, не ошибка.

Открываем http://<IP-сервера>:8080, логин Admin / zabbix.

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

Три вещи стоит сделать в первую же сессию после входа, а не откладывать на потом:

Сменить пароль Admin (иконка профиля → «Change password»).

Настроить хранение истории и трендов: «Administration → Housekeeping», блоки «История» и «Динамика изменений» → включить «Переопределить период хранения истории элементов данных» (например 14d) и «Переопределить период хранения динамики изменения элементов данных» (например 730d). По умолчанию история хранится 31 день, тренды — 365 дней на каждый item индивидуально из шаблона — это первое, что раздувает базу при добавлении реальных хостов. Важный нюанс: галки по умолчанию выключены, а поле ввода при выключенной галке становится серым и неактивным — значение в нём не применится, даже если что-то туда вписано. Проверяйте после сохранения зелёное уведомление «Настройки обновлены».

Настроить политику паролей: «Users → Authentication → вкладка Authentication», блок «Password policy» → «Minimum password length» — 12, отметить все пункты «Password must contain» (буквы разного регистра, цифра, спецсимвол), включить «Avoid easy-to-guess passwords». По умолчанию Zabbix требует только 8 символов без прочих условий.

Публикация через Nginx Proxy Manager

Сценарий: Zabbix-сервер мониторит локальную сеть и внешние сайты, а веб-панель доступна из интернета через Nginx Proxy Manager. Наружу торчит только NPM, порт 8080 самого Zabbix открыт исключительно для него (настроено в разделе про firewalld выше).

В NPM: «Hosts → Proxy Hosts → Add Proxy Host».

Details: Domain Names — ваш домен, Scheme http, Forward Hostname/IP — адрес Zabbix-сервера в локальной сети, Forward Port 8080, Block Common Exploits вкл, Websockets Support вкл.

SSL: «Request a new SSL Certificate», Force SSL вкл, HTTP/2 Support вкл, email для Let’s Encrypt. Для выпуска сертификата домен должен резолвиться из интернета на внешний IP, а порты 80/443 — быть проброшены на NPM.

Advanced — у Zabbix бывают тяжёлые дашборды и импорт больших XML-шаблонов, дефолтные таймауты nginx этого не любят:

client_max_body_size 32M;
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_send_timeout 300;

После сохранения сайт должен открываться с валидным сертификатом.

Дополнительная защита: Access List вместо штатной блокировки Zabbix

Встроенная в Zabbix защита от перебора паролей (блокировка на 30 секунд после 5 неудачных попыток) жёстко зашита в код, не настраивается через интерфейс и блокирует по логину, а не по IP — от целенаправленного брутфорса почти не спасает. Для панели, торчащей в интернет, стоит закрыть её ещё одним слоем на уровне NPM — до того, как запрос вообще дойдёт до формы логина.

«Access Lists → Add Access List» (отдельный пункт меню NPM, не путать с настройками самого Proxy Host). Вкладка «Authorization» — пары логин/пароль для HTTP Basic Auth. Вкладка «Access» — правила Allow/Deny по IP/подсети.

Если есть постоянный внешний IP или VPN с известной подсетью — используйте только «Access» (белый список IP), Satisfy: Any. Если IP переменный — используйте только «Authorization» (Basic Auth), Satisfy: Any. Чтобы совместить оба фактора — заполните обе вкладки, Satisfy: All.

«Pass Auth to Host» должен быть выключен — иначе NPM попробует передать Basic Auth заголовки дальше в Zabbix, а у него своя авторизация. Сохраните список, привяжите его в «Hosts → Proxy Hosts → [ваш домен] → Edit → Details → Access List», проверьте доступ в приватном окне браузера до того, как закроете текущую авторизованную сессию — чтобы не заблокировать самих себя.

Мониторинг самого Zabbix-сервера

Проблема: «Zabbix agent is not available» на хосте Zabbix server

В Zabbix есть предустановленный хост «Zabbix server» — по умолчанию предполагается, что для мониторинга самого сервера агент опрашивается по адресу 127.0.0.1:10050. В контейнерной среде без дополнительной настройки это не работает: zabbix-agent — отдельный контейнер со своим сетевым стеком, 127.0.0.1 внутри контейнера zabbix-server никуда, кроме себя самого, не ведёт. Результат — триггер «Linux: Zabbix agent is not available», а в логе сервера:

cannot send list of active checks to "172.18.0.4": host [zabbix-server-host] not found

Проблема состоит из трёх отдельных причин, и решать их приходится последовательно.

Во-первых, ZBX_HOSTNAME агента по умолчанию не совпадает с именем хоста «Zabbix server» в интерфейсе — активные проверки отбрасываются как «host not found». Решение — точное совпадение имени: ZBX_HOSTNAME: «Zabbix server».

Во-вторых, для пассивных проверок (сервер сам подключается к агенту) можно поменять интерфейс агента на хосте «Zabbix server» в веб-интерфейсе на DNS-имя контейнера — но это отход от дефолтной конфигурации. Более правильный вариант, соответствующий официальным compose-файлам проекта zabbix-docker — посадить агент в тот же network namespace, что и сервер, тогда 127.0.0.1:10050 в интерфейсе хоста «Zabbix server» действительно начинает работать без единой правки в самом Zabbix:

zabbix-agent:
  network_mode: "service:zabbix-server"

В-третьих, после смены network mode встречается ещё одна ошибка — агент отклоняет подключение по IP-белому списку:

Received empty response from Zabbix Agent at [127.0.0.1]. Assuming that agent dropped connection because of access permissions.

Параметр Server в конфиге агента (задаётся через ZBX_SERVER_HOST) по умолчанию содержит только DNS-имя zabbix-server, а после смены network mode запрос физически приходит с 127.0.0.1 — этого адреса в allow-листе нет. Добавляем его явно, только в секции агента:

ZBX_SERVER_HOST: "zabbix-server,127.0.0.1"
docker compose up -d --force-recreate zabbix-agent

После этого доступность хоста «Zabbix server» (бейдж ZBX в «Data collection → Hosts») становится зелёной, а в «Monitoring → Latest data» идут реальные метрики.

Проблема: пересоздание zabbix-server рвёт сеть агента

Если агент делит network namespace с сервером через network_mode: «service:zabbix-server» — при любом docker compose up -d —force-recreate zabbix-server (смена переменных окружения, обновление версии) Docker создаёт для сервера новый контейнер с новым сетевым namespace. Агент, привязанный к старому namespace, тихо остаётся без сети — хост снова падает в «Недоступен», на этот раз с «Connection refused». Лечится пересозданием агента сразу следом за сервером — это стоит превратить в привычку при любой правке zabbix-server в compose:

docker compose up -d --force-recreate zabbix-agent

Особенность: конфиг не подставляет значения переменных текстом

В образах Zabbix 7.4.x конфигурация разбита на набор Include-файлов (/etc/zabbix/zabbix_server_timeouts.conf, zabbix_server_security.conf и т.д.). Если заглянуть внутрь такого файла после смены переменной окружения, там буквально написано Timeout=${ZBX_TIMEOUT}, а не подставленное значение — это нормально, а не признак того, что настройка не применилась. Entrypoint в этой версии образа больше не делает текстовую подстановку — сам процесс zabbix_server читает переменные окружения контейнера напрямую при старте. Проверять применённое значение нужно не через grep по конфигу, а через окружение контейнера:

docker exec zbx-server env | grep -E "ZBX_TIMEOUT|ZBX_STATSALLOWEDIP"

Двухфакторная аутентификация (MFA/TOTP)

«Users → Authentication → вкладка MFA»: включить «Enable multi-factor authentication», добавить метод — Type TOTP, Name (например «Zabbix TOTP»), Hash function SHA-1 (совместим с Google Authenticator, Authy, Microsoft Authenticator), Code length 6. Обязательно нажать «Update» — иначе после перезахода состояние сбросится.

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

Если попытаться включить MFA для штатной группы «Zabbix administrators» («Users → User groups → Zabbix administrators»), поле «Многофакторная аутентификация» окажется некликабельным. Это не баг, а осознанное ограничение Zabbix: для группы, где сосредоточены все пользователи с ролью Super Admin, переключатель блокируется — чтобы не оставить систему совсем без доступа администратора в случае проблем с настройкой TOTP.

Решение — создать отдельную служебную группу: «Users → User groups → Create user group», имя, например, «MFA — TOTP», добавить туда нужных пользователей (права из основной группы сохраняются — пользователь может состоять в нескольких группах одновременно), «Многофакторная аутентификация» в новой группе уже кликабельна → Enabled → выбрать метод → сохранить. Если пользователь состоит хотя бы в одной группе с включённым MFA — при следующем входе Zabbix потребует настройку TOTP, независимо от того, что в основной группе поле по-прежнему показывает «Disabled». После разлогина и повторного входа откроется QR-код для привязки приложения-аутентификатора.

Масштабирование: 100, 500, 1000+ устройств

Конфигурация из раздела про docker-compose рассчитана на демо-нагрузку в десяток хостов. Официальные ориентиры Zabbix по размеру инсталляции:

Класс	Устройств	CPU	RAM сервера	БД
Small	до 100	1-2 ядра	2-4 ГБ	на том же хосте
Medium	до 500	2-4 ядра	4-8 ГБ	на том же хосте или рядом
Large	до 1000	4-8 ядер	8-16 ГБ	желательно отдельный хост
Very Large	более 1000	8+ ядер	16-32 ГБ	отдельный выделенный сервер БД

Это ориентир, а не формула — нагрузка зависит от количества items и частоты опроса (NVPS), а не только от числа устройств. После роста нагрузки открывайте «Reports → System information» — там видно % заполнения кешей; держать его стоит в диапазоне 20-60%. До ~100 устройств хватает дефолта, точечно стоит поднять кеши:

ZBX_STARTPOLLERS: 10
ZBX_CACHESIZE: 16M
ZBX_HISTORYCACHESIZE: 32M
ZBX_HISTORYINDEXCACHESIZE: 8M
ZBX_VALUECACHESIZE: 32M

До ~500 устройств нужно поднять число процессов-опросчиков и кеши, иначе очередь опроса начнёт расти:

ZBX_STARTPOLLERS: 50
ZBX_STARTPOLLERSUNREACHABLE: 10
ZBX_STARTTRAPPERS: 10
ZBX_STARTPREPROCESSORS: 6
ZBX_STARTDISCOVERERS: 3
ZBX_CACHESIZE: 128M
ZBX_HISTORYCACHESIZE: 128M
ZBX_HISTORYINDEXCACHESIZE: 32M
ZBX_TRENDCACHESIZE: 32M
ZBX_VALUECACHESIZE: 256M
ZBX_STARTDBSYNCERS: 8

PostgreSQL на этом объёме уже заметно нагружается записью истории:

command: >
  postgres
  -c shared_buffers=1GB
  -c effective_cache_size=3GB
  -c work_mem=16MB
  -c maintenance_work_mem=256MB

На 1000+ устройств однопроцессный docker-compose стек на одной VM — уже не лучшая архитектура, но при необходимости остаться в её рамках:

ZBX_STARTPOLLERS: 100
ZBX_STARTPOLLERSUNREACHABLE: 20
ZBX_STARTTRAPPERS: 20
ZBX_STARTPREPROCESSORS: 16
ZBX_STARTDISCOVERERS: 5
ZBX_CACHESIZE: 512M
ZBX_HISTORYCACHESIZE: 512M
ZBX_HISTORYINDEXCACHESIZE: 128M
ZBX_TRENDCACHESIZE: 128M
ZBX_VALUECACHESIZE: 1G
ZBX_STARTDBSYNCERS: 20

ZBX_STARTPREPROCESSORS держите не меньше числа ядер CPU. Для PostgreSQL: shared_buffers 6-8 ГБ, effective_cache_size 20+ ГБ, БД лучше вынести на отдельную VM с NVMe/SSD. Обязательно включите партиционирование истории (TimescaleDB либо встроенное партиционирование PostgreSQL, которое Zabbix поддерживает нативно) — без этого хаускипинг на многомиллионных таблицах начнёт просаживать всю БД. При распределённой сети на этом масштабе разверните Zabbix proxy рядом с группами устройств — сервер тогда работает не с 1000+ прямыми устройствами, а с несколькими прокси.

Обновление ОС, Docker и Zabbix

Перед любым обновлением — снапшот VM плюс бэкап базы данных, это дешевле отката вручную.

ОС: dnf update -y, needs-restarting -r для проверки необходимости перезагрузки, reboot при обновлении ядра. Контейнеры с restart: unless-stopped поднимутся сами.

Docker Engine: dnf update docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y, systemctl restart docker.

Zabbix, patch-версии внутри 7.4.x (низкий риск, без изменений схемы БД): бэкап (docker compose exec postgres-server pg_dump -U zabbix zabbix | gzip > backup.sql.gz), затем docker compose pull && docker compose up -d. Важно: если после этого пересоздался zabbix-server, следом обязательно пересоздайте zabbix-agent (docker compose up -d —force-recreate zabbix-agent) — иначе он потеряет сеть, см. раздел про мониторинг сервера выше.

Zabbix, смена мажорной версии (например 7.4 → 7.6): читаем официальные upgrade notes, обязательный бэкап БД, синхронно меняем теги образов у всех трёх компонентов, поднимаем поэтапно — сначала zabbix-server (дожидаемся в логе завершения миграции схемы), потом zabbix-web и zabbix-agent. Для полной предсказуемости обновлений в продакшене используйте точные версии образов вместо плавающих тегов (alpine-7.4.13 вместо alpine-7.4-latest).

Часто задаваемые вопросы

Почему Zabbix agent недоступен при мониторинге собственного Docker-хоста?

Потому что контейнер агента по умолчанию находится в отдельном сетевом пространстве от контейнера сервера, и 127.0.0.1, на который настроен встроенный хост «Zabbix server», внутри контейнера сервера ведёт сам на себя, а не на агент. Решение — network_mode: «service:zabbix-server» у агента плюс совпадающий ZBX_HOSTNAME и добавление 127.0.0.1 в ZBX_SERVER_HOST агента. Подробности — в разделе «Мониторинг самого Zabbix-сервера».

Как включить двухфакторную аутентификацию в Zabbix?

«Users → Authentication → MFA» — создать метод TOTP, затем назначить его не пользователю напрямую, а группе пользователей в «Users → User groups». Для группы с ролью Super Admin переключатель заблокирован — нужно создать отдельную служебную группу под MFA.

Сколько устройств может мониторить один Zabbix-сервер в Docker?

Официальные ориентиры Zabbix: до 100 устройств — 1-2 CPU/2-4 ГБ RAM, до 500 — 2-4 CPU/4-8 ГБ, до 1000 — 4-8 CPU/8-16 ГБ с отдельной БД, свыше 1000 — 8+ CPU/16-32 ГБ и вынесенная БД с партиционированием истории. Реальный лимит зависит от количества items и частоты опроса, а не только от числа хостов.

Как обновить Zabbix в Docker без потери данных?

Сделать бэкап БД через pg_dump перед любым обновлением, для patch-версий внутри одной ветки — docker compose pull && docker compose up -d, для смены мажорной версии — поэтапный подъём с ожиданием завершения миграции схемы БД в логе zabbix-server, с обязательным откатом на бэкап при сбое миграции.

Можно ли обойтись без Nginx Proxy Manager для публикации Zabbix в интернет?

Да, подойдёт любой reverse-proxy с поддержкой Let’s Encrypt (Traefik, Caddy, nginx напрямую) или прямой проброс порта с последующей настройкой TLS в самом Zabbix. NPM в этой статье выбран за простоту веб-интерфейса для управления сертификатами и Access List.