Zabbix proxy: установка и настройка 7.0 и 6.4 пошагово

Минимальный рабочий конфиг активного прокси 7.0 на SQLite выглядит так. Ниже разберём каждую строку и всё, что вокруг.

# /etc/zabbix/zabbix_proxy.conf на прокси zbx-proxy-01
ProxyMode=0
Server=10.10.0.10
Hostname=zbx-proxy-01
DBName=/var/lib/zabbix/zabbix_proxy.db
LogFile=/var/log/zabbix/zabbix_proxy.log
PidFile=/run/zabbix/zabbix_proxy.pid
SocketDir=/run/zabbix

Диагноз: зачем нужен Zabbix proxy и почему он «висит серым»

Zabbix proxy поднял в филиале, а в веб-интерфейсе он серый и пишет «последний раз видели: никогда». Агенты молчат, очередь растёт. Знакомо?

Смотри. Zabbix proxy — это сборщик данных, который работает от имени сервера. Он опрашивает агенты, SNMP, HTTP и всё остальное у себя в сегменте, складывает данные в локальный буфер и пачками отправляет на сервер. Сервер отдаёт ему конфигурацию: какие хосты, какие элементы данных, с какими интервалами.

По факту прокси решает три задачи. Разгружает сервер, когда хостов тысячи. Даёт мониторинг удалённых площадок через одно TCP-соединение вместо сотни. И не теряет данные, когда канал до центра падает: копит у себя и досылает потом.

Что получишь после статьи: рабочий активный прокси 7.0 LTS с шифрованием PSK, проверенный по логам и через API, с мониторингом самого себя, бэкапом и планом обновления. Плюс разбор ошибок, на которых спотыкаются чаще всего, включая загадочный «zabbix proxy 7 invalid option».

Время: 30-40 минут на чистой машине. Если с шифрованием и группами прокси, закладывай час.

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

• Работающий Zabbix server, у нас 7.0 LTS на хосте zbx-server с адресом 10.10.0.10.
• Виртуалка или железка под прокси: zbx-proxy-01, 192.168.50.20, Ubuntu 24.04.
• Root или sudo на прокси и права администратора в веб-интерфейсе Zabbix.
• Сетевой доступ от прокси к серверу по 10051/tcp.

Что будет в статье:

• Как устроен прокси и чем активный режим отличается от пассивного.
• Семь причин, почему прокси не подключается.
• Установка на Ubuntu, Debian и RHEL, вариант с PostgreSQL для больших площадок.
• Шифрование PSK и группы прокси в 7.0.
• Проверка: логи, порты, база, API.
• Ошибки с готовыми командами, включая invalid option и unknown parameter.
• Альтернативы, профилактика, бэкап, обновление и FAQ.

Архитектура: где стоит прокси и куда ходят данные

Прежде чем ставить, посмотри на схему. Половина проблем с прокси — это непонимание, кто к кому подключается.

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart TD
    A["Агенты филиала"] --> P["Zabbix proxy"]
    S1["SNMP-устройства"] --> P
    H1["HTTP и ICMP проверки"] --> P
    P --> B["Локальный буфер прокси"]
    B --> Z["Zabbix server"]
    Z --> D["База данных сервера"]
    W["Веб-интерфейс"] --> Z
    style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style S1 fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style H1 fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style P fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style B fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style Z fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style D fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style W fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af

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

Активный или пассивный прокси: что выбрать

Режим определяет направление соединения. Активный прокси сам стучится на сервер, забирает конфигурацию и отдаёт данные. Пассивный ждёт, когда сервер придёт к нему сам.

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#f8fafc',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'noteBkgColor': '#fefce8',
    'noteTextColor': '#713f12',
    'noteBorderColor': '#fbbf24',
    'actorBkg': '#f8fafc',
    'actorBorder': '#94a3b8',
    'actorTextColor': '#1e293b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'sequence': {
    'mirrorActors': false,
    'messageAlign': 'center',
    'actorMargin': 120,
    'width': 160,
    'noteMargin': 12
  }
}}%%
sequenceDiagram
    participant P as Активный прокси
    participant S as Zabbix server
    Note over P,S: Соединение всегда открывает прокси
    P->>S: Запрос конфигурации
    S->>P: Список хостов и элементов
    P->>S: Пачка собранных данных
    S->>P: Подтверждение приёма

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

Причины: почему Zabbix proxy не подключается к серверу

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

Первая причина обгоняет все остальные с большим отрывом. Однажды я полдня искал, почему прокси в филиале не регистрируется. Сеть чистая, порты открыты, версии совпадают. Оказалось, в интерфейсе имя было «Zbx-Proxy-Kazan», а в конфиге «zbx-proxy-kazan». Одна заглавная буква стоила шести часов. Ну и запросы у вас, сказал сервер, и молча закрыл сокет.

Пятая причина — моя любимая, потому что её создают сами админы. Копируют конфиг со старого прокси 5.0 на новый 7.0, а там параметры, которых уже нет или которые поменяли смысл. Прокси читает файл, видит незнакомое слово и не запускается.

Рецепт: установка Zabbix proxy 7.0 пошагово

Системные требования

На момент публикации актуальна ветка Zabbix 7.0 LTS для продакшна и 7.4 как стабильная с полной поддержкой до выхода 8.0. Ветка 8.0 LTS находится на стадии release candidate: первый RC вышел 1 октября 2026 года. Перед установкой проверь свежие релизы на странице release notes и сроки поддержки в политике жизненного цикла Zabbix.

Про Zabbix 6.4 отдельно. В официальной документации ветка 6.4 уже значится в списке неподдерживаемых. Если у тебя сервер 6.4, прокси ставь тоже 6.4, иначе не заведётся. Но честно: планируй переезд на 7.0 LTS, потому что исправления безопасности для 6.4 больше не выходят.

Таблица портов

Подготовка: проверь среду до установки

Три минуты на проверку экономят час на диагностику. Сначала имя хоста и время. Время критично: если часы прокси убежали, данные приезжают на сервер с кривыми метками, и графики превращаются в абстракционизм.

# На прокси zbx-proxy-01: имя, ОС и синхронизация времени
hostnamectl
timedatectl status
sudo apt update && sudo apt install -y chrony netcat-openbsd sqlite3 jq
sudo systemctl enable --now chrony
chronyc tracking | head -n 5

Результат: в выводе timedatectl строка System clock synchronized: yes, в chronyc tracking смещение в миллисекундах, а не в минутах.

Теперь сеть. С прокси проверь, что порт сервера отвечает. Если здесь пусто, дальше можно не идти, сначала чини маршрут или firewall.

# На прокси zbx-proxy-01: доступен ли порт сервера
nc -zv 10.10.0.10 10051

Ожидаемый ответ: Connection to 10.10.0.10 10051 port [tcp/*] succeeded. Если видишь timed out, пакеты режет firewall по дороге. Если Connection refused, до сервера доходишь, но там никто не слушает или сервер отклоняет.

Заодно проверь версию сервера. Её видно внизу веб-интерфейса или на самом сервере одной командой.

# На сервере zbx-server: версия Zabbix server
zabbix_server -V | head -n 1

Запомни мажорную ветку, например 7.0. Ровно её и будем ставить на прокси.

Шаг 1. Подключи репозиторий Zabbix

Зачем: в стандартных репозиториях дистрибутива Zabbix либо старый, либо собран не так, как официальный. Официальный репозиторий даёт актуальные минорные версии и одинаковые пути к файлам на всех машинах.

Ubuntu 24.04, ветка 7.0:

# На прокси zbx-proxy-01 (Ubuntu 24.04): репозиторий Zabbix 7.0
cd /tmp
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.0+ubuntu24.04_all.deb
sudo dpkg -i zabbix-release_latest_7.0+ubuntu24.04_all.deb
sudo apt update

Debian 12:

# На прокси zbx-proxy-01 (Debian 12): репозиторий Zabbix 7.0
cd /tmp
wget https://repo.zabbix.com/zabbix/7.0/debian/pool/main/z/zabbix-release/zabbix-release_latest_7.0+debian12_all.deb
sudo dpkg -i zabbix-release_latest_7.0+debian12_all.deb
sudo apt update

RHEL 9 и совместимые. Здесь есть подводный камень: если подключён EPEL, он подсовывает свои пакеты zabbix и ломает установку. Исключи их до подключения официального репозитория.

# На прокси zbx-proxy-01 (RHEL 9): исключить zabbix из EPEL, если EPEL подключён
sudo sed -i '/^\[epel\]/a excludepkgs=zabbix*' /etc/yum.repos.d/epel.repo

# Там же: репозиторий Zabbix 7.0
sudo rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rhel/9/x86_64/zabbix-release-latest-7.0.el9.noarch.rpm
sudo dnf clean all

Результат: apt update или dnf makecache показывает строку с repo.zabbix.com без предупреждений о ключе. Если wget вернул 404, имя файла поменяли. Открой страницу загрузки Zabbix, выбери версию, ОС, компонент Proxy и скопируй актуальную ссылку оттуда.

Для сервера 6.4 логика та же, только в URL ветка 6.4 и дистрибутив, для которого 6.4 собиралась. Пример для Ubuntu 22.04, перед запуском сверь ссылку на странице загрузки:

# На прокси (Ubuntu 22.04), ТОЛЬКО если сервер на 6.4: репозиторий Zabbix 6.4
cd /tmp
wget https://repo.zabbix.com/zabbix/6.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.4-1+ubuntu22.04_all.deb
sudo dpkg -i zabbix-release_6.4-1+ubuntu22.04_all.deb
sudo apt update

Шаг 2. Установи пакет прокси

Зачем выбирать пакет с базой: прокси собирается под конкретную СУБД. Пакет zabbix-proxy-sqlite3 содержит бинарник с поддержкой SQLite, zabbix-proxy-pgsql с PostgreSQL, zabbix-proxy-mysql с MySQL. Сменить базу потом можно только сменой пакета.

Для филиала на сотню хостов бери SQLite. Отдельный сервер СУБД ради буфера — это как ставить сейф для хранения мелочи на проезд.

# На прокси zbx-proxy-01 (Ubuntu/Debian): прокси с SQLite и fping для ICMP-проверок
sudo apt install -y zabbix-proxy-sqlite3 zabbix-sql-scripts fping

# На прокси zbx-proxy-01 (RHEL 9): то же самое через dnf
sudo dnf install -y zabbix-proxy-sqlite3 zabbix-sql-scripts fping

Результат: пакет встал, появился файл /etc/zabbix/zabbix_proxy.conf и служба zabbix-proxy. Проверь версию бинарника.

# На прокси zbx-proxy-01: версия установленного прокси
zabbix_proxy -V | head -n 1
which fping

Первая строка должна показывать ту же ветку, что у сервера. Путь к fping запомни: на Ubuntu и Debian это обычно /usr/bin/fping, а в конфиге по умолчанию стоит /usr/sbin/fping. Несовпадение пути — тихая причина, по которой ICMP-проверки переходят в «не поддерживается».

Шаг 3. Подготовь каталог для базы SQLite

Зачем: прокси работает от пользователя zabbix. Если каталога под базу нет или он принадлежит root, прокси не сможет создать файл и упадёт при старте.

# На прокси zbx-proxy-01: каталог под базу с правильным владельцем
sudo install -d -o zabbix -g zabbix -m 750 /var/lib/zabbix
ls -ld /var/lib/zabbix

Результат: drwxr-x— zabbix zabbix /var/lib/zabbix.

Схему SQLite прокси современных версий создаёт сам при первом запуске, если файла базы нет. Если по какой-то причине файл не появился, создай базу из штатного скрипта. Сначала проверь, что скрипт на месте.

# На прокси zbx-proxy-01: ручное создание базы, ТОЛЬКО если прокси не создал её сам
ls /usr/share/zabbix-sql-scripts/sqlite3/
sudo -u zabbix sqlite3 /var/lib/zabbix/zabbix_proxy.db < /usr/share/zabbix-sql-scripts/sqlite3/proxy.sql

Шаг 4. Настрой zabbix_proxy.conf

Здесь решается всё. Штатный конфиг — это 1000+ строк комментариев и пара десятков параметров. Я предпочитаю минималистичный файл, где каждая строка что-то значит и понятно, зачем она там. Оригинал не удаляем, переименовываем: пригодится как справочник.

# На прокси zbx-proxy-01: сохранить штатный конфиг как справочник
sudo cp -a /etc/zabbix/zabbix_proxy.conf /etc/zabbix/zabbix_proxy.conf.orig

Теперь пишем рабочий конфиг. Замени адрес сервера и имя прокси на свои.

# На прокси zbx-proxy-01: записать рабочий конфиг активного прокси 7.0
sudo tee /etc/zabbix/zabbix_proxy.conf > /dev/null <<'EOF'
############ ОСНОВНОЕ ############
# 0 = активный прокси, 1 = пассивный
ProxyMode=0
# Адрес Zabbix server. Порт по умолчанию 10051, нестандартный пишется через двоеточие
Server=10.10.0.10
# Имя прокси. Должно СОВПАДАТЬ с именем в веб-интерфейсе, с учётом регистра
Hostname=zbx-proxy-01
ListenPort=10051

############ ЛОГИ И СЛУЖЕБНОЕ ############
LogFile=/var/log/zabbix/zabbix_proxy.log
LogFileSize=10
DebugLevel=3
PidFile=/run/zabbix/zabbix_proxy.pid
SocketDir=/run/zabbix

############ БАЗА ############
DBName=/var/lib/zabbix/zabbix_proxy.db

############ БУФЕР ДАННЫХ ############
# Сколько часов хранить данные, если сервер недоступен
ProxyOfflineBuffer=24
# Не хранить данные локально после отправки
ProxyLocalBuffer=0
# Гибридный буфер 7.0: память, при переполнении диск
ProxyBufferMode=hybrid
ProxyMemoryBufferSize=16M

############ СИНХРОНИЗАЦИЯ С СЕРВЕРОМ ############
# Как часто запрашивать конфигурацию, секунды
ProxyConfigFrequency=10
# Как часто отправлять данные, секунды
DataSenderFrequency=1

############ СБОРЩИКИ ############
StartPollers=5
StartPingers=1
StartTrappers=5
Timeout=4
FpingLocation=/usr/bin/fping

############ БЕЗОПАСНОСТЬ ############
StatsAllowedIP=127.0.0.1
LogSlowQueries=3000
EOF

Разберём неочевидные строки.

Server. В активном режиме здесь один адрес сервера или кластер HA. Узлы кластера перечисляются через точку с запятой. Нестандартный порт пишется прямо в значении через двоеточие. Старый параметр ServerPort в 7.0 объявлен устаревшим, прокси будет предупреждать в логе.

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

ProxyBufferMode. Появился в 7.0. Варианты: disk, memory, hybrid. Disk пишет всё в базу, как в 6.x. Memory держит данные в оперативке и теряет их при перезапуске. Hybrid держит в памяти, а при переполнении или долгом простое сервера сбрасывает на диск. Для филиала hybrid — лучший компромисс: меньше нагрузка на диск, данные не теряются при обрыве канала. При режимах memory и hybrid обязательно задать ProxyMemoryBufferSize, иначе прокси не стартует.

ProxyConfigFrequency. В 6.4 заменил старый ConfigFrequency. Если тащишь конфиг с 6.0, найди и переименуй.

FpingLocation. Поставь путь, который показал which fping на шаге 2.

Перед запуском проверь синтаксис. В 7.x у бинарника есть ключ -T: он читает конфиг, валидирует параметры и выходит, ничего не запуская.

# На прокси zbx-proxy-01: проверка конфига без запуска
sudo -u zabbix zabbix_proxy -T -c /etc/zabbix/zabbix_proxy.conf

Результат: пустой вывод или сообщение об успешной проверке, код возврата 0. Если видишь ошибку про параметр, исправь до запуска. Если сам ключ -T не распознан и бинарник ругается invalid option, у тебя старая сборка без этого ключа. Об этом подробно в «Осложнениях».

Шаг 5. Создай прокси в веб-интерфейсе

Зачем: сервер не узнаёт о прокси сам. Пока в интерфейсе нет записи с таким именем, сервер на все подключения отвечает «не знаю такого».

Открой веб-интерфейс: Администрирование → Прокси → Создать прокси. Заполни поля:

Вкладку «Шифрование» пока не трогай, подключим PSK отдельным шагом после того, как связка заработает без него. Так проще локализовать проблему: сначала связь, потом шифрование.

Поле «Адрес прокси» советую заполнить. Это бесплатный слой защиты: даже если кто-то узнает имя прокси, подключиться с чужого адреса не получится. За NAT вписывай адрес, с которого прокси выходит наружу, его видно в логе сервера.

Шаг 6. Открой firewall и запусти прокси

Зачем: агенты филиала будут отправлять активные проверки на прокси по 10051. Порт нужно открыть только для своей сети.

# На прокси zbx-proxy-01 (Ubuntu/Debian, UFW): SSH и 10051 только из сети филиала
sudo ufw allow from 192.168.50.0/24 to any port 22 proto tcp
sudo ufw allow from 192.168.50.0/24 to any port 10051 proto tcp
sudo ufw enable
sudo ufw status numbered

# На прокси zbx-proxy-01 (RHEL 9, firewalld и SELinux)
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.50.0/24" port port="10051" protocol="tcp" accept'
sudo firewall-cmd --reload
sudo setsebool -P zabbix_can_network on

На сервере открой 10051 для адреса, с которого приходит прокси. Если сервер за своим firewall, без этой строки прокси никогда не достучится.

# На сервере zbx-server (UFW): принимать прокси только с его адреса
sudo ufw allow from 192.168.50.20 to any port 10051 proto tcp

Теперь запуск и автозапуск.

# На прокси zbx-proxy-01: включить автозапуск и стартовать
sudo systemctl enable --now zabbix-proxy
sudo systemctl status zabbix-proxy --no-pager

Результат: статус active running. Если failed, сразу смотри журнал, там будет конкретная строка с причиной.

# На прокси zbx-proxy-01: последние строки журнала службы и лога прокси
sudo journalctl -u zabbix-proxy -n 30 --no-pager
sudo tail -n 30 /var/log/zabbix/zabbix_proxy.log

Шаг 7. Перенеси хосты на прокси

Зачем: сам по себе прокси ничего не собирает. Ему нужно назначить хосты. Открой хост: Сбор данных → Узлы сети → нужный хост, в поле «Наблюдение через» выбери «Прокси» и укажи zbx-proxy-01. Для массового переноса отметь хосты галками и используй «Массовое обновление».

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

# /etc/zabbix/zabbix_agent2.conf на каждом агенте филиала
Server=192.168.50.20
ServerActive=192.168.50.20
Hostname=имя-хоста-как-в-интерфейсе

# На каждом агенте филиала: применить изменения
sudo systemctl restart zabbix-agent2

Не перепутай: Server у агента — это кто имеет право его опрашивать, ServerActive — куда агент сам отправляет данные. После переноса хоста на прокси оба должны указывать на прокси. Классика жанра: хост перенесли, а в агенте оставили адрес центрального сервера. Сервер отклоняет активные проверки, потому что хост теперь «принадлежит» прокси.

Шаг 8. Включи шифрование PSK

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

Сгенерируй ключ на прокси:

# На прокси zbx-proxy-01: сгенерировать PSK и закрыть права
openssl rand -hex 32 | sudo tee /etc/zabbix/zabbix_proxy.psk > /dev/null
sudo chown zabbix:zabbix /etc/zabbix/zabbix_proxy.psk
sudo chmod 640 /etc/zabbix/zabbix_proxy.psk
sudo cat /etc/zabbix/zabbix_proxy.psk

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

# На прокси zbx-proxy-01: добавить PSK-шифрование в конфиг
sudo tee -a /etc/zabbix/zabbix_proxy.conf > /dev/null <<'EOF'

############ ШИФРОВАНИЕ ############
TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=PSK-zbx-proxy-01
TLSPSKFile=/etc/zabbix/zabbix_proxy.psk
EOF
sudo -u zabbix zabbix_proxy -T -c /etc/zabbix/zabbix_proxy.conf

TLSConnect отвечает за то, как прокси подключается к серверу. TLSAccept — за то, какие входящие подключения принимает прокси от агентов и zabbix_sender. Если агенты филиала пока без шифрования, поставь TLSAccept=unencrypted,psk, иначе прокси начнёт отбивать их активные проверки.

Теперь в веб-интерфейсе: Администрирование → Прокси → zbx-proxy-01 → вкладка «Шифрование». Для активного прокси отметь «Подключения от прокси: PSK», впиши PSK identity и сам ключ. Identity должна совпадать с TLSPSKIdentity символ в символ.

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

# На прокси zbx-proxy-01: применить шифрование и проверить лог
sudo systemctl restart zabbix-proxy
sudo tail -f /var/log/zabbix/zabbix_proxy.log

Результат: в логе нет строк с TLS и PSK, есть регулярные сообщения о получении конфигурации. В интерфейсе в колонке «Шифрование» у прокси появляется значок PSK.

Шаг 9. Вариант для больших площадок: PostgreSQL вместо SQLite

SQLite упирается в запись, когда прокси собирает тысячи значений в секунду или сервер надолго недоступен и буфер раздувается до гигабайтов. Ориентир такой: до нескольких сотен значений в секунду SQLite справляется без вопросов, дальше смотри на загрузку диска и время отправки данных. Если упираешься, переходи на PostgreSQL.

# На прокси zbx-proxy-01: прокси с PostgreSQL вместо SQLite
sudo apt install -y postgresql zabbix-proxy-pgsql zabbix-sql-scripts
sudo -u postgres createuser --pwprompt zabbix_proxy
sudo -u postgres createdb -O zabbix_proxy zabbix_proxy
psql "postgresql://zabbix_proxy@127.0.0.1/zabbix_proxy" -f /usr/share/zabbix-sql-scripts/postgresql/proxy.sql

Отдельный пользователь базы с правами только на свою базу — обязательное условие. Не давай прокси суперпользователя postgres, даже если «так быстрее». В конфиге прокси замени блок базы:

# /etc/zabbix/zabbix_proxy.conf на прокси zbx-proxy-01, вариант PostgreSQL
DBHost=127.0.0.1
DBName=zabbix_proxy
DBUser=zabbix_proxy
DBPassword=сюда_пароль_из_createuser

Пароль в открытом виде в конфиге — компромисс. Закрой файл правами 640 с владельцем root:zabbix. Если в компании есть HashiCorp Vault или CyberArk, прокси 7.0 умеет брать учётные данные базы оттуда через параметры Vault, это описано в справочнике параметров zabbix_proxy.conf.

# На прокси zbx-proxy-01: закрыть конфиг с паролем
sudo chown root:zabbix /etc/zabbix/zabbix_proxy.conf
sudo chmod 640 /etc/zabbix/zabbix_proxy.conf

Шаг 10. Группы прокси в Zabbix 7.0: балансировка и отказоустойчивость

Начиная с 7.0 прокси можно объединять в группы. Сервер сам раскидывает хосты между прокси группы и при падении одного перекидывает его хосты на живые. Раньше для этого городили keepalived и общий IP.

Настройка: Администрирование → Группы прокси → Создать группу. Задай «Минимальное количество прокси», при котором группа считается рабочей, и «Тайм-аут переключения». Затем в карточке каждого прокси укажи группу и «Адрес для активных агентов» — адрес, по которому агенты будут к нему подключаться.

Хостам в поле «Наблюдение через» выбирай уже не конкретный прокси, а «Группа прокси». Агентам в ServerActive перечисли все прокси группы через точку с запятой: агент получит от любого из них указание, на какой прокси слать данные.

# /etc/zabbix/zabbix_agent2.conf на агенте, хосты которого обслуживает группа прокси
ServerActive=192.168.50.20;192.168.50.21
Server=192.168.50.20,192.168.50.21

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

Настройка пассивного прокси, если без него никак

Если политика безопасности требует пассивный режим, отличий три: ProxyMode=1, в Server перечисляются адреса, с которых сервер имеет право подключаться, и сервер должен иметь свободных сборщиков для прокси.

# /etc/zabbix/zabbix_proxy.conf на прокси, пассивный режим
ProxyMode=1
# В пассивном режиме здесь ТОЛЬКО список адресов через запятую, без портов кластера
Server=10.10.0.10
Hostname=zbx-proxy-01

# /etc/zabbix/zabbix_server.conf на сервере zbx-server: опрос пассивных прокси
StartProxyPollers=2
ProxyConfigFrequency=10
ProxyDataFrequency=1

В веб-интерфейсе режим «Пассивный» и интерфейс с адресом и портом прокси. На прокси порт 10051 открывай только для адреса сервера. Вот тут важно: в 7.0 проверка значения Server в пассивном режиме ужесточилась. Если оставишь там синтаксис кластера через точку с запятой, как для активного режима, прокси не стартует и прямо скажет, что в пассивном режиме допускается только список адресов через запятую.

Проверка: как убедиться, что Zabbix proxy работает правильно

«Служба запущена» ещё ничего не значит. Прокси может работать часами, не получив от сервера ни одного хоста. Проверяем по слоям: процесс, сеть, обмен с сервером, данные.

Процесс и порт

# На прокси zbx-proxy-01: служба жива и слушает 10051
systemctl is-active zabbix-proxy
sudo ss -tlnp | grep 10051

Ожидаешь: active и строку LISTEN на 0.0.0.0:10051 с процессом zabbix_proxy.

Обмен с сервером по логу

# На прокси zbx-proxy-01: ищем признаки обмена и ошибки
sudo grep -iE 'received configuration|cannot|error|failed' /var/log/zabbix/zabbix_proxy.log | tail -n 20

Хороший признак — строки про получение конфигурации от сервера с размером данных. Плохой — любые cannot connect, cannot send и not found. Каждую такую строку разберём в «Осложнениях».

Обрати внимание на одну деталь. Активный прокси 7.0 по умолчанию запрашивает конфигурацию каждые 10 секунд, но сервер отдаёт её полностью только при изменениях. Поэтому строк с большим объёмом данных будет немного, и это нормально.

Конфигурация доехала до базы

# На прокси zbx-proxy-01: сколько хостов и элементов прокси получил от сервера
sudo -u zabbix sqlite3 /var/lib/zabbix/zabbix_proxy.db "select count(*) from hosts;"
sudo -u zabbix sqlite3 /var/lib/zabbix/zabbix_proxy.db "select count(*) from items;"

Числа больше нуля — конфигурация доходит. Ноль хостов при назначенных в интерфейсе хостах значит, что прокси до сервера не достучался или сервер его не опознал.

Не пугайся, если таблица proxy_history почти пустая. В режиме hybrid данные живут в памяти и на диск попадают только при переполнении буфера или долгом отсутствии связи. Пустая таблица истории при живой связи — это как раз правильное поведение.

Взгляд со стороны сервера

В веб-интерфейсе Администрирование → Прокси смотри три колонки: «Последний раз видели» должна обновляться каждые несколько секунд, «Версия» должна показывать версию без предупреждений, «Количество узлов сети» должно совпадать с назначенными.

То же самое через API, удобно для скриптов и проверок по расписанию. Токен создаётся в Пользователи → API токены.

# На любой машине с доступом к веб-интерфейсу Zabbix: статус всех прокси через API
export ZBX_URL="https://zabbix.example.local/api_jsonrpc.php"
export ZBX_TOKEN="вставь_сюда_api_токен"
curl -s -X POST "$ZBX_URL" \
  -H 'Content-Type: application/json-rpc' \
  -H "Authorization: Bearer $ZBX_TOKEN" \
  -d '{"jsonrpc":"2.0","method":"proxy.get","params":{"output":["name","operating_mode","lastaccess","version","compatibility"]},"id":1}' \
  | jq '.result[] | {name, operating_mode, version, compatibility, lastaccess: (.lastaccess|tonumber|todate)}'

Данные реально собираются

Последний слой. Открой Мониторинг → Последние данные, отфильтруй по хосту за прокси. Значения должны обновляться по своим интервалам. Если всё серое, загляни в Администрирование → Очередь: там видно, сколько элементов задерживается и на каком прокси.

Для глубокой диагностики у прокси есть встроенная команда, которая пишет в лог состояние кэшей и препроцессинга:

# На прокси zbx-proxy-01: диагностика кэша истории и препроцессинга в лог
sudo zabbix_proxy -R diaginfo
sudo tail -n 40 /var/log/zabbix/zabbix_proxy.log

Осложнения: ошибки Zabbix proxy и как их лечить

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

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart TD
    A["Прокси серый в интерфейсе"] --> B{"Служба запущена?"}
    B -->|нет| C["Проверь конфиг ключом -T"]
    B -->|да| D{"Порт сервера доступен?"}
    D -->|нет| E["Чини firewall или NAT"]
    D -->|да| F{"Имя совпадает?"}
    F -->|нет| G["Исправь Hostname"]
    F -->|да| H{"PSK совпадает?"}
    H -->|нет| I["Сверь identity и ключ"]
    H -->|да| J["Сверь версии прокси и сервера"]
    style A fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#9a3412
    style B fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style D fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style F fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style H fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style C fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style E fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style G fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style I fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style J fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d

zabbix proxy 7 invalid option: что это и как лечить

Это сообщение пугает, потому что выглядит как сбой самого Zabbix. По факту под этой фразой в поиске прячутся три разные проблемы. Разберём каждую.

Вариант 1. Неверный ключ командной строки

Сообщение вида invalid option — ‘x’ выдаёт не Zabbix, а стандартный разборщик аргументов. Он говорит: «ты передал ключ, которого у этого бинарника нет». Типичные случаи: старый скрипт или systemd-юнит вызывает прокси с ключом от другой версии, опечатка в регистре вроде -r вместо -R, или запуск -T на старой сборке, где такого ключа ещё нет.

# На прокси zbx-proxy-01: какие ключи понимает установленная версия
zabbix_proxy -h

# Там же: как служба запускает прокси, включая переопределения
systemctl cat zabbix-proxy
ls /etc/systemd/system/zabbix-proxy.service.d/ 2>/dev/null

Если в ExecStart или в drop-in файле есть ключ, которого нет в выводе zabbix_proxy -h, убери его. В 7.x поддерживаются -c, -f, -R, -T, -h и -V. Всё остальное вызывает ошибку.

# На прокси zbx-proxy-01: после правки юнита перечитать systemd и перезапустить
sudo systemctl daemon-reload
sudo systemctl restart zabbix-proxy

Вариант 2. Неверная опция рантайм-управления

Ключ -R принимает строго определённый набор команд: config_cache_reload, diaginfo, snmp_cache_reload, housekeeper_execute, log_level_increase, log_level_decrease и ещё несколько. Опечатка в названии, например config_reload вместо config_cache_reload, даёт отказ с сообщением о неверной опции рантайм-управления.

# На прокси zbx-proxy-01: правильные команды рантайм-управления
sudo zabbix_proxy -R config_cache_reload
sudo zabbix_proxy -R log_level_increase=poller
sudo zabbix_proxy -R log_level_decrease=poller

Полный список для своей версии смотри в выводе zabbix_proxy -h или в разделе о процессе прокси в документации.

Вариант 3. Неизвестный или неверный параметр в конфиге

Самый частый случай после обновления. Zabbix proxy принципиально не запускается, если в конфиге есть строка не в формате параметр=значение или параметр, которого эта версия не знает. Так задумано ещё со времён 1.8: лучше упасть при старте, чем молча работать не так, как ты думаешь.

Откуда берутся неизвестные параметры. Конфиг скопирован с прокси другой версии. При обновлении пакетный менеджер оставил твой старый файл, а новый положил рядом как .dpkg-dist или .rpmnew. Кто-то вписал параметр сервера в конфиг прокси: например, StartAlerters или параметры веб-сервиса отчётов прокси не нужны.

# На прокси zbx-proxy-01: копия конфига перед правкой
sudo cp -a /etc/zabbix/zabbix_proxy.conf /etc/zabbix/zabbix_proxy.conf.bak.$(date +%F)

Дальше находим все параметры, которых нет в штатном конфиге текущей версии. Если пакетный менеджер оставил новый файл рядом, используем его. Если нет, достаём штатный конфиг прямо из пакета, не устанавливая его заново.

# На прокси zbx-proxy-01 (Ubuntu/Debian): достать штатный конфиг текущей версии из пакета
cd /tmp
apt-get download zabbix-proxy-sqlite3
dpkg-deb --fsys-tarfile zabbix-proxy-sqlite3_*.deb | tar -xO ./etc/zabbix/zabbix_proxy.conf > /tmp/zabbix_proxy.conf.default

# Там же: список параметров, которые знает эта версия
grep -oP '^### Option: \K\S+' /tmp/zabbix_proxy.conf.default | sort -u > /tmp/known.txt

# Там же: параметры, которые реально заданы в рабочем конфиге
grep -oP '^\s*\K[A-Za-z0-9]+(?==)' /etc/zabbix/zabbix_proxy.conf | sort -u > /tmp/used.txt

# Там же: параметры, которых эта версия не знает
comm -13 /tmp/known.txt /tmp/used.txt

Последняя команда выводит ровно те параметры, из-за которых прокси отказывается стартовать. Пусто — значит неизвестных параметров нет и проблема в значениях. На RHEL новый штатный файл обычно лежит рядом как zabbix_proxy.conf.rpmnew, подставь его вместо /tmp/zabbix_proxy.conf.default.

Если неизвестных параметров нет, а прокси всё равно не стартует, смотри на значения. Самые частые ловушки в 7.0 собраны в таблице.

# На прокси zbx-proxy-01: после правок проверить и запустить
sudo -u zabbix zabbix_proxy -T -c /etc/zabbix/zabbix_proxy.conf && sudo systemctl restart zabbix-proxy
sudo journalctl -u zabbix-proxy -n 20 --no-pager

Ошибка «proxy not found» в логе сервера

Причина: сервер получил подключение от прокси, но в интерфейсе нет прокси с таким именем. Почти всегда это расхождение Hostname и имени в интерфейсе. Реже прокси создан, но с режимом «Пассивный».

# На сервере zbx-server: какое имя присылает прокси
sudo grep -i 'not found' /var/log/zabbix/zabbix_server.log | tail -n 5

# На прокси zbx-proxy-01: какое имя прописано в конфиге
grep -E '^Hostname=' /etc/zabbix/zabbix_proxy.conf

Сравни имя из лога сервера с именем в Администрирование → Прокси. Исправь в одном из мест так, чтобы совпадало полностью. Если правил конфиг, перезапусти прокси. Если правил интерфейс, ничего перезапускать не нужно, следующий запрос прокси пройдёт.

Ошибка «cannot connect to [[адрес]:10051]»

Причина: прокси не может установить TCP-соединение с сервером. Connection refused значит, что на той стороне порт закрыт или сервер не слушает. Timed out значит, что пакеты теряются по дороге, обычно на firewall.

# На прокси zbx-proxy-01: доходят ли пакеты до сервера
nc -zv 10.10.0.10 10051
tracepath -n 10.10.0.10

# На сервере zbx-server: слушает ли сервер 10051 и что говорит firewall
sudo ss -tlnp | grep 10051
sudo ufw status | grep 10051

Если на сервере есть правило с конкретным адресом источника, убедись, что это адрес, с которого прокси реально выходит. Для прокси за NAT это внешний адрес роутера филиала, а не 192.168.50.20. Подсмотреть его можно в tcpdump на сервере.

# На сервере zbx-server: с какого адреса приходят попытки подключения к 10051
sudo tcpdump -ni any tcp port 10051 and 'tcp[tcpflags] & tcp-syn != 0' -c 10

Ошибки шифрования PSK

Причина: сервер и прокси не договорились о TLS. Варианты: в интерфейсе включён PSK, а в конфиге прокси нет, или наоборот. Identity отличается на один символ. Ключ скопирован с пробелом или переносом строки. Ключ короче 32 байт.

# На прокси zbx-proxy-01: сверить TLS-параметры и ключ
grep -E '^TLS' /etc/zabbix/zabbix_proxy.conf
sudo wc -c /etc/zabbix/zabbix_proxy.psk
sudo cat /etc/zabbix/zabbix_proxy.psk

# На сервере zbx-server: ошибки TLS по этому прокси
sudo grep -iE 'tls|psk' /var/log/zabbix/zabbix_server.log | tail -n 10

Файл ключа на 64 символа плюс перевод строки даёт 65 байт в wc -c, это нормально. Identity в конфиге и в интерфейсе сравни глазами по символам, лучше скопируй из одного места в другое. После исправления перезапусти прокси.

Версия прокси устарела

Причина: сервер обновили, прокси забыли. Сервер 7.0 принимает данные от прокси предыдущей мажорной ветки в ограниченном режиме: сбор данных и удалённые команды работают, но конфигурация прокси не обновляется, а интерфейс показывает предупреждение об устаревшей версии. Прокси ещё старше не поддерживаются совсем. Таблица совместимости есть в разделе Version compatibility документации.

# На сервере zbx-server и на прокси zbx-proxy-01: сравнить версии
zabbix_server -V | head -n 1
zabbix_proxy -V | head -n 1

Решение: обнови прокси до ветки сервера по инструкции из раздела «Обновление» ниже.

Нет прав на базу SQLite

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

# На прокси zbx-proxy-01: вернуть права на каталог и файл базы
sudo chown -R zabbix:zabbix /var/lib/zabbix
sudo chmod 750 /var/lib/zabbix
sudo systemctl restart zabbix-proxy

Растёт очередь, данные опаздывают

Причина: сборщиков не хватает. Прокси работает, но физически не успевает опросить все элементы за интервал. Признак: в Администрирование → Очередь растут задержки по этому прокси, а в шаблоне здоровья прокси загрузка сборщиков держится выше 75%.

# На прокси zbx-proxy-01: временно поднять детализацию логов поллеров для разбора
sudo zabbix_proxy -R log_level_increase=poller
sudo tail -f /var/log/zabbix/zabbix_proxy.log

Увеличивай нужный тип сборщиков постепенно: StartPollers для агентов и SNMP, StartPingers для ICMP, StartHTTPPollers для веб-проверок. Каждое увеличение — это память и соединения. Не надо ставить StartPollers=200 «на всякий случай». Прокси с сотней простаивающих поллеров — это как грузовик для доставки одного письма.

Не забудь вернуть уровень логов назад, иначе лог распухнет за пару часов:

# На прокси zbx-proxy-01: вернуть обычный уровень логов поллеров
sudo zabbix_proxy -R log_level_decrease=poller

Часы прокси убежали

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

# На прокси zbx-proxy-01 и на сервере zbx-server: сравнить время и статус синхронизации
date -u
timedatectl show -p NTPSynchronized

Если NTPSynchronized=no, включи chrony из шага подготовки и проверь, что UDP 123 до NTP-сервера не режется.

Альтернативы Zabbix proxy: когда он не нужен

Прокси — не обязательный компонент. Иногда его ставят по привычке туда, где он только добавляет точку отказа. Вот варианты и мои критерии выбора.

Прокси в Docker поднимается одной командой. Официальные образы лежат на Docker Hub zabbix/zabbix-proxy-sqlite3, тег выбирай под ветку сервера.

# На Docker-хосте филиала: прокси 7.0 на SQLite в контейнере
docker run -d --name zabbix-proxy \
  --restart unless-stopped \
  -p 10051:10051 \
  -e ZBX_HOSTNAME=zbx-proxy-01 \
  -e ZBX_SERVER_HOST=10.10.0.10 \
  -e ZBX_PROXYMODE=0 \
  -v zbx-proxy-data:/var/lib/zabbix \
  zabbix/zabbix-proxy-sqlite3:alpine-7.0-latest

docker logs -f zabbix-proxy

Почему в основном рецепте пакеты, а не Docker. Прокси — инфраструктурный компонент, который должен подниматься первым и падать последним. Пакет в systemd проще диагностировать в 3 ночи: один процесс, один лог, никаких сетевых мостов. Docker хорош, когда на площадке уже есть отлаженный Docker-хост и команда, которая его понимает.

Агенты напрямую через VPN я выбираю для мелких площадок на 10-20 машин без сетевого оборудования. Как только появляется SNMP, свитчи и принтеры, проще поставить прокси: SNMP-трафик через VPN по сотне устройств — это и нагрузка, и таймауты.

Профилактика: мониторинг, бэкап, безопасность и обновление прокси

Прокси, который никто не мониторит, однажды тихо умрёт. И узнаешь ты об этом не от Zabbix, а от бухгалтерии филиала, у которой упал принтер, а алерт не пришёл. Мониторинг мониторинга — это не паранойя, а гигиена.

Мониторинг самого прокси

Здесь два уровня. Внутреннее здоровье прокси: загрузка сборщиков, кэши, буфер. И внешний взгляд сервера: когда прокси последний раз выходил на связь.

Для внутреннего здоровья создай в интерфейсе хост с именем, например, zbx-proxy-01-health, назначь ему мониторинг через этот же прокси и привяжи шаблон «Zabbix proxy health». Шаблон собирает внутренние метрики процесса прокси: загрузку каждого типа сборщиков, заполнение кэшей, размер очереди.

Для внешнего взгляда на сервере используй внутренний элемент данных о последнем контакте прокси. Добавь его на хост самого сервера и повесь триггер.

Элемент данных на хосте Zabbix server
Тип: Zabbix внутренний
Ключ: zabbix[proxy,zbx-proxy-01,lastaccess]
Интервал: 1m

Триггер
Имя: Прокси zbx-proxy-01 не выходит на связь больше 5 минут
Выражение: now()-last(/Zabbix server/zabbix[proxy,zbx-proxy-01,lastaccess])>300
Важность: Высокая

Плюс агент на самой машине прокси с базовым шаблоном Linux: место на диске и память. Буфер SQLite при долгом обрыве связи легко съедает гигабайты, и прокси упадёт по нехватке места именно тогда, когда он нужнее всего.

Резервное копирование

Хорошая новость: прокси почти stateless. Конфигурацию хостов он получает с сервера, поэтому базу прокси бэкапить не обязательно. Это буфер, а не хранилище. Плохая новость: всё, что ты написал руками, существует только на этой машине.

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

# На прокси zbx-proxy-01: скрипт ежедневного бэкапа конфигурации
sudo tee /usr/local/sbin/zbx-proxy-backup.sh > /dev/null <<'EOF'
#!/bin/bash
set -euo pipefail
BACKUP_DIR=/var/backups/zabbix-proxy
STAMP=$(date +%F)
mkdir -p "$BACKUP_DIR"
tar -czf "$BACKUP_DIR/zbx-proxy-$(hostname -s)-$STAMP.tar.gz" \
  /etc/zabbix/zabbix_proxy.conf \
  /etc/zabbix/zabbix_proxy.psk \
  /usr/lib/zabbix/externalscripts \
  /etc/systemd/system/zabbix-proxy.service.d 2>/dev/null || true
find "$BACKUP_DIR" -name 'zbx-proxy-*.tar.gz' -mtime +30 -delete
EOF
sudo chmod 750 /usr/local/sbin/zbx-proxy-backup.sh
sudo /usr/local/sbin/zbx-proxy-backup.sh
ls -lh /var/backups/zabbix-proxy/

# На прокси zbx-proxy-01: запуск бэкапа каждый день в 02:30 через cron
echo '30 2 * * * root /usr/local/sbin/zbx-proxy-backup.sh' | sudo tee /etc/cron.d/zbx-proxy-backup

Копию за пределы площадки забирай с центральной стороны, чтобы прокси не хранил учётных данных для доступа к хранилищу:

# На сервере резервных копий или zbx-server: забрать архивы с прокси
rsync -az backup@192.168.50.20:/var/backups/zabbix-proxy/ /srv/backups/zbx-proxy-01/

Восстановление занимает минут десять. На новой машине ставишь пакет той же версии по шагам 1-3, разворачиваешь архив поверх, проверяешь конфиг и запускаешь. Имя и PSK те же, поэтому сервер узнаёт прокси и сам отдаёт ему конфигурацию хостов.

# На новой машине прокси: восстановить конфигурацию из архива и запустить
sudo tar -xzf zbx-proxy-zbx-proxy-01-2026-10-20.tar.gz -C /
sudo chown zabbix:zabbix /etc/zabbix/zabbix_proxy.psk
sudo -u zabbix zabbix_proxy -T -c /etc/zabbix/zabbix_proxy.conf
sudo systemctl enable --now zabbix-proxy

Автозапуск и автоперезапуск

systemctl enable из шага 6 уже включил автозапуск. Добавлю страховку: если прокси упадёт, systemd поднимет его через 10 секунд. Делается через drop-in, штатный юнит пакета не трогаем, иначе следующее обновление перезапишет правки.

# На прокси zbx-proxy-01: автоперезапуск при падении через drop-in
sudo mkdir -p /etc/systemd/system/zabbix-proxy.service.d
sudo tee /etc/systemd/system/zabbix-proxy.service.d/restart.conf > /dev/null <<'EOF'
[Service]
Restart=on-failure
RestartSec=10s
EOF
sudo systemctl daemon-reload
systemctl show zabbix-proxy -p Restart -p RestartUSec

Учти: если прокси падает из-за ошибки конфига, перезапуск не поможет, он просто будет падать каждые 10 секунд. Поэтому триггер на lastaccess из блока мониторинга обязателен.

Безопасность прокси

Прокси знает, что и как мониторится в твоей сети, и часто стоит на границе сегментов. Это лакомая цель. Минимальный набор защиты:

• UFW или firewalld с правилами только для нужных адресов: шаг 6.
• PSK-шифрование между прокси и сервером: шаг 8.
• Поле «Адрес прокси» в интерфейсе, чтобы сервер принимал прокси только с известного адреса.
• Отдельный пользователь базы с правами только на свою базу, если используешь PostgreSQL или MySQL.
• fail2ban для SSH.
• Закрытый вход по паролю и root-логин по SSH.
• Права 640 на конфиг и ключ PSK.

fail2ban и SSH hardening ставятся за пять минут. fail2ban сам находит неудачные попытки входа в журнале и банит источники.

# На прокси zbx-proxy-01: fail2ban с защитой SSH
sudo apt install -y fail2ban
sudo tee /etc/fail2ban/jail.d/sshd.local > /dev/null <<'EOF'
[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
EOF
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

# На прокси zbx-proxy-01: SSH hardening через отдельный файл
sudo tee /etc/ssh/sshd_config.d/10-hardening.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
MaxAuthTries 3
EOF
sudo sshd -t && sudo systemctl reload ssh

На RHEL служба называется sshd, а не ssh, поправь последнюю команду.

Обновление Zabbix proxy без сюрпризов

Главное правило порядка: сначала сервер, потом прокси. Сервер новой ветки умеет работать с прокси прошлой ветки в ограниченном режиме, обратное не работает. Значит, после обновления сервера у тебя есть время обновить прокси по одному, без аврала.

Перед обновлением проверь три вещи. Прочитай upgrade notes целевой версии, там перечислены удалённые и переименованные параметры. Сделай бэкап конфига. Убедись, что связь с сервером стабильна, иначе буфер не успеет выгрузиться.

Минорное обновление, например 7.0.20 до 7.0.25, безопасно и делается одной командой. Схема базы прокси в пределах ветки совместима.

# На прокси zbx-proxy-01: минорное обновление в пределах ветки
sudo /usr/local/sbin/zbx-proxy-backup.sh
sudo apt update
sudo apt install --only-upgrade zabbix-proxy-sqlite3
zabbix_proxy -V | head -n 1
sudo systemctl status zabbix-proxy --no-pager

Мажорное обновление, например 6.4 до 7.0, требует смены репозитория. Для SQLite самый чистый путь — удалить старый файл базы: прокси создаст новую схему и заберёт конфигурацию с сервера. Ты потеряешь только то, что лежало в буфере и не ушло на сервер, поэтому дождись пустой очереди отправки перед остановкой.

# На прокси zbx-proxy-01: мажорное обновление 6.4 до 7.0, Ubuntu 22.04
sudo /usr/local/sbin/zbx-proxy-backup.sh
sudo systemctl stop zabbix-proxy
cd /tmp
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.0+ubuntu22.04_all.deb
sudo dpkg -i zabbix-release_latest_7.0+ubuntu22.04_all.deb
sudo apt update
sudo apt install -y zabbix-proxy-sqlite3
sudo mv /var/lib/zabbix/zabbix_proxy.db /var/lib/zabbix/zabbix_proxy.db.old-6.4
ls /etc/zabbix/ | grep -E 'dpkg-dist|dpkg-old'
sudo -u zabbix zabbix_proxy -T -c /etc/zabbix/zabbix_proxy.conf
sudo systemctl start zabbix-proxy

Если ls показал zabbix_proxy.conf.dpkg-dist, это новый штатный конфиг. Прогони через него проверку неизвестных параметров из раздела про invalid option до запуска. Для прокси на PostgreSQL или MySQL базу не удаляй: прокси при старте сам обновит её схему, но бэкап базы перед этим обязателен.

Откат. Минорную версию откатить просто: поставить конкретную версию пакета и вернуть конфиг. Список доступных версий покажет apt-cache.

# На прокси zbx-proxy-01: откат на предыдущую минорную версию
apt-cache policy zabbix-proxy-sqlite3
sudo apt install --allow-downgrades zabbix-proxy-sqlite3=ВЕРСИЯ_ИЗ_СПИСКА
sudo apt-mark hold zabbix-proxy-sqlite3
sudo systemctl restart zabbix-proxy

Мажорный откат прокси имеет смысл только вместе с откатом сервера, поэтому сервер всегда обновляй со снимком виртуалки и бэкапом базы. apt-mark hold не забудь снять, когда проблема решится: sudo apt-mark unhold zabbix-proxy-sqlite3. Иначе через год обнаружишь прокси, застрявший на версии с известной уязвимостью. Рождённый в legacy рефакторинга не боится, но обновлений ему всё равно хочется.

FAQ: частые вопросы про Zabbix proxy

Почему Zabbix proxy не работает после настройки?

В девяти случаях из десяти виноваты три вещи: Hostname в конфиге не совпадает с именем прокси в интерфейсе, режим в конфиге не совпадает с режимом в интерфейсе, или закрыт порт 10051. Проверь лог прокси и лог сервера: там будет либо cannot connect, либо not found. Пройди по схеме диагностики из раздела «Осложнения» сверху вниз.

Как проверить, что Zabbix proxy работает правильно?

Смотри на четыре признака. Служба active и слушает 10051. В интерфейсе «Последний раз видели» обновляется каждые несколько секунд. В базе прокси есть хосты и элементы. В «Последних данных» хосты за прокси получают свежие значения. Для автоматической проверки используй API-запрос proxy.get с полями lastaccess и compatibility.

Что делать, если zabbix proxy 7 пишет invalid option?

Определи, откуда ошибка. Если она появляется при запуске бинарника, служба передаёт ключ, которого эта версия не знает: сверь systemctl cat zabbix-proxy с выводом zabbix_proxy -h. Если прокси не стартует из-за параметра конфига, найди неизвестные параметры сравнением со штатным конфигом и проверь файл ключом -T. Команды для обоих случаев есть в разделе «Осложнения».

Чем активный прокси отличается от пассивного?

Направлением соединения. Активный прокси сам подключается к серверу, забирает конфигурацию и отправляет данные, поэтому работает из-за NAT без проброса портов. Пассивный ждёт подключения от сервера, ему нужен входящий порт и сборщики StartProxyPollers на сервере. Активный выбирай по умолчанию, пассивный только по требованию политики безопасности.

Можно ли использовать прокси 6.4 с сервером 7.0?

Временно и с ограничениями. Сервер 7.0 работает с прокси предыдущей ветки в режиме «устаревшая версия»: данные собираются, удалённые команды выполняются, но изменения конфигурации на прокси не доходят. Это режим для плавного обновления, а не для постоянной работы. Обнови прокси до 7.0 в ближайшее окно.

Какую базу выбрать для Zabbix proxy: SQLite или PostgreSQL?

SQLite для большинства филиалов: ноль администрирования, один файл, прокси сам создаёт схему. PostgreSQL или MySQL нужны, когда прокси обрабатывает тысячи значений в секунду или буфер при обрывах связи вырастает до гигабайтов. Начни с SQLite и переходи, когда метрики здоровья прокси покажут упор в диск.

Нужно ли бэкапить базу Zabbix proxy?

Обычно нет. База прокси — это буфер и копия конфигурации, которую сервер отдаст заново. Бэкапь конфиг, ключ PSK, внешние скрипты и переопределения systemd. Этого достаточно, чтобы поднять прокси на новой машине за десять минут.

Сколько хостов выдержит один Zabbix proxy?

Зависит не от числа хостов, а от числа значений в секунду и типов проверок. Прокси на 2 vCPU и SQLite спокойно обслуживает сотни хостов с типовыми шаблонами. Ориентируйся на шаблон «Zabbix proxy health»: если загрузка сборщиков стабильно выше 75%, добавляй сборщики, если упираешься в CPU или диск, ставь второй прокси и объединяй их в группу.

Прогноз: что теперь работает

Мы подняли активный Zabbix proxy 7.0 на минималистичном конфиге, где каждая строка понятна. Связь с сервером идёт через один исходящий порт и зашифрована PSK. Хосты филиала опрашиваются локально, данные буферизуются в гибридном буфере и не теряются при обрыве канала. Ошибки invalid option и unknown parameter теперь находятся тремя командами, а не методом тыка.

Дальше прокси живёт сам: systemd поднимает его при падении, триггер на lastaccess сообщит, если он пропадёт со связи, бэкап конфигурации каждую ночь уезжает за пределы площадки, а план обновления описан заранее. Следующий логичный шаг для критичных площадок — второй прокси и группа прокси 7.0, тогда филиал переживёт смерть одной машины без твоего участия в 3 ночи.