Разворачиваем Zabbix 7.0 LTS за один вечер: пошаговый мануал для офиса до 50 рабочих мест

Меня зовут Евгений Семёнов, я технический директор компании «АйТи Фреш». Больше пятнадцати лет мы занимаемся IT-аутсорсингом для московских компаний до 50 рабочих мест и держим собственные серверы в дата-центре МТС. В первой статье серии я объяснял, почему мониторинг ставим почти каждому клиенту и почему из всех вариантов выбираем именно Zabbix. Сегодня — сплошная практика. Это наш внутренний регламент: как инженер «АйТи Фреш» с чистой виртуальной машины доводит новый офис до первого осмысленного алерта за один вечер, примерно за три-четыре часа. Все команды ниже рабочие, именно их мы гоняем на боевых внедрениях. Можете повторить сами шаг за шагом или отдать статью подрядчику как техническое задание.

Договоримся о рамках сразу. Мы ставим Zabbix 7.0 LTS — это ветка с долгосрочной поддержкой, самый свежий на момент написания корректирующий релиз 7.0.28 вышел в июле 2026 года. LTS означает, что ветку будут поддерживать до примерно 2029 года: полная поддержка до 2027-го, дальше ограниченная. Для клиентского продакшена это единственно верный выбор — никакого желания через полгода объяснять клиенту, почему его мониторинг просит мажорного апгрейда. Промежуточные версии вроде 7.2 или 7.4 живут по полгода и хороши для лабораторий, а не для инфраструктуры, которую сдал и забыл на два года.

Сайзинг и подготовка: какая VM нужна на офис до 50 рабочих мест

Первый вопрос, который задаёт любой заказчик: «А не потянет ли это половину сервера?» Не потянет. Zabbix на офис нашего масштаба — это скромная виртуалка, а не отдельная железка. Наша проверенная на десятках внедрений норма для площадки до 50 рабочих мест — 2 vCPU, 4 ГБ оперативной памяти и 50 ГБ SSD. Этого хватает, чтобы уверенно держать 60–80 хостов и порядка 5000 метрик с комфортным запасом: сервер, база и веб-морда живут на одной машине и не конкурируют за ресурсы.

Почему именно SSD, а не обычный диск побольше — принципиально. Zabbix — это база данных, которая непрерывно пишет историю значений и почти постоянно к ней обращается для расчёта триггеров и построения графиков. На медленном HDD внутренние процессы начинают ждать диск, копится очередь на запись, и в веб-интерфейсе появляется знаменитая жёлтая плашка «Zabbix housekeeper processes more than 75% busy». 50 гигабайт SSD с запасом закрывают год-полтора истории при нашей типовой глубине хранения, а с включённым сжатием TimescaleDB (про него ниже) — и того дольше.

Где размещать сервер мониторинга: внутри или снаружи

Второе решение важнее сайзинга, потому что определяет саму ценность мониторинга. Есть два места, где может жить виртуалка Zabbix, и у каждого своя логика.

• На гипервизоре клиента, внутри офисной сети. Плюс огромный: сервер видит абсолютно всё — рабочие станции, контроллер домена, сетевое железо по SNMP, ИБП, принтеры. Все они в одной локальной сети, ничего пробрасывать не нужно. Минус ровно один, но серьёзный: если в офисе пропадает интернет или гаснет свет, вместе с офисом «слепнет» и сам мониторинг — он-то как раз и должен был сообщить об аварии, но не может, потому что лёг вместе с ней.
• Снаружи, на нашей площадке в дата-центре МТС. Зеркальная картина: такой сервер переживает падение офиса и честно пришлёт письмо «связь с площадкой потеряна», но изнутри локальной сети он мало что видит без проброса портов или туннеля.

Идеальная схема, которую мы и разворачиваем на ответственных объектах, — оба сразу: основной сервер внутри офиса собирает всю внутреннюю телеметрию, а снаружи стоит лёгкая контрольная точка, которая следит за самим офисом и за внешними сервисами клиента (сайт, почта, VPN-шлюз). Для типового внедрения «за вечер» начинаем с внутренней виртуалки — она даёт 90% пользы сразу, а внешнюю точку добавляем на второй неделе.

Операционная система: Ubuntu 24.04 LTS и ничего лишнего

Под сервер берём Ubuntu Server 24.04 LTS — минимальная установка без графики, только SSH. Причина проста: Zabbix официально собирает пакеты под эту версию, обновления безопасности прилетают штатно много лет, а никаких десктопных компонентов серверу мониторинга не нужно. После разворачивания чистой системы первым делом обновляемся и ставим часовой пояс — это сэкономит потом полчаса разбирательств с «поехавшими» временными метками на графиках:

sudo apt update && sudo apt upgrade -y
sudo timedatectl set-timezone Europe/Moscow
sudo apt install -y chrony    # синхронизация времени обязательна
timedatectl status            # проверяем: System clock synchronized: yes

Синхронизация времени — не формальность. Zabbix постоянно сравнивает временные метки сервера и агентов; расхождение часов даёт ложные срабатывания триггеров вида «данные из будущего» и кривые графики. chrony держит время ровно, и об этой грабле можно забыть.

Установка серверной части: полный листинг команд

Теперь самая техническая часть. Если делать по этому листингу без остановок, серверная часть поднимается за 40–60 минут, из которых половину времени машина просто качает и разворачивает пакеты. Разберём по шагам.

Подключаем официальный репозиторий Zabbix 7.0 LTS

Пакеты Zabbix есть и в стандартных репозиториях Ubuntu, но там они устаревшие. Ставим из официального репозитория проекта — так мы получаем ровно ту версию, которую хотим, и обновления прямо от вендора. Скачиваем и подключаем deb-пакет репозитория, затем обновляем индекс:

wget https://repo.zabbix.com/zabbix/7.0/release/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

После этого одной командой ставим весь серверный набор: сам сервер под PostgreSQL, PHP-фронтенд, конфиг под nginx, SQL-скрипты со схемой базы и агент второго поколения, чтобы сервер сразу мониторил сам себя:

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

Обратите внимание на суффикс -pgsql у пакета сервера — он жёстко определяет, с какой базой Zabbix будет работать. Мы сознательно выбираем связку с PostgreSQL, и вот почему.

PostgreSQL 16 и TimescaleDB: почему мы ушли с MySQL

Долгие годы стандартной базой под Zabbix была MySQL, и она прекрасно работает. Но на клиентских внедрениях мы перешли на PostgreSQL по двум причинам, и обе про эксплуатацию, а не про идеологию.

Во-первых, TimescaleDB — расширение PostgreSQL для временных рядов, которое Zabbix 7.0 официально поддерживает. Оно нарезает таблицы истории и трендов на автоматические «куски» по времени и умеет прозрачно сжимать старые данные. На реальных базах это даёт кратное сокращение места под историю: то, что без сжатия заняло бы десятки гигабайт, укладывается в единицы. Для нашей виртуалки на 50 ГБ это разница между «диск живёт год» и «диск живёт три года без вмешательства».

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

sudo apt install -y postgresql postgresql-contrib
# репозиторий TimescaleDB и само расширение под установленную мажорную версию PG:
sudo apt install -y timescaledb-2-postgresql-16
sudo systemctl restart postgresql

Создаём базу, пользователя и импортируем схему

Дальше классика: отдельная база, отдельный пользователь с паролем из менеджера паролей (никаких «zabbix/zabbix» на продакшене) и импорт схемы из поставляемых SQL-скриптов. Схему разворачиваем от имени созданного пользователя:

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

Импорт занимает пару минут — это нормально, база создаёт тысячи таблиц и наполняет справочники. Сразу после этого включаем TimescaleDB на базе Zabbix, иначе история сжиматься не будет (это одна из самых частых граблей, вернёмся к ней в конце):

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" \
  | sudo -u postgres psql zabbix
# и активируем нарезку истории штатным скриптом Zabbix:
cat /usr/share/zabbix/sql-scripts/postgresql/timescaledb/schema.sql \
  | sudo -u zabbix psql zabbix

Правим zabbix_server.conf: пароль, кэши, поллеры

Сервер должен знать пароль к базе и — под наш объём — иметь чуть увеличенные кэши и число опросных процессов. Открываем /etc/zabbix/zabbix_server.conf и приводим ключевые параметры к таким значениям:

# /etc/zabbix/zabbix_server.conf — ключевые строки
DBName=zabbix
DBUser=zabbix
DBPassword=пароль-из-менеджера-паролей

# кэш конфигурации — под 60-80 хостов с запасом
CacheSize=64M

# опросные процессы: под ~5000 метрик хватает с головой
StartPollers=10
StartPreprocessors=5

# история значений в кэше перед сбросом в базу
HistoryCacheSize=32M
ValueCacheSize=64M

Значения выше — наш рабочий пресет для офиса до 50 рабочих мест, не «максимальная производительность», а «спокойно тянет с запасом и не жрёт память зря». По умолчанию Zabbix ставит поллеров меньше, и на живой инфраструктуре с активным SNMP начинается очередь опроса; десяти достаточно. После правки конфига запускаем и включаем в автозагрузку сервер, агент и веб-сервер:

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

nginx, PHP-FPM и мастер установки в браузере

Пакет zabbix-nginx-conf кладёт готовый конфиг веб-морды, нужно лишь раскомментировать в нём listen и server_name под адрес сервера и перезапустить nginx. Дальше открываем в браузере http://адрес-сервера/ и проходим мастер: он проверяет расширения PHP (все зелёные, если поставили пакеты из репозитория), спрашивает параметры подключения к базе — те же, что в конфиге, — и часовой пояс. Ставим Europe/Moscow и завершаем установку. Последний штрих — русский интерфейс: он включается не глобально, а в профиле каждого пользователя, поэтому сразу после первого входа зайдите в свой профиль и выберите русский язык. На весь этот этап — от apt install до первого экрана логина — уходит те самые 40–60 минут.

Первые 15 минут после входа: гигиена доступа

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

• Меняем пароль встроенного Admin. Профиль → сменить пароль на длинный из менеджера паролей. Это первое действие, ещё до всего остального.
• Заводим личную учётку инженера с ролью Super admin и включаем ей вход через реальную почту. Работать под общим Admin — плохая практика: в журнале аудита не видно, кто что менял.
• Отключаем встроенный Admin. Удалять его нельзя (Zabbix не даст удалить последнего суперадмина и служебную учётку), но перевести в статус «отключён» после создания своей — можно и нужно.
• Ставим часовой пояс и русский язык в своём профиле, если не сделали на мастере.
• Включаем HTTPS, если панель хоть как-то смотрит в интернет. Быстрее всего — certbot с сертификатом Let's Encrypt: sudo certbot --nginx -d zabbix.клиент.ru. Панель мониторинга по открытому HTTP в 2026 году — это пароли и токены, летящие по сети открытым текстом.

Звучит как бюрократия, но именно на этих пятнадцати минутах спотыкается большинство самостоятельных внедрений: сервер поставили, хосты подключили, а через полгода выясняется, что Admin/zabbix так и живёт, и панель торчит наружу. Мы закрываем этот вопрос сразу и один раз.

Массовая установка Zabbix agent 2 на Windows через GPO

Вот здесь начинается настоящая экономия времени. Обойти вручную полсотни рабочих станций с флешкой — это не вечер, это неделя. Поэтому агент на весь Windows-парк мы раскатываем одной групповой политикой Active Directory. На саму политику уходит около получаса, дальше домен разносит агент сам.

Почему agent 2, а не классический агент

Zabbix предлагает два агента, и для нового внедрения мы всегда берём Zabbix agent 2. Он написан на Go, поставляется одним самодостаточным бинарником без внешних зависимостей, умеет плагины (мониторинг служб, дисков, отдельных приложений идёт из коробки без дописывания скриптов) и, что важно для парка машин за NAT, отлично работает в режиме активных проверок. Классический агент никуда не делся и совместим, но agent 2 — рекомендуемый вендором путь, и на дистанции он проще в сопровождении.

MSI с параметрами: адрес сервера и имя хоста прямо при установке

Windows-версия agent 2 поставляется как MSI-пакет, и главное его достоинство — все ключевые параметры можно задать прямо в командной строке установки. Не нужно потом руками править конфиг на каждой машине: сервер, к которому агент подключается, адрес для активных проверок и имя хоста прописываются через свойства msiexec. Для ручной проверки на одной машине команда выглядит так:

msiexec /i zabbix_agent2-7.0.28-windows-amd64-openssl.msi /qn ^
  SERVER=192.168.10.10 ^
  SERVERACTIVE=192.168.10.10 ^
  HOSTNAME="%COMPUTERNAME%" ^
  ENABLEPATH=1

Разберём параметры: SERVER — адрес нашего Zabbix-сервера, с которого разрешён опрос; SERVERACTIVE — тот же адрес для активных проверок (агент сам ходит на сервер за списком метрик); HOSTNAME с подстановкой %COMPUTERNAME% — чтобы каждая машина зарегистрировалась под своим сетевым именем, а не под одинаковым. Флаг /qn делает установку полностью тихой, без единого окна — именно то, что нужно для раскатки по домену.

GPO Software Installation против startup-скрипта: что реально работает

У групповых политик есть два способа доставить MSI на машины, и на практике они ведут себя по-разному:

• GPO Software Installation (Computer Configuration → Policies → Software Settings) умеет ставить «голый» MSI, но не позволяет передать ему параметры вроде SERVER и HOSTNAME напрямую. Чтобы их прокинуть, нужен MST-трансформ — отдельный файл-модификатор, который делается утилитой Orca. Способ рабочий, но лишний шаг с трансформом многие делают с ошибкой.
• Startup-скрипт (Computer Configuration → Windows Settings → Scripts → Startup) на практике оказывается надёжнее и прозрачнее. Кладём MSI в сетевую шару, доступную всем машинам на чтение, и вешаем на автозагрузку короткий скрипт, который ставит агент с нужными параметрами, если он ещё не установлен.

Наш рабочий вариант — именно startup-скрипт с проверкой, чтобы установка не повторялась при каждой перезагрузке:

@echo off
REM ставим агент только если служба ещё не зарегистрирована
sc query "Zabbix Agent 2" >nul 2>&1
if %errorlevel%==0 goto :eof

msiexec /i "\\dc01\deploy$\zabbix_agent2.msi" /qn ^
  SERVER=192.168.10.10 SERVERACTIVE=192.168.10.10 ^
  HOSTNAME="%COMPUTERNAME%" ENABLEPATH=1

Проверка sc query — маленькая, но важная деталь: без неё политика будет пытаться переустанавливать агент при каждом старте машины. Шара с MSI закрывается на чтение для группы «Domain Computers» — ставит-то агент из-под системной учётной записи компьютера, а не пользователя.

Активный агент для машин за NAT и филиалов

Отдельно про режим активных проверок, потому что он снимает главную головную боль распределённых сетей. В пассивном режиме сервер сам стучится к агенту на порт 10050 — значит, до каждой машины нужен сетевой доступ, а для филиала за NAT это проброс портов и дыры в периметре. В активном режиме всё наоборот: агент сам инициирует соединение к серверу на порт 10051, забирает список того, что нужно измерять, и отправляет данные. Направление — изнутри наружу, как у обычного браузера. Ничего пробрасывать не надо: машина в филиале, ноутбук в разъездах, сервер за NAT — все они достукиваются до Zabbix сами, лишь бы у них был исходящий доступ к его адресу и порту. Именно поэтому в наших MSI всегда заполнен SERVERACTIVE, а не только SERVER.

Порты стоит запомнить как таблицу умножения: сервер слушает 10051 (сюда ходят активные агенты и другие серверы), агент слушает 10050 (сюда ходит сервер за пассивными проверками). Их мы и будем открывать в файрволе — про это в разделе с граблями.

Подключаем первые хосты по готовым шаблонам

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

Windows-серверы: шаблон Windows by Zabbix agent

Начинаем с самого ценного — серверов. Контроллер домена, сервер 1С, файловый сервер. Создаём хост, указываем интерфейс агента (адрес машины и порт 10050 для пассива либо режим активных проверок), кладём в группу и вешаем шаблон Windows by Zabbix agent. Сразу после привязки шаблон приносит загрузку процессора, использование и подкачку памяти, заполнение всех дисков, аптайм, состояние ключевых служб и десятки других метрик. Через пару минут на хосте появляются первые данные, а вместе с ними — преднастроенные триггеры вроде «мало места на диске» или «сервис перезапустился».

Linux-серверы и сама VM мониторинга: мониторь мониторинг

Линуксовые машины подключаются так же — шаблон Linux by Zabbix agent. И отдельно проговорю принцип, который экономит нервы: мониторь сам мониторинг. Виртуалку Zabbix надо завести хостом в неё же саму — агент на ней мы поставили ещё на этапе установки. Если у сервера кончится место под базой или он захлебнётся, вы должны узнать об этом от него же, пока он ещё жив, а не постфактум, когда мониторинг молча умер и никто ничего не заметил. Хост «Zabbix server» с соответствующим шаблоном следит за очередью, за состоянием внутренних процессов и за свободным местом — это первая линия самодиагностики.

Сетевое железо по SNMP: роутеры и коммутаторы

На сетевое железо агента не поставишь, зато оно умеет отдавать метрики по протоколу SNMP. На управляемом коммутаторе или роутере включаем SNMP (для внутренней сети достаточно v2c с непустой community-строкой, для более серьёзных требований — шифрованный v3 с логином и паролем), в Zabbix заводим хост с SNMP-интерфейсом и вешаем шаблон. Есть универсальный Generic SNMP для базовых вещей (статус и трафик портов, аптайм), а под многие вендорские устройства — специализированные шаблоны, которые понимают их особенности. Перед привязкой полезно проверить, что железо вообще отвечает, прямо с сервера:

# проверяем ответ коммутатора по SNMP v2c (community "public" смените!)
snmpwalk -v2c -c public 192.168.10.1 1.3.6.1.2.1.1.5.0
# ответ вида SNMPv2-MIB::sysName.0 = STRING: core-switch — значит, живой

ИБП, принтеры, сайт и почта клиента

Дальше подбираем «остаточную» инфраструктуру, про которую все забывают до первой аварии:

• ИБП APC или Ippon. Если у бесперебойника есть сетевая карта — мониторим по SNMP (заряд батареи, нагрузка, переход на батарею при пропаже 220В). Если карты нет, а ИБП подключён к серверу по USB — ставим apcupsd и снимаем данные через него. Уведомление «офис перешёл на батарею» за десять минут до того, как всё погаснет, не раз спасало клиентам несохранённую работу.
• Принтеры. Сетевые печатающие устройства отдают по стандартному Printer MIB уровень тонера, счётчики и статус. Триггер «тонер ниже 10%» превращает вечное «опять принтер не печатает в самый неподходящий момент» в плановую закупку картриджа заранее.
• Сайт и почта клиента снаружи. Веб-сценарий (Web scenario) проверяет, что сайт открывается и отдаёт нужный код ответа, а простые проверки доступности портов следят за 443 (HTTPS), 25 и 993 (почта). Это как раз работа для внешней контрольной точки из первого раздела: она видит сервисы клиента так же, как их видит посетитель из интернета.

Автообнаружение: пусть Zabbix найдёт хосты сам

Заводить полсотни рабочих станций руками — скучно и долго даже при готовых шаблонах. Для этого есть автообнаружение (Discovery). Настраивается правило обнаружения по диапазону сети — например, вся офисная подсеть 192.168.10.0/24 — и Zabbix регулярно её прочёсывает: проверяет, отвечает ли по адресу Zabbix agent, пингуется ли машина по ICMP, откликается ли SNMP. На каждую найденную живую машину навешивается действие: добавить как хост, положить в нужную группу и повесить подходящий шаблон. Полсотни станций регистрируются сами за несколько проходов правила.

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

Первый осмысленный триггер и сквозной тест алерта

А вот теперь — кульминация вечера, ради которой всё затевалось. Собранные метрики бесполезны, если о проблеме никто не узнаёт. Поэтому вечер не считается прожитым не зря, пока не прошёл сквозной тест: мы намеренно ломаем что-то безопасное и убеждаемся, что цепочка сработала целиком — от датчика до уведомления в кармане инженера.

Сначала настраиваем канал доставки — Media type. Самый универсальный — Email: указываем SMTP реального почтового сервера клиента (или нашего relay, если своей почты нет), адрес отправителя, шифрование. Дальше привязываем этот канал к учётке инженера и создаём действие: «при возникновении проблемы — отправить письмо». В следующих статьях серии разберём Telegram-оповещения отдельно — это самый удобный для дежурного канал, но настраивается через дополнительный скрипт, и ему стоит посвятить отдельный разбор.

Теперь сам тест. Берём подключённый Windows-сервер и делаем что-то заметное, но безобидное — например, останавливаем службу печати (Print Spooler). И смотрим по секундомеру, как загорается цепочка:

1. служба остановилась — агент на следующем опросе передал новое состояние;
2. сработал триггер — в разделе Monitoring → Problems зажглась проблема;
3. отработало действие — на почту инженера ушло письмо;
4. письмо дошло до реального ящика, а не осело в спаме.

Пока все четыре пункта не отработали подряд — внедрение не закончено. Чаще всего спотыкается последний: письмо формируется, но не доходит из-за настроек почтового сервера. Лучше выяснить это сейчас, ломая спулер по своей воле, чем через месяц, когда по-настоящему ляжет сервер 1С в день сдачи отчётности, а спасительное письмо тихо застрянет в очереди.

Сразу закладываем и эскалацию — простую, но рабочую: если проблему за 30 минут никто не «взял» в работу (не подтвердил в интерфейсе), уведомление уходит повторно и дополнительно старшему инженеру. Это страховка от ситуации «письмо пришло, но дежурный был на обеде и не увидел». Тонкую настройку эскалаций и расписаний оповещений разберём в отдельной статье серии — на первый вечер достаточно одного уровня повтора.

Типовые грабли первого вечера

За десятки внедрений набор «детских болезней» первого вечера устоялся. Вот они, чтобы вы не наступали на то, на что уже наступили мы:

• Кодировка базы не UTF-8. Если базу создали без явного указания кодировки, русские названия хостов и описания триггеров превращаются в «кракозябры», а импорт схемы может ругаться. Базу создаём в UTF-8 сразу — в наших командах createdb это поведение по умолчанию для свежей PostgreSQL, но на старых или нестандартно настроенных инсталляциях проверьте SHOW SERVER_ENCODING; — должно быть UTF8.
• Файрвол не пускает 10050/10051. Классика: сервер и агенты стоят, а данных нет. На сервере ufw по умолчанию не открывает порт 10051, и активные агенты не могут достучаться. Открываем явно: sudo ufw allow 10051/tcp на сервере и 10050 там, где нужны пассивные проверки. На Windows-агентах аналогично — правило в брандмауэре Windows (agent 2 при MSI-установке обычно его создаёт сам, но проверить стоит).
• Активный агент не регистрируется из-за имени хоста. Самая коварная грабля активного режима: имя в параметре Hostname агента должно точно совпадать с именем хоста в Zabbix. Разошлись в регистре или опечатке — сервер не понимает, чьи данные пришли, и молча их отбрасывает. Именно поэтому в MSI мы подставляем %COMPUTERNAME% и то же имя используем при заведении хоста (или доверяем это автообнаружению).
• PHP-FPM с чужим часовым поясом. Веб-морда ругается на несовпадение таймзоны PHP. Лечится строкой date.timezone = Europe/Moscow в конфиге PHP-FPM и его перезапуском. Мелочь, но пугает при первом входе.
• TimescaleDB не активирован — история не сжимается. Расширение поставили, а CREATE EXTENSION и активацию нарезки на базе Zabbix забыли выполнить. Внешне всё работает, но диск пухнет как без сжатия, и через полгода упирается в потолок. Проверка: в веб-интерфейсе, в разделе состояния Zabbix, должна отображаться версия TimescaleDB. Пусто — значит, шаг пропущен, вернитесь к разделу про импорт схемы.
• Агент на Windows не стартует. Две частые причины. Первая — пробелы в пути к конфигу или бинарнику без кавычек в параметрах службы. Вторая — шифрование PSK настроено криво: ключ на агенте и на сервере не совпадают, и соединение отклоняется. На первом вечере проще начать без PSK во внутренней доверенной сети, а шифрование агент-сервер включить осознанно на втором этапе, когда всё уже работает.

Ни одна из этих граблей не смертельна, но каждая способна съесть полчаса, если бить по ней вслепую. Держите список под рукой — он превращает «почему-то не работает» в «а, вот же оно».

Чек-лист «вечер прошёл не зря» и что делать на второй неделе

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

Итого — примерно три с половиной часа плотной работы, то есть один вечер. На выходе: чистая VM превратилась в работающий мониторинг, который следит за инфраструктурой офиса и умеет сообщать об авариях. Если хоть один пункт остался незакрытым — вечер не закончен, особенно последний: непроверенный алерт — это не мониторинг, а его имитация.

А что дальше? Первый вечер даёт костяк, но настоящая ценность мониторинга раскрывается на дистанции. На второй неделе мы обычно занимаемся тонкой настройкой: убираем «шумные» триггеры, которые срабатывают на пустом месте и приучают дежурного игнорировать письма; подключаем Telegram-оповещения вместо почты; выстраиваем нормальные эскалации и расписания дежурств; настраиваем регулярный бэкап самого Zabbix через pg_dump. Каждой из этих тем посвятим отдельную статью серии — тюнинг триггеров, интеграция с Telegram и 1С, эксплуатация и резервное копирование. Начало положено в обзорной статье про Zabbix, а весь раздел о мониторинге собираем на странице статей.

Если разворачивать всё это по вечерам некому или некогда — просто напишите нам. Развернём по этому же регламенту, сдадим по этому же чек-листу и будем сопровождать: Telegram @ITfresh_Boss или +7 903 729-62-41. Один настроенный вечер экономит клиенту не одну бессонную ночь.