Zabbix для малого офиса: как мы настраиваем мониторинг без админа
За годы обслуживания небольших юрлиц — бухгалтерий, юрфирм, торговых компаний, производств и медклиник на 15-50 рабочих мест — я вывел простое правило: если о падении сервера вам первым сообщил бухгалтер, а не система мониторинга, значит мониторинга у вас нет. В этой статье — наша реальная методология развёртывания Zabbix 7.0 LTS для клиентов без штатного администратора: с конкретными ключами, шаблонами, триггерами и командами, которые мы используем в каждой инсталляции.
Зачем малому офису промышленный мониторинг, а не обзвон по симптомам
У наших клиентов один и тот же профиль инфраструктуры: 1-2 сервера (файловый плюс сервер 1С или терминалка), 15-40 рабочих станций, коммутатор, UPS, иногда MS SQL под учётной системой. И у девяти из десяти — ни одного штатного администратора, который бы каждое утро проверял свободное место на диске или статус вчерашнего бэкапа.
На практике это выливается в один и тот же сценарий: сервер 1С «висит», потому что диск C: заполнился логами технологического журнала до 2% свободного места, и об этом узнают в девять утра, когда бухгалтерия не может провести накладные закрытия месяца. Или задание резервного копирования на внешний диск молча остановилось три недели назад из-за смены пароля учётной записи — и это вскрывается только в момент, когда бэкап реально нужен для восстановления. Или на UPS давно села батарея, и первое же отключение электричества роняет сервер жёстко, с риском повреждения базы 1С.
Zabbix закрывает именно этот класс проблем — не «красивые графики для отчёта», а автоматическое обнаружение деградации раньше, чем её заметит пользователь. Мы разворачиваем его как часть абонентского обслуживания: один раз настроенный сервер мониторинга обслуживает всю инфраструктуру клиента без необходимости держать штатного админа — реагируем на алерты мы, а систему можно частично администрировать силами толкового офис-менеджера.
Что именно мы мониторим: объекты, ключи и пороги
Дальше — не абстрактный список «что можно мониторить в Zabbix», а конкретный набор объектов, ключей и шаблонов, которые мы включаем в каждую инсталляцию для малого офиса на Windows. Часть ключей — из официальных шаблонов Zabbix (Windows by Zabbix agent, MSSQL by Zabbix agent 2), часть — собственные UserParameter-скрипты для специфики 1С и SMART, где готового официального шаблона под задачу нет.
| Объект | Ключ / шаблон | Как собирается | Типовой порог |
|---|---|---|---|
| Диск сервера/РС | vfs.fs.size[C:,pfree], шаблон Windows by Zabbix agent, LLD vfs.fs.discovery | agent2, автообнаружение всех разделов | <10% Warning, <5% High |
| Загрузка CPU | system.cpu.util[,,avg1] | agent2 | среднее за 10 мин >90% Warning |
| Оперативная память | vm.memory.size[pavailable] | agent2 | <15% свободной Average |
| Служба RDP / сервер 1С | net.tcp.service[tcp,,3389], net.tcp.service[tcp,,1541] | agent2, проверка TCP-порта | =0 три минуты подряд — High |
| Процессы кластера 1С | proc.num[ragent.exe], proc.num[rphost.exe] | agent2 | =0 Disaster |
| Сеансы кластера 1С | свой UserParameter поверх rac.exe (RAC/RAS) | скрипт → JSON → LLD по инфобазам | используемые/лимит >90% Warning |
| Доступность MS SQL | mssql.ping (плагин MSSQL agent2) | agent2, встроенный плагин | =0 Disaster |
| Блокировки/базы MS SQL | LLD mssql.db.discovery, счётчики плагина | agent2 plugin | рост длительности блокировок Average |
| SMART-статус дисков | свой UserParameter поверх smartctl -a | скрипт → JSON LLD по физическим дискам | Reallocated_Sector_Ct >0 High |
| Возраст файла бэкапа | vfs.file.time[путь,modify] | agent2 | старше 26 часов Average |
| UPS: батарея, сеть | SNMP, OID из UPS-MIB (upsBatteryCharge, upsInputLineFailCause) | SNMP-опрос сервером/proxy | заряд <50% Warning, работа от батареи High |
| Порты коммутатора | SNMP LLD net.if.discovery + ifOperStatus | SNMP | критичный (uplink) порт down — Disaster |
Архитектура нашей типовой инсталляции
Сервер мониторинга — Zabbix Server 7.0 LTS на Ubuntu 24.04 LTS, обычно виртуалка 2 vCPU / 4 GB RAM / 40 GB диска — этого достаточно вплоть до 40-50 хостов малого офиса. Бэкенд — PostgreSQL 16 (Zabbix 7.0 требует PostgreSQL 13 и новее). Для клиентов, где хотим хранить тренды дольше стандартного года на ограниченном диске VPS, разворачиваем поверх TimescaleDB 2.13+ — она делает автоматическое партиционирование и сжатие истории; для инфраструктуры до 20-30 хостов это опция, а не необходимость. Frontend — nginx + php-fpm (PHP 8.0-8.3).
Ключевое архитектурное решение для малого офиса за NAT — Zabbix agent2 работает в активном режиме: агент сам инициирует соединение к серверу мониторинга по TCP 10051, а не сервер стучится к агенту по 10050. Это значит, что на pfSense или Keenetic клиента не нужно пробивать ни одного входящего порта — агент просто ходит наружу, как любой обычный клиент.
Zabbix proxy добавляем только в двух случаях: когда сеть клиента разбита на изолированные VLAN без прямого маршрута к серверу мониторинга, либо когда у клиента две площадки, соединённые медленным VPN-каналом — тогда proxy стоит на удалённой площадке и буферизует данные локально, не гоняя каждый item через узкий канал. SNMP-опрос UPS и коммутаторов делает сам сервер (или proxy) — это pull-модель, agent2 там не участвует.
Для нескольких клиентов на одном сервере мониторинга разграничение делаем через отдельные Host groups + User groups с ограничением permissions — так менеджер клиента А физически не видит хосты клиента Б, даже если сервер общий.
Тюнинг PostgreSQL и Zabbix Server под 200 хостов
Когда мы выходим за рамки 20–30 хостов и начинаем мониторить 200+ объектов, стандартных параметров Zabbix Server уже не хватает. Вот минимальный набор правок, который мы вносим в конфигурацию на виртуалке с 8 ГБ ОЗУ.
В /etc/postgresql/16/main/postgresql.conf обязательно включаем TimescaleDB и выделяем память:
shared_preload_libraries = 'timescaledb'
shared_buffers = 2GB
effective_cache_size = 5GB
work_mem = 32MB
maintenance_work_mem = 512MB
wal_buffers = 16MB
max_wal_size = 2GB
checkpoint_completion_target = 0.9
random_page_cost = 1.1
max_connections = 100В /etc/zabbix/zabbix_server.conf увеличиваем пулы обработчиков и кеши:
StartPollers=20
StartPreprocessors=10
StartTrappers=5
StartPingers=5
StartDiscoverers=3
StartHTTPPollers=3
StartDBSyncers=4
StartAlerters=3
CacheSize=256M
HistoryCacheSize=128M
HistoryIndexCacheSize=64M
TrendCacheSize=64M
ValueCacheSize=128M
Timeout=15
HousekeepingFrequency=1
MaxHousekeeperDelete=10000Тюнинг производительности Zabbix Server для малых инсталляций
Даже для 20–50 хостов стоит сразу задать параметры производительности в /etc/zabbix/zabbix_server.conf — дефолтные значения рассчитаны на более крупные инсталляции и не всегда оптимальны для небольшой виртуалки:
StartPollers=10
StartPingers=5
CacheSize=256M
HistoryCacheSize=64M
ValueCacheSize=128MДля 100 хостов со стандартными шаблонами ориентируйтесь на 4 vCPU / 8 GB RAM / 100 GB SSD под базу. При 1000+ NVPS (new values per second) увеличьте CacheSize до 512M и HistoryCacheSize до 128M. Housekeeper держим на 30 дней для history и 365 для trends — больше хранить для малого офиса смысла нет, только место занимает.
Пошаговая установка: Zabbix Server 7.0 LTS + Agent2 на Windows
Порядок ниже — ровно то, что мы прогоняем на новом сервере клиента, шаг за шагом.
1. Репозиторий и пакеты сервера (Ubuntu 24.04)
wget https://repo.zabbix.com/zabbix/7.0/release/ubuntu/pool/main/z/zabbix-release/zabbix-release_7.0-2+ubuntu24.04_all.deb
dpkg -i zabbix-release_7.0-2+ubuntu24.04_all.deb
apt update
apt install -y zabbix-server-pgsql zabbix-frontend-php php8.3-pgsql \
zabbix-nginx-conf zabbix-sql-scripts zabbix-agent2 postgresql2. База данных
sudo -u postgres createuser --pwprompt zabbix
sudo -u postgres createdb -O zabbix zabbix
zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | sudo -u zabbix psql zabbixПароль прописываем в /etc/zabbix/zabbix_server.conf параметром DBPassword=, затем поднимаем сервисы:
systemctl restart zabbix-server zabbix-agent2 nginx php8.3-fpm
systemctl enable zabbix-server zabbix-agent2 nginx php8.3-fpmЕсли планируем хранить историю дольше стандартного срока на небольшом диске VPS, TimescaleDB разворачиваем отдельным шагом сразу после базовой установки, до того как накопится история.
3. Агент на Windows-сервере/РС
Ставим тихую установку MSI без диалогов, сразу в активном режиме — так агент сам инициирует соединение к серверу мониторинга и на клиентском pfSense/Keenetic не нужно открывать входящий 10050:
msiexec /i zabbix_agent2-7.0.14-windows-amd64-openssl.msi /qn ^
SERVER=10.20.0.5 SERVERACTIVE=10.20.0.5 ^
HOSTNAME=WIN-BUH01-SRV LISTENPORT=10050В zabbix_agent2.conf сразу закрываем возможность удалённого выполнения команд, если она не нужна для конкретного хоста — это стандартная точка входа для атаки, если агент будет скомпрометирован:
Server=10.20.0.5
ServerActive=10.20.0.5
Hostname=WIN-BUH01-SRV
DenyKey=system.run[*]Для сервера с MS SQL дополнительно прописываем сессию плагина прямо в конфиге агента, чтобы не хранить пароль в шаблоне на сервере мониторинга:
Plugins.MSSQL.Sessions.acc.Uri=tcp://127.0.0.1:1433
Plugins.MSSQL.Sessions.acc.User=zbx_monitor
Plugins.MSSQL.Sessions.acc.Password=<пароль>После этого в веб-интерфейсе Zabbix создаём host, привязываем нужные шаблоны — дальше автообнаружение (LLD) само разложит диски, интерфейсы и базы данных по items.
Бесплатный экспресс-аудит мониторинга от ITfresh
Развернём Zabbix 7.0 LTS под вашу инфраструктуру за 1-2 дня: агенты на серверах и РС, шаблоны под 1С/MS SQL/SMART/UPS, триггеры с реальными порогами и оповещения в Telegram — без необходимости держать штатного администратора. Первичный аудит инфраструктуры и план мониторинга — бесплатно.
Шаблоны из коробки и автообнаружение (LLD): диски, базы, интерфейсы
Официальный шаблон Windows by Zabbix agent (требует agent 7.0 и новее) закрывает базовую телеметрию сервера и РС из коробки: CPU, память, диски через LLD vfs.fs.discovery (с regex-фильтром, чтобы не заводить CD-ROM и съёмные носители), сетевые интерфейсы через net.if.discovery. Это тот минимум, который мы навешиваем на каждый Windows-хост без исключений.
Для MS SQL используем официальный шаблон MSSQL by Zabbix agent 2 — плагин встроен в agent2, не требует внешних скриптов. На хосте задаются макросы {$MSSQL.URI}, {$MSSQL.USER}, {$MSSQL.PASSWORD}, дальше LLD-правило обнаруживает базы данных и заводит per-базовые items: доступность (mssql.ping), размер, page life expectancy, buffer cache hit ratio, число блокировок.
Для 1С готового официального шаблона нет — используем собственный. Через RAC (Remote Administration Client) к RAS (Remote Administration Server) кластера 1С опрашиваем список информационных баз и активных сеансов; обёртка на PowerShell превращает вывод rac.exe в JSON, который Zabbix читает как LLD-правило с макросом {#IBNAME} на каждую информационную базу. Дальше по каждой базе заводим item числа сеансов и, если лицензирование программное — числа занятых лицензий относительно лимита.
Для SMART-статуса дисков аналогично нет официального шаблона под Windows — используем smartmontools (smartctl.exe), собственный discovery-скрипт раз в час опрашивает все физические диски (\\.\PhysicalDriveN), парсит атрибуты 5 (Reallocated_Sector_Ct), 187, 197, 198 и температуру (194), отдаёт JSON для LLD-макроса {#DISKID}. Дальше единый item-прототип smart.attribute[{#DISKID},<id>] разворачивается автоматически на каждый найденный диск.
Для UPS и коммутаторов берём готовые community-шаблоны SNMP (APC UPS, generic Network Interfaces), а в LLD-правиле net.if.discovery обязательно ставим фильтр по regex на имя или alias интерфейса — иначе на 24-портовом коммутаторе получим полсотни бесполезных items по портам рабочих станций вместо двух-трёх критичных uplink-портов.
Триггеры и severity: считаем пороги, а не гадаем
Главная ошибка при настройке триггеров — использовать last() для метрик, которые естественно колеблются (CPU, сеть, число сеансов). Один случайный всплеск даёт ложное срабатывание среди ночи. Мы используем агрегирующие функции с окном (avg, count) и двухпороговую логику для гистерезиса — отдельный порог на срабатывание и отдельный, более мягкий, на закрытие проблемы.
| Триггер | Выражение (упрощённо) | Severity |
|---|---|---|
| Мало места на диске | last(/Host/vfs.fs.size[C:,pfree])<10 | Warning (<5% — Average) |
| CPU перегружен долго | avg(/Host/system.cpu.util[,,avg1],10m)>90 | Warning |
| Мало памяти | last(/Host/vm.memory.size[pavailable])<10 | Average |
| Служба 1С/RDP недоступна | max(/Host/net.tcp.service[tcp,,1541],3m)=0 | High |
| Кластер 1С не отвечает | last(/Host/proc.num[ragent.exe])=0 | Disaster |
| Лицензии 1С почти исчерпаны | last(/Host/1c.sessions.used[{#IBNAME}])/last(/Host/1c.sessions.limit[{#IBNAME}])*100>90 | Warning |
| MS SQL недоступен | last(/Host/mssql.ping)=0 | Disaster |
| SMART-деградация диска | last(/Host/smart.attribute[{#DISKID},5])>0 | High |
| Бэкап не обновлялся | (now()-last(/Host/vfs.file.time[...,modify]))>93600 | Average |
| UPS перешёл на батарею | last(/Host/upsInputLineFailCause)<>0 | High |
| Хост недоступен вообще | nodata(/Host/agent.ping,10m)=1 | High/Disaster по критичности хоста |
Для критичных хостов (сервер 1С, файловый сервер, гейт) триггер недоступности хоста делаем родительским и вешаем на него trigger dependency для всех прочих триггеров того же хоста — если сервер целиком лёг, не нужно 15 отдельных алертов про недоступность каждой службы на нём, достаточно одного.
Оповещения в Telegram без спама: эскалации, maintenance, dependencies
Media type — встроенный вебхук Telegram: бот-токен плюс {ALERT.SENDTO} как chat_id, формат сообщения Markdown. Одного бота на клиента достаточно, разные проблемные теги роутим в разные топики или чаты через Problem tags (component:1c, component:backup, component:network) — так системный вопрос по 1С не тонет в потоке алертов про свитч.
Эскалации настраиваем ступенчато: шаг 1 (сразу) — дежурный чат ITfresh; если проблема не подтверждена и не закрыта через 20 минут — шаг 2, уведомление ответственному менеджеру со стороны клиента; для Disaster-severity (сервер 1С, MS SQL, бэкап) время до эскалации короче, для Warning — длиннее или вообще без эскалации в рабочее время.
Maintenance-периоды обязательны, иначе плановые работы (перезагрузка после патчей, обновление 1С) генерируют лавину ложных Disaster. Создаём объект Maintenance на конкретный хост/группу с окном (например, «Патч-вторник» 02:00-04:00), в этом окне проблемы либо не создаются, либо создаются, но не триггерят действия — это настраивается флагом «Data collection» в объекте.
Dependencies — отдельный инструмент, чтобы гасить каскад. Для клиентов, где всё стоит за одним pfSense/Keenetic-шлюзом, триггер «шлюз недоступен» делаем родительским для всех триггеров хостов позади него: если упал канал или сам роутер, мы получаем одно сообщение «шлюз недоступен», а не тридцать сообщений «сервер недоступен, РС недоступен, свитч недоступен» одновременно — это тот же принцип, что мы применяем на инфраструктурах за NAT-фронтами у нескольких клиентов.
Дашборды и отчёты: живая картина для офис-менеджера
Для клиентов без штатного админа мы собираем один обзорный дашборд, который выводится на монитор в серверной или открывается офис-менеджером по ссылке: Monitoring → Dashboard → Create dashboard. Добавляем виджеты Graph (сводные графики CPU/память/диски по критичным хостам), Problem hosts (активные проблемы), System information (состояние самого Zabbix) и Map (схема сети). Период отображения — последние 24 часа, автообновление — 60 секунд.
Для регулярной отчётности перед руководством клиента используем Scheduled reports — PDF-отчёт автоматически уходит по расписанию на почту. Если нужна продвинутая визуализация — связка Grafana + Zabbix plugin (alexanderzobnin-zabbix-app) через API, но для малого офиса это опция, а не необходимость.
Подводные камни, на которых мы обожглись
- Открытый входящий 10050 через NAT. Если по старой памяти пробить порт агента наружу вместо активного режима — сканеры находят открытый Zabbix agent за минуты. Лечится переходом на active checks и явным правилом firewall «разрешить только с IP сервера мониторинга», если пассивный режим всё же нужен для части items.
- WMI/RemoteRegistry закрыты по умолчанию. На части клиентских флитов удалённый WMI и Remote Registry для инвентаризации РС закрыты фаерволом из коробки. Для мониторинга через agent2 это не проблема — агент стоит локально и не использует WMI, но если кто-то планирует докручивать инвентаризацию поверх, про это нужно помнить.
- SNMP-community «public» по умолчанию. UPS и управляемые коммутаторы почти всегда приезжают с community string
public— меняем на собственную строку сразу при заведении в мониторинг, где оборудование поддерживает — переходим на SNMPv3. - Незакрытый
system.run. Разрешённое выполнение произвольных команд с сервера мониторинга — потенциальный вектор для RCE, если скомпрометирован сам Zabbix Server. По умолчанию держимDenyKey=system.run[*]и включаем точечно только там, где реально нужен remote-restart службы. - Рассинхрон времени на клиентских Windows. Без нормальной синхронизации с PDC-эмулятором домена получаем лавину «future timestamp» в истории и ложные всплески на графиках — типовая проблема на доменах, где NTP через GPO не настроен.
- Наложение шаблонов с одинаковыми ключами. Если официальный Windows-шаблон и собственный UserParameter описывают один и тот же объект разными ключами — получаем задвоенные данные и путаницу в триггерах. Продумываем namespace ключей заранее, до раскатки на несколько клиентов.
- TimescaleDB требует отдельного шага. Просто «включить» её на существующей базе без переноса схемы истории не получится — компрессия настраивается отдельно, и без неё диск небольшого VPS ощутимо «утекает» за пару месяцев на history/trends при плотном опросе.
- Ложный Disaster на рестарте кластера 1С. При штатном перезапуске кластера 1С сеансы на пару секунд обнуляются — если триггер строится на
last()без минимального периода подтверждения, получаем ложный Disaster ночью. Добавляем условие по количеству последовательных «плохих» замеров.
Три типовых отказа: база, Telegram, PHP-FPM
За полтора года эксплуатации у клиента с 60+ хостами мы столкнулись с тремя серьёзными проблемами, и все они оказались типовыми.
- PostgreSQL разросся до 180 ГБ за 4 месяца. Причина — забыли включить TimescaleDB compression. Бэкапы базы стали занимать по 2 часа, виртуалка начала тормозить. После включения компрессии на всех hypertables база ужалась до 35 ГБ за сутки. С тех пор это первое, что мы делаем на каждом новом сервере.
- Алерты в Telegram перестали приходить ночью. В логах Zabbix — таймаут. Выяснилось, что провайдер блокировал api.telegram.org именно в окне ночных регламентных работ. Решение: подняли SOCKS5-прокси через нашу VPN-инфраструктуру и прописали его в настройках Media Type Telegram.
- Веб-интерфейс открывался по 8 секунд. Причина — PHP-FPM с дефолтными настройками:
pm.max_children = 5при четырёх одновременных пользователях плюс автоматические запросы из Grafana. Подняли доpm.max_children = 20иpm.start_servers = 5— интерфейс стал открываться за полсекунды.
Конфликт портов Apache и Nginx при установке
Zabbix по умолчанию тянет за собой Apache. Если хотите использовать Nginx — ставьте пакет zabbix-nginx-conf и удаляйте Apache, иначе оба веб-сервера будут делить 80-й порт, и фронтенд не откроется. На Ubuntu 24.04 мы сразу ставим zabbix-nginx-conf и не устанавливаем Apache вовсе — это избавляет от типовой проблемы «веб-интерфейс не грузится после установки».
Ещё один нюанс: при миграции Zabbix между серверами (например, с CentOS на Debian) конфигурацию вытаскивайте через API или XML-экспорт, а базу переносите через pg_dump/pg_restore. Схема рабочая, проверена не раз.
Стоимость внедрения и окупаемость: наши оценки
Дальше — оценки по нашей практике для типового клиента на 15-40 рабочих мест; точная цифра зависит от числа хостов, наличия MS SQL/1С-кластера и SNMP-оборудования.
| Позиция | Оценка стоимости | Периодичность |
|---|---|---|
| Разовое внедрение: сервер + до 20 хостов, базовые шаблоны, Telegram | 15 000 - 25 000 ₽ | однократно |
| Дополнительно: 1С RAC/RAS, MS SQL, SNMP UPS/свитч | +5 000 - 8 000 ₽ | однократно |
| Сопровождение мониторинга (реакция на алерты, актуализация порогов) | от 3 000 ₽/мес | в составе IT-абонемента |
| Выезд на инцидент без мониторинга (для сравнения) | 5 000 - 10 000 ₽ за выезд | по факту, обычно постфактум |
| Стоимость сорванного дня закрытия периода в 1С (простой бухгалтерии) | оценочно от 15 000 ₽ по фонду оплаты труда за день | разово, но выше годового сопровождения |
По нашей практике вложение в мониторинг окупается на первом же предотвращённом инциденте: сорванный день закрытия периода в 1С или потерянный бэкап обходятся клиенту дороже, чем годовое сопровождение системы мониторинга целиком.
Оценка простоя: формула для расчёта
Чтобы понять, нужен ли мониторинг конкретному офису, мы считаем стоимость часа простоя по простой формуле: число сотрудников × средняя зарплата за час × коэффициент 0,5 (половина людей всё равно чем-то занята, пока система лежит).
Для типичного офиса на 50 человек получается 12–15 тыс. руб./час простоя, а в напряжённые дни — во время отчётности или закрытия месяца — эта сумма доходит до 30 тыс. руб./час. Грамотно настроенный Zabbix окупается одним-единственным предотвращённым инцидентом.
Для сравнения: у клиента на 42 рабочих места мы взяли под наблюдение 131 объект — 6 Windows-серверов, 4 Linux-сервера, 2 Hyper-V хоста, 14 коммутаторов, 5 ИБП, 9 принтеров, 8 устройств СКУД и видеонаблюдения, 83 внешних HTTP/HTTPS-эндпоинта. Суммарно это около 5 700 метрик в минуту (NVPM) на одном сервере мониторинга.
Частые вопросы
- Нужен ли отдельный физический сервер под Zabbix?
Нет. Для 20-50 хостов малого офиса достаточно виртуальной машины на 2 vCPU / 4 GB RAM / 40 GB диска — разворачиваем её на существующей виртуализации клиента либо в нашем облаке.
- Обязательна ли TimescaleDB?
Нет, это опция. Она полезна, если нужно хранить тренды дольше года на ограниченном по объёму диске VPS. Без неё Zabbix 7.0 LTS отлично работает на обычном PostgreSQL 13 и новее.
- Как мониторить 1С, если нет доступа к кластеру (RAC/RAS)?
Тогда ограничиваемся косвенными метриками: процессы ragent.exe/rphost.exe, доступность TCP-порта 1541, блокировки на стороне MS SQL. Полноценный подсчёт сеансов и лицензий требует прав администратора кластера на RAS.
- Безопасно ли открывать порт агента наружу через pfSense или Keenetic?
Не рекомендуем. Используем активный режим agent2 — агент сам инициирует соединение к серверу мониторинга по 10051, входящие порты на стороне клиента открывать не нужно.
- Что если у клиента уже стоит старый Zabbix 5.0 или 6.0?
Обновляем по официальному пути миграции: снапшот базы данных, обновление пакетов, автоматические патчи схемы БД при первом запуске нового сервера. На инфраструктуре малого офиса это обычно 1-2 часа работ с коротким окном недоступности мониторинга.