Zabbix Enterprise Guide¶
Книга-руководство по построению зрелого мониторинга на Zabbix для крупных инфраструктур.
Не инструкция. Не сборник готовых шаблонов. Это операционная инженерия: как думать про мониторинг, как заходить в проект с криво развёрнутым Zabbix, как разделить IT и OT, как не утонуть в шуме алертов.
С чего начать¶
Если нужен общий словарь перед чтением или во время проекта, откройте глоссарий: там собраны ключевые термины книги с отсылками к главам и рабочим артефактам.
Если вы здесь впервые — читайте по порядку первые шесть глав (часть «Принципы и дизайн»). Это основа, без которой остальные главы рассыпаются:
- Манифест — зачем эта книга и кому она полезна
- Сервис, а не хост — главный принцип всего, что дальше
- Severity = действие — почему 200 Disaster-триггеров это не зрелость
- Теги и группы — двухосная модель, без которой ничего не работает
- LLD и prototypes — фундамент масштабирования
- Многоуровневый дизайн — методический центр: как четыре измерения слоёв собираются в единый язык проектирования
Дальше — по вкусу:
- Внедрение Zabbix с нуля или с легаси → начните с Implementation Playbook, затем используйте reference 90-day roadmap
- Архитектура и масштабирование → Слои и развёртывание
- Эксплуатация уже работающего Zabbix → Эксплуатационная модель + Runbooks
- Нужно проектировать или принимать шаблоны → Требования к шаблонам с честным дисклеймером
Статусы глав¶
| Бейдж | Значение |
|---|---|
| 🟢 | Conceptually stable — концепция устойчива |
| 🟡 | Design draft — подход верный, код/пороги требуют валидации |
| 🔴 | Requirements only — это ТЗ, не имплементация |
| ⚫ | Lab-tested — проверено в лаборатории |
| 🟣 | Production-tested — проверено в продакшне |
В шапке каждой главы — её статус.
Критерии валидации статусов ⚫ / 🟣:
| Параметр | Lab-tested | Production-tested |
|---|---|---|
| Версия Zabbix | указана явно | указана явно |
| Размер стенда | hosts/items/NVPS | реальная нагрузка |
| БД | тип и версия | тип и версия |
| Proxy | да/нет | да/нет |
| HA | не требуется | желательно |
| Сценарий отказа | базовый smoke | подтверждён в поле |
Если глава не несёт ни ⚫, ни 🟣 — считайте её непроверенной на конкретной инфраструктуре.
Полное оглавление¶
Часть I. Принципы и дизайн¶
- Манифест · 🟢
- Сервис, а не хост · 🟢
- Severity = действие · 🟢
- Теги и группы · 🟢
- LLD и prototypes · 🟢
- Многоуровневый дизайн · 🟢
Часть II. Архитектура и внедрение¶
- Слои и развёртывание · 🟡
- Implementation Playbook · 🟡
- Reference 90-day roadmap внедрения · 🟡
- GitOps для Zabbix · 🟢
Часть III. Эксплуатация¶
- Runbooks · 🟢
- SLA и сервисный каталог · 🟡
- Дашборды и отчётность · 🟢
- Эксплуатационная модель · 🟡
Часть IV. Шаблоны¶
Финал¶
- Anti-patterns · 🟢
Практические примеры¶
В репозитории есть директория examples/:
tag-schema.yaml— reference-схема тегов;triggers/— примеры trigger expressions;userparameters/— примеры UserParameter;project/— RACI, phase gates и implementation checklist.
Они намеренно вынесены из книги: это рабочие артефакты для копирования и адаптации, а не narrative-главы. Статус большинства примеров — 🟡 Design draft.
Лицензия¶
- Документация — CC BY-SA 4.0
- Код — MIT
Project and decision artifacts¶
Для практического внедрения используйте:
examples/project/— RACI, phase gates, implementation checklist и decision log;examples/decisions/— ADR template и примеры архитектурных решений.
ADR нужны не для бюрократии, а чтобы зафиксировать: какой вариант выбран, почему, кто согласовал, какие последствия для эксплуатации и когда решение пересматривать.