00. Манифест¶

Зачем эта книга¶

Мониторинг крупной инфраструктуры ломается не на триггерах и графиках. Он ломается там, где непонятно, что считать сервисом, кто владелец проблемы, какие события требуют реакции, а какие — просто шум. Эта книга — про то, как из Zabbix собрать управляемую эксплуатационную систему. Не пересказ документации: возможности там описаны исчерпывающе. Именно подход: сервисная модель, шаблоны, severity, алертинг, runbook, дашборды, регулярная эксплуатация. Контекст — крупная гетерогенная ИТ-инфраструктура: завод, холдинг, распределённая компания с 1С, MSSQL, устаревшими Windows-системами, OT/SCADA и периметром. 187-ФЗ и КИИ здесь не юридическая тема — это архитектурное ограничение: где установка агента требует согласования с ИБ/владельцем ЗОКИИ и учёта требований безопасности, где нужны отдельные контуры, где мониторинг должен быть осторожным. На русском много рецептов по Zabbix. Материалов, которые связывают его с реальной эксплуатацией такой среды, — существенно меньше. Этот разрыв и закрывает книга.

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

Версии Zabbix¶

Книга ориентирована на Zabbix 6.0 LTS и Zabbix 7.0 LTS как основные LTS-ветки, а также учитывает возможности актуальных релизов 7.x там, где они важны для практики. Большинство концепций (сервисная модель, теги, severity, runbook) применимы к любой современной версии. Там, где возможность специфична для версии, это явно отмечено в тексте.

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

Чего здесь нет¶

Установки Zabbix step-by-step. Это есть в официальной документации. Лучше там.
Нет готовых production-ready шаблонов Zabbix. Материалы в части IV — это проектные спецификации, примеры структуры и требования к будущим шаблонам.
Маркетинга в пользу Zabbix. Где Prometheus или коммерческое решение лучше — об этом сказано.
Универсальных ответов. Везде есть оговорки: «в нашем контексте», «для завода 4К хостов», «без КИИ-сегментов».

Главные идеи (если читать только манифест)¶

1. Мониторинг — это не «поставили Zabbix». Это функция эксплуатации: сбор → хранение → корреляция → визуализация → алертинг → реагирование (runbook) → постмортем → обратно в шаблоны. Если хотя бы одно звено отсутствует — у вас не мониторинг, а декорация.

2. Сервис, а не хост. «1С работает» — это не пинг сервера. Это: AS работает + SQL отвечает + публикация отдаёт логин + вчерашний бэкап успешен. Мониторим сервисы, а не железо.

3. Severity = действие, не цвет. Disaster = «звоним сейчас». High = «к утру». Average = «тикет». Information = «лог». Если на алерт никто не реагирует — это не алерт, это метрика. Понизить severity или удалить.

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

4. Runbook в триггере. Каждый Disaster и 80% High должны иметь ссылку на runbook в поле Menu entry URL триггера — она доступна в уведомлениях через макрос {TRIGGER.URL}. TL;DR в первых трёх строках runbook закрывает 80% ночных вызовов.

Зрелостный критерий: новые Disaster/High без runbook не принимаются; legacy High закрывается итерационно — Disaster получает хотя бы escalation stub сразу.

5. Tag schema — фундамент. Без тегов вы не получите маршрутизацию алертов по командам, не построите дашборды по сервисам, не посчитаете SLA, не сделаете корреляцию событий, не отфильтруете кому какие Problems видны. Тегирование — не косметика, а архитектурный слой. См. главу 3.

6. SLA не подписываем без 3 месяцев исторических данных. Сначала измеряем, потом обязуемся. Иначе подписываете цифры из потолка и не вытягиваете.

Для новых сервисов допустимо стартовать с provisional SLO/SLA — с явным условием пересмотра через 30/60/90 дней после накопления реальной статистики.

7. Read-only месяц в начале проекта. Когда заходите в чужой Zabbix — не правите триггеры «пока есть время». Не ставите агенты «посмотреть». Сначала понять, потом проектировать.

Что значит «крупная гетерогенная ИТ-инфраструктура»¶

Условный портрет:

1000–5000+ хостов (физические серверы + виртуальные машины)
Несколько площадок, часть с плохой связностью
IT и OT (SCADA) одновременно, обычно с КИИ-статусом
Типичный стек: 1С, Exchange (наследие), MSSQL/PostgreSQL, AD/DFS, UserGate, Cisco/Eltex, MasterScada4D, Veeam, TrueNAS, VMware/Hyper-V/KVM/РЕД
Дежурная смена 24/7, разный уровень квалификации ночных операторов
ИБ-требования (PSK/TLS, RBAC, аудит)
Legacy Zabbix, развёрнутый кем-то 4 года назад «как получилось»

Если у вас 20 хостов и всё в облаке — большая часть книги для вас избыточна. Если 200 хостов и стек попроще — берите главами по выбору.

Для кого¶

DevOps / системные инженеры, которым достался Zabbix «как есть» от предшественников
Архитекторы, проектирующие мониторинг для производственного предприятия
Тимлиды, переводящие команду от «красных лампочек» к зрелой эксплуатации
Студенты и стажёры — для понимания, как устроен мониторинг в крупных компаниях
Менеджеры, которым нужно понимать, что вообще такое «зрелый мониторинг» и сколько он стоит

Язык и стиль¶

Книга написана живым инженерным языком — намеренно. Здесь используется жаргон практиков: «Disaster», «шаблон», «тег», «хост», «runbook», «постмортем».

Английские термины сохраняются там, где они: - являются устоявшимися стандартами индустрии: SLA, SLO, API, CI/CD, RBAC, GitOps - являются официальными именами интерфейса Zabbix: trigger, item, template, action, media type - служат предметом объяснения в конкретной главе: runbook, postmortem, LLD

Официальные русские эквиваленты терминов Zabbix и их английские названия приведены в глоссарии.

Главное правило при чтении¶

Сверяйте с контекстом. Везде, где написано «обычно», «как правило», «в большинстве случаев» — есть исключения. Везде, где приведён конкретный порог (CPU > 85%, queue > 100) — это отправная точка, не догма. Тюнинг порогов под вашу инфраструктуру — это отдельная работа на месяц-два после внедрения.

Если книга расходится с реальностью — побеждает реальность.