Zabbix 7 для офиса: как мы мониторим 200 хостов одним сервером

Привет! Я Семёнов Евгений Сергеевич, директор компании АйТи Фреш. Часто спрашивают: зачем сисадмину в офисе на 50 человек вообще нужен Zabbix? Мой ответ прост: чтобы система мониторинга сообщила о падении почтового сервера, а не разъярённый бухгалтер в 23:48. За пятнадцать лет работы я лично внедрил мониторинг в нескольких десятках компаний и могу точно сказать, что работает. Сегодня я поделюсь нашим подходом к разворачиванию Zabbix 7 LTS для типичного клиента: это 200-500 хостов под наблюдением, один сервер, никаких распределённых прокси и сложного enterprise-зоопарка. Только проверенные решения, которые реально приносят пользу малому и среднему бизнесу.

Кому и зачем нужен Zabbix в офисе

Когда я приезжаю на новый объект и задаю, казалось бы, простой вопрос — как у вас настроен мониторинг? — обычно слышу один из трёх типичных ответов. Первый, самый частый: «Да никак, нам бухгалтерия звонит, когда что-то ломается». Второй вариант: «Поставили на сервере штатный Performance Monitor, иногда заглядываем». Ну и третий, мой любимый, самый колоритный: «Zabbix есть, его пять лет назад какой-то парень поднимал, но он уволился, и теперь там жёлтые лампочки горят постоянно — мы их просто игнорируем». Понимаете, все эти сценарии приводят к одному и тому же: системы падают, бизнес несёт убытки, а крайним оказывается админ.

Я уверен, что внятный мониторинг необходим любой компании, где каждый час простоя обходится дороже 5000 руб./час. Рассчитать это очень просто: берём число сотрудников, умножаем на их среднюю зарплату за час и на коэффициент 0.5 (ведь половина людей всё равно чем-то занята, пока та же «1С лежит»). Для типичного офиса на 50 человек получается 12-15 тыс. руб./час простоя, а в особо напряжённые дни, например, во время отчётности или в конце месяца, эта сумма может доходить до всех 30 тыс. Грамотно настроенный Zabbix окупается моментально, буквально одним-единственным предотвращённым инцидентом.

Что мы мониторим у типичного клиента

Давайте посмотрим на моего клиента — производственную компанию «Инжимарт». У них 65 рабочих мест, два цеха расположены в Подмосковье, а бэк-офис — в Москве. Когда мы начали их обслуживать полтора года назад, мониторинга не было совсем. Это была чистая реактивная модель: ждём «звонка от пользователя», чтобы узнать о проблеме. За первый же месяц мы развернули Zabbix и взяли под наблюдение 218 объектов:

Знаете, какая тут ключевая мысль? Мониторить нужно не «всё подряд», а только те вещи, отказ которых реально остановит ваш бизнес. Если упадёт одна рабочая станция в отделе кадров — это, конечно, неприятно, но не катастрофа. А вот если вдруг ляжет сервер 1С или контроллер домена, тогда уже через минуту начнётся настоящая катастрофа. Именно поэтому мы всегда берём под наблюдение 100 % серверов, а рабочие станции мониторим выборочно.

Архитектура: один сервер вместо распределённой системы

В большинстве типичных туториалов вам предложат разворачивать сервер, базу, фронтенд и прокси — всё по отдельности. Для крупного оператора связи с 5000 хостами в десяти регионах это, безусловно, правильный подход. Но для обычного московского офиса с 200 объектами это просто overkill. Такая избыточность только усложняет администрирование и, что немаловажно, стоит лишних денег.

Моя рабочая схема для SMB — одна виртуальная машина на Ubuntu 24.04 LTS:

• 4 vCPU, 8 ГБ ОЗУ, 200 ГБ SSD (этого хватает на 200-500 хостов с историей за 90 дней).
• Zabbix Server 7.0 LTS — версия с долгосрочной поддержкой до 2029 года.
• PostgreSQL 16 + TimescaleDB вместо штатной БД (TimescaleDB на порядок быстрее на больших историях).
• Nginx + PHP-FPM для веб-интерфейса.
• Zabbix Agent 2 на этом же сервере — мониторим сам сервер мониторинга.

Отдельный Zabbix-прокси мы добавляем только в том случае, если у клиента есть удалённая площадка, где канал связи оставляет желать лучшего. У «Инжимарт» как раз такой случай: основной сервер стоит в центральном офисе, а прокси — на одном из цехов. Он собирает и буферизует данные с 30 хостов цеха, а потом отправляет их одним пакетом, что очень экономит трафик по 4G-каналу.

Установка Zabbix 7 на Ubuntu 24.04 за 30 минут

Делается за вечер. Берём чистую Ubuntu 24.04 LTS — с интернетом, после apt update и с проброшенными портами 80/443 под веб-интерфейс.

# 1. Подключаем репозиторий Zabbix 7.0 LTS
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_7.0-1+ubuntu24.04_all.deb
dpkg -i zabbix-release_7.0-1+ubuntu24.04_all.deb
apt update

# 2. Устанавливаем компоненты
apt install -y zabbix-server-pgsql zabbix-frontend-php \
    zabbix-nginx-conf zabbix-sql-scripts zabbix-agent2

# 3. Устанавливаем PostgreSQL 16 и TimescaleDB
echo "deb https://packagecloud.io/timescale/timescaledb/ubuntu/ noble main" | \
    tee /etc/apt/sources.list.d/timescaledb.list
wget -qO- https://packagecloud.io/timescale/timescaledb/gpgkey | \
    gpg --dearmor -o /etc/apt/trusted.gpg.d/timescaledb.gpg
apt update
apt install -y postgresql-16 timescaledb-2-postgresql-16

# 4. Создаём базу данных
sudo -u postgres psql -c "CREATE USER zabbix WITH PASSWORD 'YourStr0ngPass!';"
sudo -u postgres psql -c "CREATE DATABASE zabbix OWNER zabbix;"
sudo -u postgres psql -d zabbix -c "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;"

# 5. Импортируем схему Zabbix
zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | \
    sudo -u zabbix psql zabbix
cat /usr/share/zabbix-sql-scripts/postgresql/timescaledb/schema.sql | \
    sudo -u zabbix psql zabbix

Конфигурация PostgreSQL под нашу задачу — небольшая правка /etc/postgresql/16/main/postgresql.conf:

# Включаем TimescaleDB
shared_preload_libraries = 'timescaledb'

# Память — для виртуалки с 8 ГБ ОЗУ
shared_buffers = 2GB
effective_cache_size = 5GB
work_mem = 32MB
maintenance_work_mem = 512MB

# WAL и I/O
wal_buffers = 16MB
max_wal_size = 2GB
checkpoint_completion_target = 0.9
random_page_cost = 1.1

# Подключения
max_connections = 100

Конфигурация Zabbix Server (/etc/zabbix/zabbix_server.conf) — минимальный набор изменений под 200 хостов:

# База данных
DBHost=localhost
DBName=zabbix
DBUser=zabbix
DBPassword=YourStr0ngPass!

# Производительность
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

# Логи
LogFile=/var/log/zabbix/zabbix_server.log
LogFileSize=50

После запуска systemctl enable --now zabbix-server zabbix-agent2 nginx php8.3-fpm идём в браузер на адрес сервера, проходим мастер начальной настройки (логин/пароль БД, имя сервера, часовой пояс — Europe/Moscow), создаём админский пароль вместо стандартного Admin/zabbix.

Установка агента на Windows-серверы и рабочие станции

Под Windows мы используем Zabbix Agent 2. У него есть встроенные плагины для IIS, MSSQL, Memcached, что значительно экономит наше время. Мы просто скачиваем MSI-пакет с zabbix.com и устанавливаем его либо через групповую политику, либо вручную.

# Конфигурация агента C:\Program Files\Zabbix Agent 2\zabbix_agent2.conf

Server=10.10.10.50
ServerActive=10.10.10.50
Hostname=DC01.inzhimart.local
HostMetadata=windows-server;ad;dns;production

# Плагины — раскомментировать нужные
Plugins.MSSQL.URI=tcp:127.0.0.1:1433
Plugins.MSSQL.User=zabbix_monitor
Plugins.MSSQL.Password=monitoring_password

# Логи
LogFile=C:\Program Files\Zabbix Agent 2\logs\zabbix_agent2.log
LogFileSize=10

Тонкий момент с Windows: открыть TCP-порт 10050 в Windows Firewall и для входящих, и для исходящих. На AD-серверах ещё нужно дать сервисной учётке агента (по умолчанию Local System) доступ к WMI и Performance Counters. Готовый PowerShell-скрипт для массовой установки и настройки через GPO я выложил в нашем рабочем репозитории, ссылка по запросу.

Шаблоны: что мы используем для типового офиса

Пожалуй, главная фишка Zabbix — это его готовые шаблоны. В "коробке" с 7-й версией их уже около 300, они подходят практически под любое железо и софт. Вот что мы обычно прикручиваем у каждого нашего клиента:

Для 1С мне пришлось допилить собственный шаблон, потому что штатного просто нет. Мой шаблон мониторит систему на трёх уровнях: во-первых, это процессы (rphost, ragent, rmngr), во-вторых, технические метрики через rac (например, число сеансов или длительность блокировок), и, в-третьих, ключевые бизнес-показатели (скажем, время выполнения отчёта «Анализ продаж»). Кстати, он у нас в открытом доступе на GitHub — можете забирать и пользоваться!

Алерты в Telegram: настройка за 10 минут

Любая система мониторинга бесполезна без понятных оповещений. SMS и email в 2026 году — это медленно, дорого и легко пропускается. Telegram — быстро, бесплатно и доходит сразу.

# Создаём бота через @BotFather в Telegram
# Получаем токен вида 1234567890:AAEhBP...

# В Zabbix UI: Alerts → Media types → Telegram (готовый шаблон)
# Параметры:
#   bot_token: 1234567890:AAEhBP...
#   parse_mode: HTML
#   chat_id: {ALERT.SENDTO}

# Шаблон сообщения для проблем:
<b>[{TRIGGER.SEVERITY}] {EVENT.NAME}</b>

🖥 Хост: <code>{HOST.NAME}</code>
📍 IP: <code>{HOST.IP}</code>
📊 Значение: <code>{ITEM.LASTVALUE1}</code>
🕐 Когда: {EVENT.DATE} {EVENT.TIME}

🔗 <a href="https://zabbix.itfresh.ru/tr_events.php?triggerid={TRIGGER.ID}&eventid={EVENT.ID}">Открыть в Zabbix</a>

# Для каждого пользователя в Zabbix: Profile → Media → Telegram
# В поле "Send to" указывает свой chat_id (узнать через @userinfobot)

Дальше создаём Action: «Если severity >= Warning, отправлять в Telegram дежурному инженеру; если severity = Disaster, эскалировать через 5 минут на старшего инженера; через 15 минут — лично на меня». Это наша стандартная схема для всех клиентов на круглосуточной поддержке.

Совет из реальной жизни. Не отправляйте все алерты подряд в общий чат — он превратится в шум, который никто не читает. Разделите по severity: Information и Warning — в служебный канал для статистики, Average и High — дежурным, Disaster — отдельный канал с громким уведомлением, который никто не выключает.

Хитрости тюнинга для офисной нагрузки

Вот несколько практических советов, которые я наработал за годы плотной работы с Zabbix в сфере SMB:

Обязательно включайте TimescaleDB compression и retention. В перспективе 3-6 месяцев это становится критически важным для производительности всей системы. Если этого не сделать, база начинает разбухать до неприличных размеров, housekeeper тормозит, а простые запросы в дашбордах могут висеть по 10 секунд.

# Включаем компрессию данных старше 7 дней
SELECT add_compression_policy('history', INTERVAL '7 days');
SELECT add_compression_policy('history_uint', INTERVAL '7 days');
SELECT add_compression_policy('trends', INTERVAL '30 days');

# Автоматическое удаление старых chunks
SELECT add_retention_policy('history', INTERVAL '90 days');
SELECT add_retention_policy('history_uint', INTERVAL '90 days');
SELECT add_retention_policy('trends', INTERVAL '730 days');  # 2 года трендов

Не мониторьте каждую секунду. По умолчанию многие шаблоны опрашивают метрики каждые 30-60 секунд. Для офиса этого с лихвой достаточно. Не поднимайте интервал до 10 секунд — это утроит нагрузку на сервер без полезного эффекта. Для бизнес-метрик 1 раз в 5 минут — нормально.

Пожалуйста, используйте триггеры с зависимостями! Представьте: упадёт коммутатор, через который доступен ваш сервер, — и Zabbix начнёт слать алерты и про сам коммутатор, и про сервер, который стал недоступен. Настройте dependency (то есть укажите, что «триггер сервера зависит от триггера коммутатора») — и всё, никакого спама не будет.

Не забывайте про Maintenance windows перед плановыми работами. Перед тем как перезагрузить сервер или обновить Windows, поставьте хост в maintenance — иначе вы рискуете разбудить всех дежурных в 3 ночи кучей алертов типа «host unreachable». Это делается буквально за 5 секунд через UI, а сколько нервов вы сэкономите!

Дашборды: что показывать руководителю и что — себе

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

• NOC-экран для дежурных. Большая таблица «зелёное-жёлтое-красное» по всем критичным сервисам. Проблемы за последний час. Топ-10 хостов по нагрузке. Висит на отдельном мониторе в офисе сисадмина.
• Executive dashboard. Общий аптайм за месяц в процентах, количество инцидентов, среднее время восстановления (MTTR), стоимость предотвращённых простоев. Отправляется руководителю в виде PDF раз в неделю.

Для того чтобы генерировать красивые отчёты руководству, я довольно часто использую Grafana. Она, кстати, бесплатна и отлично умеет «тянуть» данные из Zabbix через официальный плагин. Но это, конечно, уже такой опциональный, второй уровень. Для базовой работы вполне хватает и встроенных дашбордов Zabbix 7 — в седьмой версии их очень заметно прокачали.

Что ломалось и как мы это чинили

За полтора года эксплуатации у «Инжимарт» мы столкнулись с тремя серьёзными проблемами по Zabbix, и, что интересно, все они были довольно типовыми.

1. PostgreSQL разросся до 180 ГБ всего за 4 месяца. Причина оказалась банальной: просто забыли включить TimescaleDB compression. В итоге бэкапы базы стали занимать по 2 часа, а виртуальная машина начала дико тормозить. Решение было очевидным: мы включили compression на всех hypertables, и уже через сутки база ужалась до 35 ГБ. С тех пор это первое, что я делаю на каждом новом сервере.

2. Алерты в Telegram перестали приходить ночью. Бот молчал, а в логах Zabbix мы видели таймаут. Выяснилось, что провайдер блокировал api.telegram.org именно в окне ночных регламентных работ. Что мы сделали? Подняли SOCKS5-прокси через нашу VPN-инфраструктуру и прописали его в настройках Media Type Telegram. Заодно, кстати, подсказали клиенту, какого провайдера лучше выбрать.

3. Веб-интерфейс открывался по 8 секунд. Причина — PHP-FPM с дефолтными настройками. По умолчанию pm.max_children = 5, а у нас 4 одновременных пользователя в офисе плюс автоматические запросы из Grafana. Поднял до pm.max_children = 20 и pm.start_servers = 5 — открывается за полсекунды.

Сколько это стоит и что вы получаете

А теперь давайте поговорим о деньгах — сколько это стоит для типичного клиента, например, с офисом на 50-80 человек и 200-300 объектами мониторинга.

В наш стандартный пакет внедрения входит всё необходимое: установка Zabbix Server и базы данных, настройка 5-10 шаблонов специально под вашу инфраструктуру, регистрация всех ваших серверов и сетевого оборудования, создание дашбордов как для админа, так и для руководителя, настройка алертов в Telegram, а также обучение вашего сисадмина базовому администрированию (это примерно 4 часа) и вся необходимая документация. По срокам — обычно от старта до приёмки уходит 2-3 рабочих недели.

FAQ — частые вопросы по внедрению Zabbix

Сколько стоит мониторинг офисной инфраструктуры на Zabbix?

Сам Zabbix бесплатный — это open-source. Расходы складываются из железа (виртуалка 4 vCPU, 8 ГБ ОЗУ, 200 ГБ SSD — около 6-8 тыс. руб./мес. при размещении в нашем дата-центре) и работ инженера на внедрение (от 95 тыс. руб.). Проект окупается за 3-4 месяца за счёт предотвращённых простоев.

Какое железо нужно для Zabbix на 200 хостов?

Виртуальная машина 4 vCPU, 8 ГБ ОЗУ, 200 ГБ SSD (с учётом 90 дней истории) — этого хватает с запасом. PostgreSQL и веб-интерфейс на той же машине. Если вырастете до 500 хостов — добавьте до 6 vCPU и 16 ГБ ОЗУ. Отдельный сервер БД нужен только начиная с 1000+ хостов.

Можно ли мониторить 1С через Zabbix?

Да, и весьма успешно. Мы используем три уровня мониторинга: технические метрики сервера 1С, состояние сервиса 1С:Предприятие через UserParameter, и бизнес-метрики (количество активных пользователей, время отклика типового документа). Шаблон отдаём клиентам бесплатно.

Чем Zabbix лучше Prometheus для офиса?

Для офиса с разнородной инфраструктурой (Windows-серверы, Mikrotik, ИБП, принтеры, 1С, СКУД) Zabbix удобнее: всё в одном продукте, не нужен node_exporter на каждой железке, есть готовые шаблоны для всего. Prometheus прекрасен для cloud-native окружения, но в офисе — overkill.

Как настроить алерты в Telegram?

В Zabbix 7 встроен Media Type Telegram. Создаёте бота через @BotFather, получаете токен, в Zabbix добавляете медиа-тип и шаблон сообщения. Каждому пользователю прописывается chat_id. Типичная схема: критичные алерты — в общий канал дежурных + личный чат старшего инженера, предупреждения — только в канал.