Антипаттерны Zabbix в крупной инфраструктуре: каталог базовых граблей

Две сцены, которые видел в разных компаниях в последний год.

Сцена первая. На стене в кабинете директора по ИТ висит большой телек, на нём дашборд: «Availability 99.83%», зелёные плашки, всё хорошо. В этот же момент этажом ниже бухгалтерия пишет в поддержку: «1С зависла, не можем закрыть смену». Дашборд не врёт — 99.83% хостов реально доступны. Просто из этих хостов 78 — тестовые стенды, 12 — резервные узлы, и ещё пачка в SCADA-сегменте, который вообще про другое.

Сцена вторая. Заходишь в Zabbix новой компании после предыдущего админа. Четыре тысячи хостов, двенадцать тысяч триггеров, средний возраст триггера три года. Runbook’ов нет. У всего severity High. Алерты падают в один телеграм-чат на пятьдесят человек, который дежурный молча мьютит первым делом после прихода на смену.

Если хоть одна сцена узнаваемая — статья для вас. Это попытка структурировать ошибки, на которых ломается большинство Zabbix-инсталляций в крупных компаниях с 1С, Exchange, SCADA, legacy-Windows-стеком и КИИ-сегментами.

Это не учебник и не пошаговая инструкция — каталог граблей из практики работы с крупной разнородной инфрой: 1000+ хостов, 1С, SCADA, КИИ-сегменты, legacy Zabbix от предшественников. На облачной 20-хостовой инсталляции половина пунктов будет избыточна. Конкретные пороги (CPU > 85%) — отправная точка, не догма. Если текст расходится с реальностью — побеждает реальность.

❌ «Поставить Zabbix и забыть»

Самый частый и самый дорогой антипаттерн. Логика обычно такая: «у нас же есть Zabbix» — и на этом всё.

Тут есть нюанс. Zabbix — это инструмент, не мониторинг. Мониторинг — это процесс, в котором инструмент только один из элементов. Если упростить, цикл выглядит так:

сбор → хранение → корреляция → визуализация → алертинг →реагирование (runbook) → постмортем → обратно в шаблоны

Из практики: чаще всего отваливаются последние два звена. Реагирование без runbook’ов, постмортемы без обратной связи в систему. Поговорили, поплакали, разошлись — и через два месяца тот же инцидент. У меня самого пару лет назад был кейс, когда мы три раза подряд ловили одну и ту же поломку MSSQL, и только на четвёртом постмортеме я заметил, что мы вообще не меняем шаблоны после разборов. Просто пишем красивые документы в Confluence.

Если у вас постмортемы не приводят хотя бы к одному изменению в системе мониторинга — это не постмортемы, это терапия.

❌ Дашборд для CIO на основе доступности хостов

Возвращаюсь к сцене из начала статьи. Зелёный дашборд, упавшая 1С, рассерженный финдир.

Что здесь происходит технически: дашборд показывает то, что Zabbix умеет показывать «из коробки» — статус хостов по ICMP. CIO смотрит на эту картинку и хочет увидеть «работает ли бизнес». Это два разных мира, между которыми никто не построил мост.

Дашборд для бизнеса должен быть про бизнес-сервисы, не про хосты. Список из сервисного каталога (1С УПП, корпоративная почта, файловые шары, CRM, ВКС), для каждого — текущий статус (работает / деградировал / лежит) и аптайм за период. Деградации привязаны к инцидентам. Никаких CPU, дисков и сетевых интерфейсов — это уровень дежурной смены, а не директора.

Технически в Zabbix это реализуется через модуль Services (он же IT Services / Business Service Monitoring). Сервис собирается из триггеров нижнего уровня по правилам, и на дашборд выводится агрегированный статус, а не сырые метрики. Чтобы это работало, нужна нормальная схема тегов. Условный минимальный набор:

service:      1c-erp        # бизнес-сервис из каталогаcomponent:    app-server    # роль внутри сервисаenv:          prod          # средаcriticality:  P1            # уровень критичностиowner:        it-apps       # ответственная командаlocation:     dc-main       # площадкаsegment:      it            # сегмент: it / ot / dmz

По таким тегам строятся actions, дашборды и фильтрация — без них никакой Services не поможет, потому что не из чего агрегировать. О схеме тегов отдельно — на ней многое держится.

❌ Тег criticality=critical на половине хостов

Классика инфляции значений. Если 50% хостов помечены «критичными» — это не означает, что у вас всё критичное. Это означает, что у вас нет калибровки, и тег ничего не различает. У меня в одном проекте мы провели аудит и обнаружили, что criticality=critical стоит на 62% хостов, включая тестовые контроллеры домена и хост, который вообще никто не помнил, зачем поднимали.

Рабочая калибровка для P1/P2/P3 примерно такая:

P1 — уровень бизнес-сервиса. Если лежит — компания теряет деньги или нарушает обязательства. Это узкий список, 5–15% хостов, не больше.
P2 — деградация без полной остановки. Резервные узлы, второстепенные сервисы, инфраструктурные компоненты с горячим резервом.
P3 — техническое внимание. Тестовые стенды, утилитарные сервисы, всё, без чего можно прожить день.

И отдельно про схему. Без зафиксированных разрешённых значений каждого тега через полгода у вас будет service=1c, service=1C, service=1с, service=erp — всё это про одну систему. После такого ни фильтры, ни дашборды, ни RBAC не работают. Простое правило: новый тег и новое значение проходят через ревью, как код. Это занудно, но иначе никак.

❌ Алерты без runbook

Если Disaster уходит дежурному в три ночи без ссылки на инструкцию — дежурный гуглит. В лучшем случае находит чужой StackOverflow с пятилетним рецептом. В худшем — звонит вам.

Я для себя сформулировал правило, которое экономит сотни часов:

Нет runbook’а — нет алерта в severity Disaster/High. Понизить severity или удалить триггер.

Технически — пишите URL прямо в описание триггера через макрос {TRIGGER.URL}. Сам runbook кладите туда, где дежурный его найдёт в три ночи: Bookstack, Wiki со стабильной структурой, что угодно, что переживёт увольнение того, кто это писал. TL;DR в первых трёх строках runbook’а закрывает 80% ночных вызовов — потому что в три ночи никто не читает простыни, читают первый абзац.

Чего точно не надо — страницы в Confluence «инструкция по 1С v2 final FINAL.docx», которая лежит в OneDrive у уволенного админа. Видел такое больше раз, чем хотелось бы.

❌ «Зелёный backup job = бэкап работает»

Тут поделюсь конкретной историей, потому что она показательная.

Веб-команда попросила восстановить версию файла двухнедельной давности — простой запрос, обычное дело. Идём смотреть бэкапы: Veeam рапортует success всю неделю, всё зелёное. Открываем репозиторий — а самой свежей точке три дня. Почему так? Неделей раньше кто-то сократил retention с 30 до 7 дней (была инициатива по экономии места), потом забыли, никто не следил. Job делал ровно то, что ему говорили: «забэкапь то-то и подчисти старое». Он подчистил.

Файл, кстати, нашли — но в архивной копии, к которой пришлось получать отдельный доступ. И вот тогда я понял, что зелёный job — это статус задачи, не статус резервной копии. Разные вещи.

С тех пор мониторю не job, а:

возраст последнего успешного восстановимого бэкапа по каждому защищаемому сервису;
раз в N дней — тестовое восстановление (хоть отдельной VM из бэкапа) с записью результата в метрику;
storage capacity репозитория с прогнозом на горизонт retention.

Третий пункт особенно полезен — он предупреждает о проблеме за месяц, а не в день инцидента.

❌ Тяжёлые UserParameter «напрямую»

Очень частый паттерн: «напишем UserParameter, который дёргает rac session list / парсит PowerShell-логи / делает SQL-запрос на двести строк». Через неделю в метрике ZBX_NOTSUPPORTED, флап, дежурный мьютит.

Проблема — таймаут агента. По умолчанию три секунды, на практике поднимают до тридцати, и это уже плохо. Любая операция, которая не укладывается, ломает сбор. А rac session list на 1С с пятьюдесятью базами и тысячей сессий — это легко десять секунд в плохой день.

Как делать правильно:

Cron + JSON. Скрипт раз в одну-две минуты собирает всё нужное в JSON-файл на диске. UserParameter читает файл, JSONPath раскладывает значения через dependent items. Один лёгкий вызов вместо десяти тяжёлых. Это, кстати, ещё и снижает нагрузку на источник — rac session list сам по себе тяжёлый.
zabbix_sender / trapper. Скрипт сам пушит метрики асинхронно, когда они готовы. Полезно для очень длинных операций, типа парсинга часового лога или обхода кластера.

Принцип общий: тяжёлая работа — вне таймаута агента.

❌ Grafana как второй центр алертинга

Тут предсказываю холивар, поэтому сразу оговорюсь: у Grafana Alerting есть свои сильные стороны, и для cloud-native стека с Prometheus он работает отлично. Я не спорю с тем, что им можно пользоваться. Я говорю про конкретный класс инфраструктуры — Zabbix-centric среду, где Zabbix уже стоит и собирает основную часть данных.

В такой среде Grafana как второй центр алертинга — это путь к двум системам правды, которые рано или поздно разойдутся. Дежурный видит зелёный график в Grafana, но в Zabbix висит триггер. Кто прав? Или у вас одни и те же условия продублированы в двух DSL — что синхронизировать руками. Или эскалации, maintenance windows, RBAC и история инцидентов в Zabbix уже настроены, а в Grafana — отдельно и поверхностно, потому что её сильная сторона не в этом.

Где Grafana действительно бесценна — это слой представления поверх Zabbix-данных (через zabbix-grafana-plugin). Дашборды для команды, дашборды для бизнеса, ad-hoc исследования инцидентов. Я бы на этом и остановился, без перетягивания алертинга.

Это не «нельзя», это «зачем».

❌ «Алерт в Telegram-чат на 50 человек»

Ещё одна история. Однажды наблюдал, как в чат на шестьдесят человек один за другим приходят алерты по реальному инциденту с MSSQL — лагают коннекты, лезут таймауты, потом отваливается репликация. И — тишина. Никто не пишет «принял», никто не комментирует.

Через сорок минут позвонил руководитель отдела поддержки и спросил, почему 1С тормозит. Тогда и подняли архив чата. Все шестьдесят человек видели алерты. Просто каждый думал: «Это, наверное, не моё, БД-команда разберётся». БД-команда думала: «Это дежурный должен принять, у нас же дежурство». Дежурный — что это профильная команда. В итоге сорок минут никто не реагировал на падение прода.

Универсальный канал «всё в один чат» работает ровно до первого реального инцидента. Потому что:

все привыкли игнорировать (там же и шум, и информашки, и иногда мемы),
никто не знает, его ли это алерт,
дежурный не понимает, отреагировал ли уже кто-то.

Каналы должны быть узкоцелевыми и адресными. Канал дежурной смены — только P1/P2, с обязательным acknowledge. Канал профильной команды (БД / сеть / 1С / прикладные) — только её алерты. Эскалация на руководство — отдельная цепочка, не «крикнуть в общий чат». И отдельно — Major Incident Communication Plan: в момент падения 1С в 08:30 уже поздно думать, кто звонит ИТ-директору, кто пишет триста пользователям, кто фиксирует таймлайн. Это процесс, который пишется в спокойное время.

❌ «У них SRE — давайте и нам». «Prometheus, потому что модный»

Карго-культ из cloud-native, перенесённый на инфраструктуру с 1С, SCADA и Exchange-2016. С разной степенью успеха.

Про SRE. Большая часть гугловских практик придумана для веб-сервисов с автоскейлом, blue-green-деплоем и stateless-нагрузкой. На производстве с 1С и SCADA половина модели нерелевантна напрямую. Это не значит, что SRE «не работает» — это значит, что брать модель целиком как обязательную не нужно. Лучше разобрать на компоненты — runbook’и, постмортемы, error budgets, on-call ротации — и интегрировать в существующий процесс. Без манифестов.

Про Prometheus. Это прекрасный инструмент для Kubernetes и cloud-native. Для legacy Windows-инфры с 1С, Exchange, SCADA, SNMP-периметром и КИИ Zabbix чаще практичнее. Pull-модель Prometheus неудобна для сегментов с плохой связностью (а такие сегменты бывают на любой большой инфраструктуре), долгие исторические окна для SLA в Prometheus тоже не самая сильная сторона. Это не «Prometheus плохой». Это «не везде он лучший выбор».

И отдельная боль — distributed tracing на монолите. Если у вас в проде монолит и три старые VM, OpenTelemetry на каждый компонент не нужен. Хорошо настроенный Zabbix + Grafana + ELK закроет процентов девяносто пять задач. Остальные пять — это уже отдельные тулы под конкретные кейсы, не общая инфраструктура трейсинга.

❌ Подписывать SLA «c потолка»

«Давайте напишем 99.9% доступности, это вроде стандарт». Через квартал считаем — а вышло 99.4%, потому что patch tuesday, обрыв канала, плановое окно SCADA. Минус доверие, минус бонус, плюс конфликт с бизнесом, который теперь знает: ИТ-обещания можно делить на два.

Правило:

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

Три месяца — это минимум. Лучше шесть, но три — порог, ниже которого статистика откровенно неполная: вы не успели застать ни один квартальный пик, ни одно сезонное окно обслуживания, ни одно реальное падение. Соглашусь, что бизнес часто не готов ждать. В таком случае честнее подписать предварительный SLA с пометкой «по итогам Q+1 уточним» — чем потолочную цифру.

И ещё одно: внешний SLA (для бизнеса) должен быть слабее внутренних обязательств между ИТ-командами (OLA). Если бизнесу обещали 99.5%, то БД-команда сетевикам должна обещать 99.7%, а сетевики DC — 99.9%. Иначе при первом сбое подрядчика у вас нет запаса.

Что ещё встречается

Короче — те грабли, которые повторяются часто, но обычно достаточно одной строчки, чтобы спорить было не о чем:

Zabbix Agent внутрь SCADA / OT-сегмента без согласования с ИБ. Для АСУ ТП есть специализированные пассивные системы (PT ISIM, Kaspersky ICS for Networks, UDV DATAPK) — Zabbix решает другие задачи и не на этих уровнях.
Один Zabbix Server на всё. Прокси нужны не для масштаба, а для изоляции и устойчивости при обрывах канала.
Бизнес-смысл в host groups (1C-prod-warehouse-critical). Это не группа, это конкатенация тегов в имя. Группы — для RBAC, бизнес-смысл — в теги.
LLD без фильтров. Discovery всех services Windows или всех сетевых интерфейсов = десятки тысяч мусорных items. Фильтры обязательны, lifecycle-политика тоже.
Disaster на всё «плохое». rphost=0 при десяти rphost’ах — не Disaster, потому что бизнес-сервис ещё жив. Disaster — это «бизнес-сервис лежит», не «один из компонентов».
Чистить severity inflation в первый месяц. Перенастроите → переделаете шаблоны → опять переделаете. Сначала стандартизация, потом чистка.
nmap по всей инфре без согласования с ИБ. На предприятии с КИИ — короткий путь до неприятного разговора с СБ. Сегменты сканируем только в согласованных окнах.
Чистить базу Zabbix без партиционирования. При 4К хостов и минутном интервале таблицы history* спокойно разрастаются до сотен ГБ. TimescaleDB или нативные партиции — с первого дня.
Не мониторить сам мониторинг. Упал Zabbix Server → вы слепые → вы об этом не знаете, потому что Zabbix молчит. Self-monitoring плюс независимый внешний watchdog обязательны.
Принимать алерты без maintenance windows. Каждый patch tuesday — шквал ложных P1 и потеря доверия к алертам. Maintenance Windows должны быть процессом, привязанным к Change Request.
Постмортем без участия владельца сервиса. Починили технику, не починили процесс — инцидент повторится через месяц.
Поднимать Netbox / iTop «пока есть время» на онбординге. Это отдельный полугодовой проект. Для начала достаточно Excel + структурированной вики, CMDB — потом.

Резюме: 8 правил, которые закрывают 80% граблей

Думайте сервисами, не хостами. «1С работает» — это AS работает + SQL отвечает + публикация отдаёт логин + вчерашний бэкап восстановим.
Severity = действие, не цвет. Disaster — звоним. High — к утру. Average — тикет. Information — лог.
Tag schema — фундамент. Без зафиксированных тегов с разрешёнными значениями не будет ни RBAC, ни дашбордов, ни SLA.
Каждый Disaster имеет runbook. Прямо в {TRIGGER.URL}, с TL;DR в первых трёх строках.
SLA — после 3 месяцев данных, не до. Внешний SLA слабее внутреннего OLA.
Постмортем меняет шаблоны. Иначе зачем.
Дашборд для бизнеса — про сервисы, не про хосты. «99.8% доступности» — это не статус 1С.
Чистка severity inflation — после стандартизации, не до. Иначе делаете работу дважды.

Послесловие

Это пилотная заметка — выжимка из заметок, которые накопились за несколько проектов внедрения мониторинга в крупных инфраструктурах. Если зайдёт и в комментариях соберётся обсуждение — отдельно разберу tag schema (там оказалось больше нюансов, чем я думал на старте), runbook’и с реальными примерами, Zabbix Services для бизнес-дашбордов, и GitOps-подход к хранению конфигурации.

У каждого второго есть свой «зелёный бэкап, которого не было».

ссылка на оригинал статьи https://habr.com/ru/articles/1040166/