Статус: Reference draft
Глоссарий фиксирует язык книги. Это не официальный словарь Zabbix и не замена документации, а прикладная карта терминов: что термин значит именно в этой методике и где читать подробнее.
Глоссарий¶
Официальные термины Zabbix: EN / RU / язык книги¶
Zabbix имеет официальную русскую локализацию документации и интерфейса. Часть её терминов отличается от живого языка инженерного сообщества: в документации написано «узел сети», в разговоре чаще говорят «хост». В таблице ниже разделены три слоя: английский термин, официальный русский вариант и форма, которую книга использует в основном тексте для краткости и простоты.
| Английский термин | Официальная русская терминология Zabbix | В книге |
|---|---|---|
| Host | Узел сети | хост |
| Host group | Группа узлов сети | группа хостов / host group |
| Host prototype | Прототип узла сети | прототип хоста / host prototype |
| Item | Элемент данных | item / элемент данных / метрика по контексту |
| Item prototype | Прототип элемента данных | item prototype / прототип элемента данных |
| Trigger | Триггер | триггер |
| Trigger prototype | Прототип триггера | trigger prototype / прототип триггера |
| Problem | Проблема | problem / проблема |
| Template | Шаблон | шаблон |
| Discovery rule | Правило обнаружения | LLD rule / правило LLD |
| Action | Действие | action / действие |
| Media type | Тип оповещения | media type / канал оповещения |
| User macro | Пользовательский макрос | user macro / пользовательский макрос |
| Maintenance window | Окно обслуживания | maintenance window / окно обслуживания |
| Service (Zabbix Services / SLA) | Услуга | услуга / service object |
| Service (Linux/Windows) | Служба | служба |
| Service (бизнес-смысл) | Сервис | сервис |
| Map | Карта сети | карта / network map |
| User role | Роль пользователя | роль пользователя |
| Audit log | Журнал аудита | audit log / журнал аудита |
Термины сгруппированы по смыслу, а не по алфавиту. Если читаете книгу впервые, полезнее идти от сервисной модели к событиям, шаблонам, архитектуре и эксплуатации.
Базовая модель¶
| Термин | Коротко | Где читать |
|---|---|---|
| Мониторинг | Не набор графиков, а эксплуатационная функция: сбор данных, хранение, корреляция, визуализация, алертинг, реагирование и улучшение шаблонов после инцидентов. | Манифест, Архитектура, Операционка |
| Метрика | Измеряемое значение: загрузка CPU, возраст бэкапа, число сессий, статус проверки. Метрика сама по себе ещё не алерт. | Сервис, а не хост, Severity |
| Item | Объект Zabbix, который собирает одну метрику или состояние. | LLD, Требования к шаблонам |
| Trigger | Правило, которое превращает метрику в проблемное состояние. В зрелой модели trigger должен не только «краснеть», но и нести смысл через severity, теги и ссылку на runbook. | Severity, Теги, Многоуровневая модель |
| Alert | Уведомление человеку или системе. Не каждое событие PROBLEM должно становиться активным уведомлением. | Severity, Операционка |
| Event | Событие Zabbix: факт изменения состояния, например переход trigger в PROBLEM или OK. | Теги, Многоуровневая модель |
| Problem event | Событие PROBLEM, с которым работает дежурный: что сломалось, где, чей сервис, какое влияние и что делать. | Многоуровневая модель, Implementation Playbook |
| Recovery event | Событие восстановления. Важно для уведомления о восстановлении, автоматического закрытия тикетов и расчёта времени восстановления. | Многоуровневая модель, Операционка |
| Host | Объект мониторинга в Zabbix. Это может быть сервер, сетевое устройство, proxy, виртуальный объект или синтетическая точка проверки. | Сервис, а не хост, Теги |
| Service | Бизнес-смысл, ради которого существуют компоненты: 1С, почта, файловые шары, печать, SCADA-контур. Сервис не равен одному хосту. | Сервис, а не хост, SLA |
| Business service | Сервис глазами пользователя или бизнеса: «можно провести документ», «почта отправляется», «производственный контур виден». | Сервис, а не хост, Дашборды |
| Component | Техническая часть сервиса: БД, IIS, rphost, лицензии HASP, очередь, сетевой линк. | Сервис, а не хост, Многоуровневая модель |
| Resource | Низкоуровневый ресурс: CPU, RAM, диск, интерфейс, процесс. Ресурс важен, но не всегда означает влияние на сервис. | Сервис, а не хост, Severity |
| Synthetic check | Проверка пользовательского пути: логин, открытие страницы, отправка письма, запись/чтение файла. Ловит проблемы, которых не видно по отдельным компонентам. | Сервис, а не хост, Roadmap |
| E2E-проверка | End-to-end сценарий, проверяющий сервис целиком с точки зрения пользователя. | Сервис, а не хост, Roadmap |
| Сервисная модель | Способ описать мониторинг вокруг бизнес-сервисов, а не вокруг списка серверов. | Сервис, а не хост, SLA |
| Сервисный каталог | Список сервисов, владельцев, часов работы, критичности, зависимостей и целевых уровней доступности. | SLA, Implementation Playbook |
| Service owner | Владелец сервиса: человек или роль, которые принимают бизнес-смысл, критичность и правила реакции. | SLA, Implementation Playbook |
| Monitoring owner | Владелец мониторинга как продукта: отвечает за правила, качество модели, развитие и эксплуатационную дисциплину. | Implementation Playbook, Roadmap |
Severity, события и реакция¶
| Термин | Коротко | Где читать |
|---|---|---|
| Severity | Не «насколько страшно», а какое действие требуется и за какое время. | Severity, Roadmap |
| Disaster | Бизнес-сервис недоступен или есть критичное влияние на пользователей. Требует немедленной реакции, звонка/эскалации и runbook. | Severity, Anti-patterns |
| High | Сервис деградирует или скоро ляжет, если не вмешаться. Требует активного уведомления и реакции в ограниченное время. | Severity, Runbooks |
| Average | Требует плановой реакции, но не должен будить команду ночью. Часто уходит в тикет или рабочий канал. | Severity |
| Warning | Превентивный сигнал или тренд. Обычно дашборд/плановая работа, а не активный алерт. | Severity, Операционка |
| Information | Событие, которое полезно знать, но на которое не реагируют как на инцидент. | Severity |
| Impact | Влияние проблемы на сервис: недоступность, деградация, риск исчерпания ресурсов, риск потери данных. Часто фиксируется тегом. | Теги, Многоуровневая модель |
| Scope | Тип проблемы: доступность, производительность, ёмкость, резервное копирование, безопасность, качество. | Теги, Многоуровневая модель |
| Усталость от алертов (Alert fatigue) | Состояние, когда алертов так много, что команда перестаёт им доверять и пропускает реальный инцидент. | Severity, Операционка, Anti-patterns |
| Disaster inflation | Ситуация, когда слишком много триггеров имеют severity Disaster, и настоящий Disaster теряется в шуме. | Severity, Anti-patterns |
| Silent mode | Крайность, когда уведомления выключены или игнорируются, и команда узнаёт о проблемах от пользователей. | Severity |
| Action | Правило Zabbix, которое решает, кому и куда отправить уведомление или какую операцию выполнить. | Теги, Многоуровневая модель |
| Operation | Конкретное действие внутри Action: отправить сообщение через media type, выполнить remote command. Webhook в Zabbix реализуется как media type/интеграция и вызывается через операцию отправки сообщения. | Многоуровневая модель, Roadmap |
| Recovery operation | Действие при восстановлении: уведомить о RESOLVED, закрыть тикет, обновить статус. | Многоуровневая модель, Операционка |
| Escalation | Передача инцидента дальше по цепочке: L1, L2, профильная команда, руководитель. | Архитектура, Операционка |
| Escalation matrix | Документированная схема: кто получает P1/P2, через сколько минут, кто резервный контакт. | Операционка, Implementation Playbook |
| L1 / L2 | Уровни поддержки. L1 — дежурный/NOC: первичное реагирование, диагностика по runbook. L2 — профильный инженер: разбор корневых причин, нестандартные случаи. | Runbooks, Операционка |
| Дежурство (On-call) | Роль или функция, обязанная реагировать на активные уведомления. | Runbooks, Операционка |
| NOC | Network Operations Center — операционный центр или дежурная функция: наблюдает за активными проблемами, подтверждает события и эскалирует. | Дашборды, Операционка |
| Acknowledge | Подтверждение, что событие взято в работу. Не равно исправлению проблемы. | Дашборды, Операционка |
| Auto-resolve | Событие восстановилось само. Полезно для анализа шума и проверки, были ли реальные действия. | Дашборды, Операционка |
| Flapping | Частое переключение OK/PROBLEM. Требует гистерезиса, задержек, коррекции порогов или другой логики trigger. | Roadmap, Операционка |
| Hysteresis | Разные условия входа в проблему и выхода из неё, чтобы trigger не «дребезжал». | Roadmap, Требования к шаблонам |
| Trigger dependency | Зависимость между триггерами, позволяющая подавлять дочерние симптомы при корневой проблеме. | Сервис, а не хост, Roadmap |
| Correlation | Объединение или подавление связанных событий, чтобы вместо каскада симптомов получить управляемую картину. | Манифест, Архитектура, Теги |
| Noise ratio | Доля шумовых, бесполезных или самовосстанавливающихся алертов. Используется в регулярном разборе алертов. | Операционка, Дашборды |
| Alert hygiene | Регулярная дисциплина: чистка шумных триггеров, проверка severity, наличие runbook и корректной маршрутизации. | Операционка, Дашборды |
| Еженедельный разбор алертов (Weekly alert review) | Регулярная короткая встреча, где разбирают топ шумовых триггеров, пропуски runbook и качество реакции. | Операционка, Implementation Playbook |
Теги, группы и смысл события¶
| Термин | Коротко | Где читать |
|---|---|---|
| Tag | Метаданные Zabbix, которые дают событию смысл: сервис, владелец, среда, компонент, тип проблемы. | Теги, Многоуровневая модель |
| Tag schema | Документированный набор обязательных тегов, уровней размещения и разрешённых значений. | Теги, ADR tag schema |
| Mandatory tags | Минимальный набор тегов, без которого host/event нельзя считать управляемым. | Теги, Implementation Playbook |
| Allowed values | Разрешённые значения тегов, чтобы не получить 1c, 1c-erp, ERP-1C как разные сервисы. |
Теги, examples/tag-schema.yaml |
| Host tag | Тег на уровне host: кто объект, чей он, где расположен, какой сервис обслуживает. | Теги, Многоуровневая модель |
| Item tag | Тег на уровне item: что измеряется, например файловая система, rphost, возраст резервной копии. | Теги, Многоуровневая модель |
| Trigger tag | Тег на уровне trigger: что произошло и как реагировать: область проблемы, компонент, влияние, уведомление, runbook. | Теги, Многоуровневая модель |
| Prototype tag | Тег, заданный на prototype, чтобы discovered item/trigger сразу наследовал правильный смысл. | LLD, Теги |
Event tag service |
Методический тег события (service=<name>), связывающий объект или событие с бизнес-сервисом. Используется для дашбордов, маршрутизации и фильтрации. |
Теги, Многоуровневая модель |
| Zabbix Service tag | Тег, настраиваемый непосредственно на объекте типа Service в Zabbix (раздел Services). Используется для сопоставления SLA и сервисных правил; не то же самое, что event tag service= на хосте/триггере. |
SLA, Теги |
| env | Среда хоста: prod, test, dev, dr. dr — площадка аварийного восстановления (Disaster Recovery site). Нужна для фильтрации, маршрутизации и окон обслуживания. |
Теги, Roadmap |
| location | Площадка или логическое место: dc-main, plant-main, remote-site. | Теги, Многоуровневая модель |
| segment | Сетевой или организационный сегмент: it, ot, dmz, cloud. Влияет на права, безопасность и архитектуру proxy. | Теги, Архитектура |
| owner | Команда или роль, которая отвечает за сервис/компонент. | Теги, Implementation Playbook |
| criticality | Критичность сервиса или объекта, обычно P1/P2/P3/P4. Не должна заменять severity. | Теги, Roadmap |
| os_family | Семейство ОС, полезное для фильтрации, шаблонов, отчётности и инвентаризации. | Теги, Roadmap |
| role | Роль хоста: 1c-app, mssql, proxy, web, db. Не равна бизнес-сервису. | Теги, Многоуровневая модель |
| notification | Тег, который определяет активность уведомления: active, passive, dashboard-only и т.п. | Теги, Многоуровневая модель |
| Host group | Группа объектов мониторинга: официально «группа узлов сети», в книге часто «группа хостов». В этой методике нужна для RBAC и грубой технической навигации, а не для сервисного каталога. | Теги, Roadmap |
| RBAC | Role-Based Access Control: модель прав доступа, определяющая, кто что видит и кто что может менять. В Zabbix во многом опирается на host groups. | Теги, Roadmap |
| Business view | Представление сервисов для бизнеса: статус, SLA, влияние на пользователей, без низкоуровневого шума. | Сервис, а не хост, Дашборды |
| Service tree | Дерево бизнес-сервисов и зависимостей, через которое можно показывать статус сервиса, а не отдельных хостов. | Многоуровневая модель, SLA |
| Event context | Полный набор данных в событии: сервис, владелец, среда, компонент, влияние, runbook, площадка. | Многоуровневая модель, Теги |
| Tag-based routing | Маршрутизация уведомлений по тегам события, а не по имени host group или trigger. | Теги, Многоуровневая модель |
| Maintenance by tags | Подавление конкретного типа проблем через теги. Окно обслуживания задаётся на хостах или группах хостов, а теги используются как фильтр подавления проблем внутри заданной области. | Теги, Операционка |
Шаблоны, LLD и композиция¶
| Термин | Коротко | Где читать |
|---|---|---|
| Template | Шаблон Zabbix: набор элементов данных, триггеров, LLD-правил, макросов, тегов и правил для класса объектов. | Многоуровневая модель, Требования к шаблонам |
| Linked template | Шаблон, привязанный к хосту или другому шаблону. В Zabbix композиция строится через набор связанных шаблонов. | Многоуровневая модель |
| Template composition | Подход «несколько узких шаблонов на хост», а не один монолитный шаблон на всё. | Многоуровневая модель, ADR composition |
| Base template | Шаблон базового слоя: ОС, агент, сеть, инфраструктурные ресурсы. | Многоуровневая модель, Требования к шаблонам |
| Role template | Шаблон роли хоста: например сервер MSSQL, узел приложения 1С, участник Exchange DAG. | Многоуровневая модель, ADR composition |
| Application template | Шаблон прикладных метрик, которые описывают работу приложения или сервиса. | Многоуровневая модель, Требования к шаблонам |
| Synthetic template | Шаблон пользовательского сценария: логин, письмо, веб-путь, файл. | Сервис, а не хост, Многоуровневая модель |
| Common Policy template | Узкий шаблон политик: соглашения, макросы, общие технические теги. Не место для случайных items. | Многоуровневая модель |
| Agent Health template | Шаблон проверки самого агента: доступность, свежесть активных проверок, версия. | Многоуровневая модель, Операционка |
| Self-monitoring | Мониторинг самого Zabbix и его компонентов. Должен быть отдельным контуром, потому что слепота мониторинга критична. | Многоуровневая модель, Операционка, Anti-patterns |
| Monolithic template | Антипаттерн: один шаблон, куда складывают ОС, приложение, БД, синтетику и исключения. | Многоуровневая модель, Anti-patterns |
| LLD | Low-Level Discovery: автообнаружение сущностей внутри host и создание элементов данных/триггеров по prototype. | LLD, Требования к шаблонам |
| Discovery rule | Правило LLD, которое возвращает найденные сущности: диски, интерфейсы, БД, очереди, сервисы. | LLD, Требования к шаблонам |
| Prototype | Заготовка объекта, из которой LLD создаёт конкретные элементы данных, триггеры и графики. | LLD |
| Item prototype | Заготовка item для каждой найденной сущности. | LLD, Теги |
| Trigger prototype | Заготовка trigger для каждой найденной сущности. Ошибка в prototype размножается на сотни объектов. | LLD, Требования к шаблонам |
| LLD filter | Фильтр, ограничивающий, какие найденные сущности создавать. Без фильтров LLD может создать мусор и нагрузку. | LLD, Anti-patterns |
| LLD lifecycle policy | Правила, что делать с исчезнувшими discovered objects: удалять, отключать, оставлять историю. | LLD, Требования к шаблонам |
| Discovered item/trigger | Конкретный item или trigger, созданный из prototype. | LLD, Теги |
| Macro | Переменная Zabbix для порогов, URL, настроек шаблона и повторного использования. | Многоуровневая модель, Требования к шаблонам |
| Value mapping | Преобразование числовых/строковых значений в понятные статусы. Критично для шаблонов и trigger expressions. | Требования к шаблонам, examples/triggers |
| Preprocessing | Подготовка данных item перед хранением и вычислением триггеров: JSONPath, regex, преобразования, зависимые элементы данных. | Требования к шаблонам |
| Dependent item | Item, который получает значение из master item через preprocessing. Удобно для API/JSON и тяжёлых запросов. | Требования к шаблонам |
| UserParameter | Пользовательский ключ агента Zabbix, который запускает локальный скрипт или команду. | Требования к шаблонам, examples/userparameters |
| Trigger expression | Выражение Zabbix, определяющее PROBLEM/OK. Должно быть валидировано под реальные item keys и версии Zabbix. | Требования к шаблонам, examples/triggers |
| Runbook URL | Ссылка на инструкцию, хранящаяся в поле Menu entry URL триггера; в уведомлениях доступна через макрос {TRIGGER.URL}. |
Severity, Runbooks, Многоуровневая модель |
Архитектура и развёртывание¶
| Термин | Коротко | Где читать |
|---|---|---|
| Zabbix server | Центральный компонент, который принимает данные, считает trigger, хранит конфигурацию и управляет событиями. | Архитектура, ADR deployment |
| Zabbix frontend | Веб-интерфейс Zabbix. Может жить вместе с server или отдельно. | Архитектура, ADR deployment |
| Zabbix proxy | Промежуточный сборщик для площадок, DMZ, удалённых сегментов и OT-граничных зон. Даёт буферизацию и снижает связность. | Архитектура, Roadmap |
| Active proxy | Proxy сам отправляет данные на server. Часто удобнее для firewall и удалённых площадок. | Архитектура, ADR deployment |
| Active agent | Агент сам забирает список проверок и отправляет данные. Удобен для сегментированных сетей. | Архитектура, ADR agent mode |
| Passive agent | Zabbix server/proxy сам опрашивает агента. Требует доступности агента по сети. | ADR agent mode, Roadmap |
| PSK | Pre-shared key для TLS-шифрования соединений агента/proxy. Практичный минимальный уровень безопасности. | Roadmap, ADR agent mode |
| TLS-сертификаты | TLS (Transport Layer Security) с сертификатами — более строгая модель шифрования, обычно требует внутреннего CA и зрелой эксплуатации сертификатов. | Roadmap, ADR agent mode |
| CA | Certificate Authority — удостоверяющий центр, выпускающий TLS-сертификаты. Требуется при шифровании соединений агента/proxy через TLS с сертификатами. | Roadmap, ADR agent mode |
| DMZ | Demilitarized Zone — сегмент между доверенными и недоверенными зонами. Часто место для proxy или интеграционных точек. | Архитектура, Implementation Playbook |
| DC | Data Center — площадка или здание, где размещена инфраструктура. В тег-схеме используется как значение тега location (например, dc-main, dc-dr). | Теги, Архитектура |
| DR | Disaster Recovery site — резервная площадка для аварийного восстановления. В тег-схеме: env=dr, location=dc-dr. Связан с метриками RPO/RTO. | Теги, Roadmap |
| OT | Operational Technology: промышленный контур, где активное вмешательство и сканирование могут быть опасны. | Манифест, Архитектура, Implementation Playbook |
| SCADA | Системы диспетчерского управления и сбора данных. В книге рассматриваются как осторожный, часто read-only контур мониторинга. | Манифест, Архитектура, Требования к шаблонам |
| КИИ | Критическая информационная инфраструктура. В книге важна как архитектурное ограничение: нельзя «просто поставить агент». | Манифест, Архитектура |
| ЗОКИИ | Значимый Объект Критической Информационной Инфраструктуры. Объект КИИ, которому присвоена категория значимости (1–3) по 187-ФЗ. Определяет требования к защите, аудиту и согласованию изменений, включая установку агентов мониторинга. | Манифест, Архитектура |
| Read-only monitoring | Модель мониторинга без установки агента и без выполнения команд на целевой системе. Конкретные методы (ICMP/TCP, SNMP, read-only API) остаются активными проверками и согласуются с ИБ/владельцем отдельно. | Архитектура, Требования к шаблонам |
| Passive discovery | Обнаружение через пассивный анализ трафика или read-only источники, особенно в OT/SCADA. | Roadmap, Implementation Playbook |
| HA | High availability — высокая доступность. Полезна, но не исправляет плохую модель тегов, шаблонов и реакции. | Архитектура, ADR deployment |
| PostgreSQL для Zabbix | Часто предпочтительный выбор для зрелой/крупной инсталляции при наличии компетенций: хорошо работает с партиционированием и контролем history/trends. | Архитектура, Roadmap |
| Partitioning | Партиционирование таблиц history/trends, чтобы БД не разрасталась в неуправляемый монолит. В Zabbix 6/7 с PostgreSQL возможны три подхода: ручное партиционирование, TimescaleDB (hypertables/compression) и штатный housekeeping — выбор зависит от NVPS и компетенций. | Roadmap, Anti-patterns |
| Housekeeping | Механизм очистки истории в Zabbix. В больших инсталляциях часто требует пересмотра: при TimescaleDB/партиционировании штатный housekeeping настраивается или отключается отдельно. | Roadmap, Операционка |
| History | Сырые значения метрик за короткий/средний период. | Roadmap, ADR retention |
| Trends | Агрегированные значения для долгосрочного хранения и отчётности. | Roadmap, ADR retention |
| NVPS | New values per second: поток новых значений в Zabbix. Важен для оценки нагрузки на server и БД. | Roadmap, Implementation Playbook |
| Sizing | Оценка нагрузки, ресурсов, БД, proxy, history/trends, LLD и числа проверок до внедрения. | Implementation Playbook, ADR retention |
| Планирование ёмкости (Capacity planning) | Регулярное прогнозирование ресурсов: диски, CPU, лицензии, БД, каналы, рост числа items. | Операционка, Дашборды |
Эксплуатация, runbooks и отчётность¶
| Термин | Коротко | Где читать |
|---|---|---|
| Runbook | Пошаговая инструкция «что делать, если сработал этот конкретный алерт». Не архитектурная статья и не общий мануал. | Runbooks, Severity |
| TL;DR runbook | Первые строки runbook, которые закрывают 80% ночных случаев и читаются в стрессе. | Runbooks, Манифест |
| Runbook coverage | Доля алертов High/Disaster, у которых есть рабочая ссылка на runbook. | Runbooks, Дашборды |
| Known error | Известная проблема с описанным обходным способом или устойчивым способом диагностики. | Runbooks, Архитектура |
| Postmortem | Разбор инцидента после восстановления: хронология, первопричина, влияние, задачи. | Архитектура, Операционка |
| Blameless postmortem | Постмортем без поиска виноватого: цель — улучшить систему, runbooks, пороги, шаблоны и процессы. | Архитектура, Операционка |
| Задача / Пункт плана (Action item) | Конкретное улучшение после инцидента: владелец, срок, проверяемый результат. | Операционка, Implementation Playbook |
| Maintenance window | Плановое окно, в котором часть уведомлений подавляется или меняет правила реакции. | Операционка, Теги |
| Календарь заморозки (Freeze calendar) | Периоды, когда изменения запрещены или ограничены: закрытие месяца, производственный пик, годовой баланс. | Операционка, SLA |
| Change request | Формальная заявка на изменение, часто связанная с maintenance window и ServiceDesk. | Операционка, GitOps |
| ServiceDesk / ITSM | Система учёта инцидентов, изменений и SLA. Zabbix создаёт сигнал, ITSM хранит процесс. | Roadmap, Implementation Playbook |
| ITIL | Information Technology Infrastructure Library — набор практик по управлению ИТ-услугами. В книге — ориентир для incident management, change control, SLA и сервисного каталога. | SLA, Операционка |
| CMDB | Configuration Management Database — база данных конфигурационных единиц инфраструктуры. Zabbix может выступать источником данных для CMDB или синхронизироваться с ней через API. | Implementation Playbook, Roadmap |
| Ticket | Запись инцидента или задачи в ITSM. Не все алерты должны становиться тикетами. | Теги, Roadmap |
| Auto-close | Автоматическое закрытие или перевод тикета при событии восстановления. Требует аккуратной интеграции. | Roadmap, Операционка |
| SLA | Service Level Agreement: договорённость с бизнесом о доступности или качестве сервиса. Нельзя подписывать без данных. | SLA, Манифест |
| SLO | Service Level Objective: внутренняя цель ИТ-функции, часто предшествует SLA. | SLA, Roadmap |
| SLI | Service Level Indicator: конкретная измеряемая метрика, из которой считается SLO/SLA. | SLA, Roadmap |
| OLA | Operational Level Agreement: договорённость между ИТ-командами. | SLA |
| UC | Underpinning Contract: договор с внешним поставщиком, поддерживающий SLA. | SLA |
| Service hours | Часы, в которые сервис обязан работать по SLO/SLA. Без них процент доступности бессмыслен. | SLA |
| Maintenance exclusion | Исключение плановых работ из расчёта SLA, если это согласовано заранее. | SLA, Операционка |
| MTTR | Mean Time To Recovery/Repair: среднее время восстановления после инцидента. | Дашборды, Операционка |
| MTBF | Mean Time Between Failures: средний интервал между сбоями. | Дашборды, Операционка |
| RPO | Recovery Point Objective: допустимая потеря данных по времени. Важен для мониторинга резервного копирования. | Операционка, SLA |
| RTO | Recovery Time Objective: целевое время восстановления сервиса. | Операционка, SLA |
| Dashboard | Витрина мониторинга для конкретной аудитории и действия. Не «все графики на одном экране». | Дашборды, Anti-patterns |
| NOC dashboard | Экран для дежурного: что горит сейчас, что подтверждать, куда эскалировать. | Дашборды, Операционка |
| Per-service dashboard | Дашборд одного бизнес-сервиса, фильтруемый по service= и смежным тегам. |
Дашборды, Теги |
| Executive dashboard | Представление для руководства: статус сервисов, SLA, риски, без технического шума. | Дашборды, SLA |
| Report | Периодическая сводка: ежедневная сводка NOC, еженедельная операционная сводка, месячный SLA, квартальная ёмкость. | Дашборды, Операционка |
| Аудитория (Audience) | Конкретный пользователь дашборда или отчёта. Без аудитории дашборд становится шумом. | Дашборды |
| Refresh rate | Частота обновления дашборда/отчёта. Для NOC и CIO нужны разные скорости. | Дашборды |
Проект, GitOps и управление изменениями¶
| Термин | Коротко | Где читать |
|---|---|---|
| Discovery | Фаза инвентаризации: что есть, что мониторится, где зоны непокрытия, кто владельцы, какие события шумят. | Roadmap, Implementation Playbook |
| Пробел / Зона непокрытия (Gap) | Разрыв между тем, что должно мониториться, и тем, что реально покрыто. | Roadmap, Implementation Playbook |
| Coverage | Доля хостов, сервисов или проверок, покрытых мониторингом и обязательными тегами. | Roadmap, Дашборды |
| MVP | Minimum Viable Product: минимальный объём внедрения, который уже даёт проверяемую эксплуатационную пользу. В книге это не «черновик», а первая управляемая версия с владельцами, тегами, runbooks и понятными критериями приёмки. | Implementation Playbook, Roadmap |
| Pilot | Ограниченное внедрение на выбранном сервисе/площадке для проверки модели до rollout. | Roadmap, Implementation Playbook |
| Rollout | Раскатка изменений волнами после pilot. | Roadmap, Implementation Playbook |
| Wave | Одна волна rollout: ограниченный набор хостов/сервисов/шаблонов с проверкой после изменения. | Implementation Playbook, Roadmap |
| Phase gate | Контрольная точка между фазами внедрения: что принято, что измерено, что нельзя тащить дальше. | Implementation Playbook, examples/project |
| Передача в эксплуатацию (Handover) | Передача мониторинга в штатную эксплуатацию: роли, runbooks, дашборды, процессы, ответственность. | Implementation Playbook, Roadmap |
| Operations Handbook | Итоговый эксплуатационный документ: архитектура, процессы, runbooks, эскалация, передача в эксплуатацию, регулярные операции. | Roadmap, Операционка |
| ADR | Architecture Decision Record: запись архитектурного решения, вариантов, последствий и критериев пересмотра. | Implementation Playbook, examples/decisions |
| Decision log | Журнал решений: показывает статус ADR — что предложено, что принято и когда пересмотр. | examples/project, Implementation Playbook |
| RACI | Матрица ответственности: Responsible, Accountable, Consulted, Informed. | Implementation Playbook, examples/project |
| Acceptance checklist | Список критериев, по которым внедрение можно принимать, а не просто считать «настроенным». | Implementation Playbook, examples/project |
| GitOps для Zabbix | Подход к контролю конфигурации через Git, export/import, проверку изменений, поиск расхождений и частичную автоматизацию. | GitOps, ADR change control |
| CI/CD | Continuous Integration / Continuous Delivery — практика непрерывной интеграции и доставки. В контексте книги: автоматизированная проверка, тестирование и экспорт/импорт конфигурации Zabbix через pipeline. | GitOps, Implementation Playbook |
| Export/import | Минимальный способ версионировать Zabbix-конфигурацию: экспортировать YAML/XML, хранить в Git, импортировать изменения. | GitOps, Roadmap |
| Drift | Расхождение между тем, что хранится в Git/стандарте, и тем, что реально находится в Zabbix UI. | GitOps, Операционка |
| Drift detection | Регулярная проверка расхождений между Git/export и живой конфигурацией Zabbix. | GitOps, Implementation Playbook |
| Change control | Процесс, который определяет, кто и как меняет production-мониторинг, как фиксируется причина и как откатываться. | GitOps, ADR change control |
| Rollback | Возврат к предыдущей рабочей конфигурации после неудачного изменения. | GitOps, Roadmap |
| PR/review | Pull request и его проверка перед применением: шаблоны, схема тегов, действия уведомлений, дашборды, отчёты. | GitOps, Implementation Playbook |
| Auto-registration | Автоматическое добавление новых agents/hosts в Zabbix. Полезно, но опасно без схемы тегов и правил групп. | Roadmap, GitOps |
| HostMetadata | Строка метаданных агента для auto-registration и первичной классификации host. | Теги, Roadmap |
| Retagging | Приведение существующих hosts/items/triggers к новой tag schema. | Теги, Implementation Playbook |
| Production-ready | Готовность к production: не только работает в тесте, но имеет ответственность, теги, runbooks, маршрутизацию, откат и мониторинг влияния. | README, Implementation Playbook |
| Lab-tested | Проверено в лаборатории, но требует проверки на реальной инфраструктуре и данных. | README, scripts |
| Design draft | Концептуальный черновик: полезен как ориентир, но требует адаптации и валидации в конкретной среде. | README, examples |
| Requirements only | Требования и дизайн, а не готовый импортируемый шаблон. | Требования к шаблонам, README |
Предметные сокращения и контуры¶
| Термин | Коротко | Где читать |
|---|---|---|
| 1С | Критичный бизнес-сервис в примерах книги: rphost, HASP, веб-публикация, MSSQL/PostgreSQL, синтетика. | Сервис, а не хост, Требования к шаблонам |
| HASP | Hardware Against Software Piracy — аппаратный ключ лицензирования 1С. Исчерпание лицензий может быть пользовательским impact, а не просто технической метрикой. | Сервис, а не хост, Требования к шаблонам |
| rphost | Рабочий процесс 1С. Падение одного процесса и падение всех процессов имеют разный impact и severity. | Требования к шаблонам, Сервис, а не хост |
| rac | Консольная утилита администрирования кластера 1С:Предприятия. В книге используется для проверок доступности кластера, очередей, сеансов и рабочих процессов 1С через UserParameter/скрипты. | Требования к шаблонам, Implementation Playbook |
| MSSQL | Частая СУБД под 1С/Exchange/приложения: блокировки, взаимные блокировки, возраст резервной копии, tempdb, сессии. | Требования к шаблонам, Многоуровневая модель |
| PostgreSQL | БД Zabbix или прикладная БД; в Zabbix-контуре важны partitioning, retention, trends/history. | Архитектура, Roadmap |
| Exchange | Пример сервиса, который проверяется не только health БД, но и синтетикой отправки/получения почты. | Сервис, а не хост, Требования к шаблонам |
| DAG | Database Availability Group — группа высокой доступности баз данных Exchange. В шаблонах проверяются состояние реплик, очереди и синтетика отправки/получения. | Требования к шаблонам, Сервис, а не хост |
| Veeam | Пример системы резервного копирования: возраст последнего успешного бэкапа важнее простого статуса задания. | Операционка, Требования к шаблонам |
| UserGate | Пример сетевого/ИБ-компонента, где важны интерфейсы, VPN, политики, доступность. | Требования к шаблонам, Roadmap |
| OPC | Open Platform Communications (исторически OLE for Process Control) — интерфейс/протокол в промышленном контуре; мониторинг требует осторожности и согласования с SCADA/ИБ. | Требования к шаблонам, Архитектура |
| HMI / PLC | Human-Machine Interface / Programmable Logic Controller — компоненты промышленного контура. Мониторинг — пассивный или через OPC/SNMP, строго read-only, согласуется с ИБ и владельцем SCADA. | Архитектура, Требования к шаблонам |
| SPAN | Switch Port Analyzer / port mirroring: зеркалирование трафика с одного или нескольких портов коммутатора на порт анализа. В книге имеется в виду источник копии трафика для пассивного OT/ICS discovery и DPI-систем. | Архитектура, Roadmap |
| SNMP | Simple Network Management Protocol — базовый способ мониторинга сетевого оборудования, UPS, PDU, части железа. | Архитектура, Требования к шаблонам |
| UPS / PDU | Источник бесперебойного питания / блок распределения питания. Мониторятся через SNMP: уровень заряда, нагрузка, статус батареи, входное/выходное напряжение. | Архитектура, Требования к шаблонам |
| IPMI / iLO / iDRAC | Intelligent Platform Management Interface (общий стандарт) / Integrated Lights-Out (HPE) / Integrated Dell Remote Access Controller (Dell) — каналы мониторинга железа: питание, температура, RAID, аппаратные события. | Сервис, а не хост, Архитектура |
| DNS health | Синтетическая или компонентная проверка разрешения ключевых имён. | Roadmap, Сервис, а не хост |
| AD / Kerberos | Active Directory / протокол Kerberos. Инфраструктурный сервис, который часто требует синтетической проверки входа и получения ticket, а не только ping контроллера домена (Domain Controller, DC — не путать с Data Center). | Roadmap, Сервис, а не хост |
| DFS / файловые шары | Distributed File System и файловые ресурсы. Пример сервиса, где важно проверять пользовательский путь чтения/записи, а не только доступность сервера. | Сервис, а не хост, SLA |
| P1/P2/P3/P4 | Классы критичности или приоритета, часто используются в service catalog и ITSM. Не равны автоматически Zabbix severity. | Roadmap, SLA |