🟢 Статус: Conceptually stable · v0.1

Концепция устойчива, проверена опытом, литературой и практикой.

Этот раздел - каркас, на котором держится остальное. Что считать объектом мониторинга (сервис, не хост), что означает severity, как теги делают событие осмысленным, чем LLD отличается от ручного зоопарка метрик, и как четыре измерения слоёв собираются в проектный язык. Если эти пять глав пропустить, остальная книга читается как набор частных приёмов — потому что у них нет общего основания.

01. Сервис, а не хост¶

Главный принцип¶

«Сервер 1С пингуется» ≠ «1С работает».

«CPU на сервере Exchange в норме» ≠ «почта отправляется».

«Все агенты Zabbix зелёные» ≠ «у пользователей всё хорошо».

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

Зам.директора звонит начальнику ИТ: «1С не работает, бухгалтерия стоит!»
Начальник ИТ открывает Zabbix: «У нас всё зелёное».
Через 40 минут выясняется, что исчерпались доступные лицензии 1С/HASP, веб-публикация падает, но сам сервер пингуется отлично.

Дашборд врёт. Не потому, что Zabbix плохой — а потому, что мониторили не то.

Шесть слоёв того, что нужно мониторить¶

Снизу вверх:

Слой	Что	Чем
Hardware	iLO/iDRAC, ИБП, температура, диски RAID	SNMP, IPMI
Network	Cisco/Eltex/UserGate — порты, CPU, BGP, тоннели	SNMP, SNMP-traps
OS	Win/Linux — CPU, RAM, диски, сервисы	Zabbix-agent (active)
Middleware	MSSQL, PostgreSQL, Exchange DAG, IIS, веб-публикации 1С	SQL-чеки, native templates
Application	1С — очереди, фоновые, лицензии RPHost; SCADA — связь	API, log-monitoring
Business	«Зарплата начислится сегодня?», «Документ выпускается?»	синтетика, e2e-чеки

Большинство Zabbix-инсталляций закрывают слои 1–3, плохо закрывают 4, почти не закрывают 5, и редко закрывают системно 6.

А пользователю важен только слой 6.

Что значит «мониторить сервис»¶

Возьмём 1С как пример. «1С работает» — это:

rmngr (менеджер кластера) запущен
rphost (хотя бы один рабочий процесс) запущен
RAS/rac endpoint отвечает (порт зависит от конфигурации кластера 1С, по умолчанию 1545)
MSSQL для 1С — отвечает на запросы, нет deadlock'ов выше порога
Веб-публикация отдаёт страницу логина за разумное время
HASP лицензии не исчерпаны
Вчерашний бэкап прошёл успешно
Синтетический тест: "тестовый пользователь" логинится и проводит «пустой» документ за N секунд

Любое из 1–7 может быть зелёным, а сервис при этом не работать. Только пункт 8 — это «1С работает с точки зрения пользователя». Остальное — компоненты, которые тушат алерты по очереди, пока проблема нарастает.

Иерархия алертов «сервис → компонент → ресурс»¶

Когда у вас есть синтетика и компонентные проверки одновременно — нужно их правильно связать, иначе на одно реальное падение прилетит двадцать алертов одновременно.

ALERT: 1С-ERP сервис недоступен (Disaster)
   └ детали: синтетика "логин test_user" падает 3 раза подряд
        └ дочерние алерты (подавлены через trigger dependencies):
              ├ rphost.count = 0 (High)
              ├ MSSQL deadlocks > 100 (High)
              ├ HASP free < 2 (High)
              └ RAC port 1545 not responding (High)

Дежурный видит один Disaster и сразу под ним — список причин. А не «20 алертов прилетели за 30 секунд, разбирайся сам».

Технически это можно реализовать через trigger dependencies в Zabbix, но с важной оговоркой: dependency в первую очередь удерживает actions/notifications для зависимых триггеров, а не строит иерархию "сервис → причины" визуально. Сервисная синтетика — это верхнеуровневый симптом, а не первопричина. Если зависимость настроена неаккуратно, можно потерять диагностические component-алерты именно тогда, когда они нужны.

Для построения полноценной картины "сервис → компоненты → проблемы" правильнее использовать Zabbix Services + problem tags: сервис в Services видит связанные проблемы по тегам, а дашборд и root cause view (элемент интерфейса Zabbix) собирают нужный контекст без подавления компонентных алертов.

Trigger dependencies — рабочий инструмент там, где есть понятная причинно-следственная связь (например: сеть → downstream сервисы, core-свитч → все хосты площадки). Для сервисной иерархии они слабее, чем Services + tags.

Откуда берутся синтетические проверки¶

Это самая «дорогая» часть мониторинга — она требует прикладной экспертизы, не только сетевой/системной.

Примеры синтетики:

Сервис	Синтетика
1С	Тестовый пользователь логинится в веб-публикацию, проводит пустой документ в тестовой базе, выходит. Засекается время каждого шага. ⚠ Только в согласованной тестовой ИБ/организации — не в производственной базе напрямую.
Exchange	Скрипт раз в 5 мин отправляет письмо `mon-out@<domain>` → `mon-in@<domain>` через OWA/SMTP. Триггер на отсутствие письма за N мин
AD	LDAP bind тестовым пользователем со всех площадок к локальному DC
DFS / файловые шары	`Test-Path \\dfs-root\common\test.txt` с разных хостов
Печать	Печать тестового PDF на референсный принтер раз в час
VPN	TCP-handshake до публичного хоста через VPN-туннель

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

Когда сервисная модель не нужна¶

Не делайте сервисную модель «на всякий случай». Это работа, и она имеет смысл только если:

У вас есть дежурная смена, и она реагирует
У вас обсуждается SLA (внутренний или внешний)
У вас более 5 бизнес-сервисов с разными владельцами
Руководство периодически спрашивает «а где у нас проблемы по сервисам, не по железкам»

Если ничего из этого — компонентного мониторинга достаточно. Сервисный слой добавите, когда подоспеет потребность.

Резюме¶

Что	Где обсуждается
Как реализовать сервисную модель технически	Глава 6 — Архитектура, Глава 13 — Шаблоны
Как связать с SLA	Глава 10 — SLA
Как теги участвуют в сервисной модели	Глава 3 — Теги
Какие синтетические проверки имеют смысл	Часть IV (Шаблоны)

Главное — держать в голове: на дашборде CIO должны висеть бизнес-сервисы, а не количество доступных хостов. Если у вас на дашборде CIO висит «доступность хостов 99.8%» — у вас проблема не с Zabbix, а с моделью.