Аудит покрытия мониторингом в Zabbix: как убедиться, что авария будет замечена

У большинства компаний, куда мы приходим, мониторинг уже есть. Стоит Zabbix, нарисованы дашборды, кто-то однажды настроил алерты. На вопрос «а мониторинг у вас есть?» отвечают «да» — и это правда. Проблема в том, что «мониторинг стоит» и «авария будет замечена» — это два разных утверждения, и между ними обычно лежит пропасть.

Дашборд бывает зелёным по самой скучной из причин: упавший узел в мониторинг просто не заведён, и потому «зелёный» по построению — за ним не следят вообще. Алерт бывает настроен, но канал его доставки идёт через то же оборудование, которое и упало. А иногда умирает сам сервер мониторинга — и не сообщает об этом, потому что сообщать физически нечем.

Всё, что ниже, мы делали руками — на своей же инфраструктуре, а не на клиентской. Так честнее: клиентские кейсы пришлось бы вычищать до неузнаваемости, а на своём хозяйстве можно называть цифры. Пересказа документации Zabbix не будет: она хорошая, и «как установить Zabbix» — тема, где в топе выдачи стоит сам вендор, и правильно делает. Будет ровно то, чего в ней нет: как убедиться, что мониторинг ИТ-инфраструктуры, который у вас уже стоит, реально поймает аварию. Инструмент при этом почти неважен — примеры мы приводим на Zabbix, но метод одинаково работает для Prometheus, Zabbix, PRTG или Nagios: проверяется не название системы, а то, что она сработает. Ниже — шесть способов, которыми зелёный экран нас обманывал, и метод, которым мы каждый из них ловили.

Чем аудит покрытия мониторингом отличается от самого мониторинга

Мониторинг отвечает на вопрос «что сейчас происходит с системой». Аудит покрытия отвечает на другой, более неудобный вопрос: «а всё ли, что важно, вообще под наблюдением, и сработает ли оповещение, когда важное сломается». Первое показывает состояние того, за чем следят. Второе проверяет сам периметр слежки — и именно на нём живут дыры, потому что настраивавший мониторинг человек по определению не заведёт в него то, о чём забыл или не знал. Дашборд не может подсветить собственную слепую зону. Аудит — это взгляд снаружи на то, чего дашборд не видит.

Что у нас работает: мониторинг на Zabbix 7.2 и Grafana

Чтобы было понятно, к чему относятся цифры дальше.

• Zabbix Server 7.2 на бэкенде MariaDB, отдельная небольшая виртуальная машина на Ubuntu Server (веб-морда — nginx + php-fpm). Патч-версии стека — в служебной шапке, для текста они не важны.
• Grafana поверх Zabbix как источника данных — то есть красивые дашборды рисует именно она, а собирает и хранит метрики Zabbix. Это важная деталь для всего текста: зелёная панель в Grafana — это отрисовка того, что ей отдал Zabbix, а не независимое суждение о здоровье системы.
• Инфраструктура смешанная и типовая для СМБ: гипервизор виртуализации, пара физических серверов, сетевое железо, хранилище NAS, IP-телефония, десяток сайтов на одном веб-сервере, вторая площадка (офис) со своим роутером.
• Оповещения — в мессенджер (Telegram; у кого-то это MAX) и резервным каналом на почту.
• Вся настройка Zabbix у нас — это код, а не клики в интерфейсе. Хосты, триггеры, правила оповещения заводятся скриптами через API. Зачем — отдельный раздел ниже; здесь важно, что благодаря этому аудит воспроизводим: его можно прогнать снова и получить тот же результат.

Аудит, о котором идёт речь, — это сквозная сверка 50 машин: что написано в документации против того, что фактически заведено и настроено в Zabbix. Не «посмотрели на дашборд», а построчно.

Способ 1. Узел не заведён — и потому «зелёный» по построению

Первое, что показывает честный аудит: там, где хост заведён, покрытие обычно плотное — а дыры не в глубине, а в охвате.

У нас с глубиной всё было хорошо. Где узел стоял в мониторинге, метрик снималось с запасом: на гипервизоре виртуализации — 713 метрик, на веб-сервере с 13 сайтами — 234. По таким числам легко решить, что мониторинг зрелый.

А потом сверяешь список хостов Zabbix со списком того, что реально крутится в стойке, — и находишь целый ряд узлов вне мониторинга вовсе: пограничный прокси-контейнер, вторую физическую ноду, контроллеры управления серверами (iDRAC и iLO — это встроенные контроллеры, которые видят железо сервера: температуры, блоки питания, память — даже когда сама операционная система лежит), сетевое хранилище, ядро сети дата-центра. Ни одна из этих железок не показывала на дашборде красный — потому что её на дашборде не было. Отсутствие метрики выглядит ровно как «всё хорошо».

Это ключевая ловушка зелёного экрана: он зелёный не там, где всё исправно, а там, где есть за чем следить. Про то, чего в мониторинге нет, экран не краснеет — он молчит.

Метод, которым это ловится, до обидного прост и не требует инструментов: взять список систем, без которых бизнес не работает, и сверить его со списком хостов в Zabbix — построчно, руками. Расхождение и есть слепая зона. Мы завели недостающее по SNMP (протокол опроса сетевого железа и контроллеров) — и, например, контроллер управления гипервизором сразу отдал 164 метрики железа, включая состояние модулей памяти. Всё это железо жило без наблюдения ровно до того дня, пока мы не сверили два списка.

Вопрос себе: возьмите список серверов, роутеров и сервисов, без которых компания встанет, и список хостов в вашем Zabbix. Совпадают? Контроллеры управления серверами (iDRAC/iLO), NAS, ядро сети, вторая площадка — они в списке хостов или их там нет?

Способ 2. Метрика собирается, а по ней ничего не сработает — и триггера доступности сайта нет

Заведённый хост и заведённый алерт — тоже разные вещи. Zabbix может исправно снимать с сервера семьсот метрик и не иметь ни одного правила, которое по этим метрикам кого-то разбудит.

Здесь у нас была самая громкая находка аудита. Оповещение в мессенджер уходило ровно по двум условиям: по одной группе узлов при высокой критичности и по одному типу событий (по метке). Всё остальное — молчало. Метрики собирались, графики рисовались, дашборд зеленел, но правило оповещения (в терминах Zabbix — action: «что сделать и кого известить, когда сработал триггер») на них не распространялось.

Что именно молчало: ядро дата-центра — гипервизор (с уже неисправной, к слову, памятью — контроллер это видел, но никто не смотрел), магистральный роутер, веб-сервер, телефония. И сам сервер мониторинга. Как мы сформулировали это по итогам аудита: если бы Zabbix умер, никто бы не узнал. В журнале архитектурных решений та же мысль записана строже — «Zabbix не может запейджить „я умер“» (перевод: не может отправить оповещение «я умер»). К этому вернёмся отдельно, это способ 4.

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

Нашли мы это на разборе конфигурации, а не на инциденте — оговорюсь честно, лежащих сайтов при зелёном экране в тот момент не ловили, нашли дыру раньше, чем она выстрелила. Закрыли за две рабочие сессии: одно правило оповещения на четыре группы (ядро ДЦ, телефония, веб, вторая площадка) при критичности High и выше — и тринадцать триггеров «сайт недоступен» там, где было ноль. С важной деталью: у триггера доступности стоит анти-флап — тревога поднимается только после трёх подряд неудачных проверок, а не по одной. Одиночный сбой пробы (моргнул DNS, дёрнулась сеть) не должен будить дежурного в три ночи, иначе алерты быстро научатся игнорировать — а это хуже, чем их отсутствие.

Честная оговорка, которую мы записали сразу: новое правило пейджит новые проблемы. Те, что уже висели открытыми на момент его создания, задним числом оно не разошлёт. Это свойство инструмента, а не наша забывчивость, — но знать о нём надо, иначе создашь правило и решишь, что раз тихо, то всё здорово.

Вопрос себе: сколько у вас правил оповещения и на какие группы хостов они распространяются? Отдельно: есть ли у вас триггер, который сработает, когда ваш публичный сайт перестанет открываться, — и когда он в последний раз проверялся?

Способ 3. Алерт настроен, но не доходит — а вы думаете, что доходит

Дальше начинается самое коварное. Допустим, триггер есть, правило оповещения есть, канал (в нашем случае бот в Telegram) настроен. Кажется, готово. Но между «Zabbix решил отправить» и «человек увидел сообщение» стоит цепочка из нескольких звеньев, и рвётся она молча.

Мы поймали это активной проверкой — и хорошо, что до аварии. Сквозной тест доставки показал: вся отправка оповещений в Telegram молча не работала. Не «иногда сбоила» — не работала вообще. Причин было две, и обе поучительные:

1. Рассинхрон после обновления. Канал доставки требовал параметр, которого в его настройке не было: скрипт-обработчик обновили, а список передаваемых ему параметров — нет. Zabbix честно писал в лог ошибку про «параметр не найден», но эту ошибку никто не читал — она же в логе, а не в мессенджере, до которого она как раз и не доезжала.
2. Блокировка на выходе. Сервер Telegram был недоступен из сети дата-центра напрямую. Оповещение упиралось в сеть и умирало.

Обе дыры такие, что снаружи неотличимы от тишины «всё спокойно». Именно поэтому доставку алерта нельзя проверять по конфигу — только по факту отправки. Мы сделали для этого отдельный скрипт, и это, пожалуй, главный переносимый приём всей статьи:

• скрипт создаёт временный триггер (искусственно вызывает состояние проблемы);
• ждёт, пока отработает правило оповещения (примерно две минуты);
• читает служебную таблицу отправок в базе Zabbix — там по каждому оповещению написано sent или failed и текст ошибки;
• и гарантированно удаляет временный триггер в блоке очистки — даже если сама проверка упала с ошибкой посередине. Иначе тестовый триггер останется висеть и будет слать ложные тревоги.

Важно, что этот тест проверяет всю цепочку — триггер → правило оповещения → канал → доставка, — а не только последнее звено. Проверить «бот отвечает на сообщение» недостаточно: бот может отвечать, а конкретно из Zabbix через конкретное правило сообщение не уйти.

После починки доставка как канал стала исправной: 46 успешных отправок против одной неуспешной за неделю (это срез за семь дней перед аудитом, а не общий счётчик — так и подаю). А потом механизм сработал в реальной аварии: когда отвалилась вторая площадка, триггер «офис пропал» отработал и дошёл — сначала «High: офис пропал», через двадцать минут «Восстановлено». Это уже не тест, а боевое подтверждение — и разница между «мы проверили, что доходит» и «мы надеемся, что дойдёт».

Вопрос себе: когда вы в последний раз получали от мониторинга тестовый алерт, который специально вызвали, и убедились по факту, что он дошёл на телефон дежурного? Если ответ «оно же работает, приходили же алерты» — вспомните, когда последний раз приходил хоть один, и не значит ли эта тишина, что доставка сломалась полгода назад.

Способ 4. Сам сервер мониторинга умер — кто сторожит сторожа

Это тот способ, ради которого стоит дочитать, если больше ничего не уносить.

Система мониторинга не может отправить оповещение «я умерла». Если падает она сама — или падает канал, по которому она шлёт алерты, — вы об этом не узнаете от неё по определению: сообщать нечем. Дашборд в такой ситуации не краснеет, он просто перестаёт обновляться — а последний кадр на нём был зелёный. Человек, глянувший мельком, увидит зелёный экран и успокоится.

Решение не внутри той же системы (изнутри её не решить в принципе), а снаружи. И вам не нужна наша точная схема — нужны три вещи: наблюдатель на другой площадке (в отдельном «домене отказа», который не заденет падение наблюдаемого); канал тревоги, который не проходит через наблюдаемый объект; и модель, где наблюдатель сам опрашивает объект (pull), а не ждёт от него сигнала «я жив» (push). Последнее важнее, чем кажется: если объект шлёт «я жив», то пропажа сигнала означает либо его смерть, либо просто обрыв канала между площадками — и вы не знаете что. При опросе снаружи логика чище.

Как это устроено у нас, коротко: сторож живёт в офисе, на другом здании и другом интернет-канале, раз в две минуты опрашивает всю цепочку дата-центра (публичный вход, веб-сервер мониторинга и сам процесс Zabbix — ему шлётся валидный запрос на его родном протоколе и проверяется ответ), бьёт тревогу напрямую со своего канала, минуя дата-центр, с резервом на почту и анти-флапом (тревога после трёх подряд аварийных циклов). Дата-центр, в свою очередь, сторожит офис отдельным сигналом — стороны караулят друг друга крест-накрест, ни одна не караулит сама себя.

А если площадка одна? Второй офис или ЦОД есть не у всех — и это не отговорка. Роль внешнего сторожа закрывает дешёвая облачная виртуалка за пару сотен рублей в месяц или любой хост вне вашего периметра: он так же раз в пару минут опрашивает вашу систему снаружи и бьёт тревогу по независимому каналу. Принцип «наблюдатель снаружи наблюдаемого» важнее, чем наличие второго здания.

Вопрос себе: если ваш сервер мониторинга выключить прямо сейчас — кто и через сколько минут об этом узнает? Если ответ «увидим, что дашборд не обновляется» — то кто на него смотрит в три ночи?

Способ 5. Порт открыт — это не значит, что сервис доступен

Пятый способ обмануться — проверять живость сервиса проверкой порта. «Порт открыт» и «через сервис реально что-то работает» — разные вещи, и разница эта не теоретическая.

Мы держали узел связи с многонедельным аптаймом: TCP-порт открыт, TLS-рукопожатие (обмен сертификатами при установке защищённого соединения) проходит, мониторинг зелёный. А данные через него не шли — блокировалась сама фаза передачи данных, уже после рукопожатия. Соединение устанавливается, дверь открывается — а комнаты за ней нет. Обычная проверка порта этого не видит по построению: она проверяет, что дверь открывается, а не что за дверью что-то есть. Узел мы в итоге вывели из эксплуатации — именно по вердикту сквозной пробы, а не по статусу порта.

Вот техническая деталь, на которой мы поймали сами себя и которую можно проверить у себя за минуту. Если между вами и целью стоит прозрачный туннель (а он есть много где — VPN, прокси), то простая проверка «открыт ли порт» — nc -z или через bash /dev/tcp — вернёт «открыто» даже для заведомо несуществующего адреса. Возьмите адрес 192.0.2.1 — он из диапазона 192.0.2.0/24, специально зарезервированного «для примеров и документации», он гарантированно ничей, — и проверьте на нём порт из-за туннеля. Получите «открыто». Локальный сетевой стек подтверждает соединение раньше, чем оно реально дотянется до цели. Ваша проверка порта врёт, и это можно увидеть за одну команду.

Отсюда правило: сквозная проба обязана прогнать настоящий трафик до внешней контрольной точки и получить осмысленный ответ. У нас проба возвращает задержку в миллисекундах (больше нуля — жив) или -1 (сквозной сбой). Именно -1 ловит мёртвую фазу передачи данных, которую проверки порта и рукопожатия пропускают.

Второй случай мы, наоборот, поймали на инциденте, а не на разборе. В офисе дважды коротко, по десять-пятнадцать секунд, проседал восходящий канал провайдера. Статус линка на роутере при этом не падал — по SNMP мониторинг не увидел ничего, а часть сайтов у сотрудников легла. Узнали от людей, а не от системы. Классический «дашборд зелёный, потому что мерили не то, что легло». Завели активную пробу: четыре метрики раз в тридцать секунд, отдельно потери наружу и отдельно до шлюза провайдера (чтобы предъявлять провайдеру факты, а не спорить), и главное — проба идёт тем же путём, что и трафик сотрудников. Не в служебный туннель, а туда же, куда ходят люди.

И сразу записали предел этой пробы — прямо в скрипте: тридцатисекундная проба может проскочить мимо десятисекундного провала. Она копит статистику частоты и будит дежурного на длительных обрывах, а мгновенные моргания честно может пропустить. Предел проверки мы называем вслух, а не прячем, — потому что «проба стоит» это опять не то же самое, что «проба поймает всё».

Вопрос себе: ваши проверки доступности — это открытый порт или реальный запрос с осмысленным ответом? И идёт ли проба тем же путём, что трафик ваших пользователей, — или коротким служебным маршрутом, на котором всё всегда хорошо?

Способ 6. Красный алерт тоже врёт — и его тоже надо сводить к фактам

Симметричная ошибка не менее опасна: поверить алерту, который врёт в другую сторону, и начать чинить то, что не сломано.

Заведя в мониторинг контроллер управления одним из серверов, мы первым же алертом получили «System status critical» (перевод: «критический статус системы»). Инстинкт — бежать. Разобрались — это оказалась не активная авария, а «защёлка» истории: контроллер держит критическим статус из своего журнала оборудования до ручного сброса, а в журнале висели старые, давно неактуальные записи — двойная потеря входного питания на обоих блоках (событие несколькими неделями ранее) и ещё более старые ошибки дискового массива. Активной аварии не было.

Как мы это установили — и есть метод: свели к фактам из независимых источников. Дисковые пулы — в статусе ONLINE, самодиагностика (SMART) всех дисков — PASSED. Значит, «критический статус» — это защёлкнутое эхо старого события, а не текущий отказ; сбрасывается сбросом контроллера, операционную систему не трогает. Правильный разбор — не выключить надоедливый алерт и не поверить ему на слово, а отличить активную аварию от исторической записи по независимым признакам.

Заодно всплыл настоящий вопрос на будущее — почему вообще было двойное пропадание входного питания. То есть красный алерт врал про «прямо сейчас всё горит», но не соврал полностью: в истории лежал факт, с которым стоит разобраться. Вот это и есть аккуратный разбор — и зелёный дашборд, и красный алерт нужно уметь свести к фактам, а не принимать ни один из них на веру.

Вопрос себе: когда у вас загорается критический алерт — вы проверяете его по независимому признаку, прежде чем действовать? И не отключили ли вы уже пару «вечно красных» алертов просто потому, что они надоели, — не разобравшись, что за ними стоит?

Настройка Zabbix у нас — это код, а не клики

Короткое отступление, которое объясняет, почему аудит вообще получился воспроизводимым. Всю конфигурацию мониторинга мы держим кодом: в репозитории лежит четырнадцать скриптов (около тысячи строк на Python), которые заводят хосты, триггеры и правила оповещения через API Zabbix. Скрипты идемпотентны — перед созданием проверяют, не существует ли объект уже, и не плодят дубликатов; повторный запуск ничего не ломает.

Что это даёт на практике: аудит повторяем (добавить тринадцать триггеров — один скрипт в истории изменений, а не тринадцать забытых походов по меню), результат проверяем (правило оповещения — код, который читают и ревьюят, а не галочки по вкладкам), а конфигурация восстановима — если мониторинг придётся поднимать заново, она приезжает из репозитория, а не собирается по памяти. Когда встаёт вопрос «а что у нас вообще заведено и почему», разница между „посмотрю в UI“ и „прочитаю в git“ — это разница между археологией и чтением.

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

Zabbix или Prometheus, при чём тут Grafana и как быть с Astra Linux

Вопрос про выбор системы всплывает всегда, поэтому отвечу — но честно помечу: это позиция, а не результат замера. Мы не гоняли Zabbix против Prometheus на одинаковой нагрузке и цифр сравнения не имеем.

Коротко, как мы это видим для сегмента СМБ. Zabbix — это готовая коробка «из одного места»: сбор метрик, хранение, триггеры, оповещения и инвентаризация в одной системе, с опросом железа по SNMP прямо из поставки. По SNMP Zabbix умеет опрашивать сетевое железо любых вендоров — и MikroTik, и отечественный Eltex, и контроллеры серверов, — а для смешанного парка «немного серверов, немного сетевого железа, телефония, пара площадок» это попадает в задачу точно. Prometheus силён в другом мире — динамические окружения, контейнеры, Kubernetes, где хосты появляются и исчезают, и метрики модель «сервис сам отдаёт свои показатели» описывает лучше. Такого мира у типичной компании на 30–200 человек обычно нет.

Grafana в этом раскладе — не конкурент ни тому, ни другому, а слой визуализации поверх. У нас она рисует дашборды, беря данные из Zabbix. И здесь стоит повторить мысль из начала статьи, потому что она прямо про инструмент: красивый зелёный дашборд в Grafana — это отрисовка того, что ей отдал источник. Grafana не знает, что какой-то узел не заведён в Zabbix; она нарисует ровно то, что есть, и пустое место будет выглядеть спокойно. Дашборд — это витрина, а не проверка.

Про Astra Linux и импортозамещение отвечу честно: наш стек стоит на Ubuntu Server, на Astra мы Zabbix в продуктиве не разворачивали и делать вид, что разворачивали, не будем. Но принципиально это ничего не меняет — Zabbix и его агент работают на Astra Linux, RED OS и других отечественных ОС так же, как на Ubuntu, а весь метод аудита из этой статьи от операционной системы вообще не зависит: сверка двух списков, проверка доставки фактом отправки, сторож снаружи и сквозные пробы одинаковы хоть на Astra, хоть на любом дистрибутиве.

Чего мы не делали

Раздел, которого обычно нет, а зря. Всё перечисленное ниже мы либо не разворачивали, либо сделали ограниченно — значит, выдавать это за отработанную практику не будем.

• Автоматических дашбордов «доступность за месяц» (SLA-отчётов) мы не выпускаем. История метрик есть, отчётной формы «сервис был доступен 99,x% времени» — нет. Если вам нужна такая отчётность по договору — это отдельная работа, которую мы честно не ставили на поток.
• Zabbix на Astra Linux / RED OS мы в продуктиве не разворачивали — работаем на Ubuntu. Что Zabbix там работает — знаем, но по своей практике на отечественных ОС не отчитываемся.
• Мы не делали инъекцию отказов (chaos engineering) — намеренное гашение узлов по расписанию. Мы проверяем реакцию на отказ наблюдением и разбором, а не тем, что специально всё ломаем в проде. Для парка СМБ без Kubernetes это, на наш взгляд, и не нужно, но раз не делали — не советуем с наших слов.
• Инструментальных сканеров (nuclei, trivy и подобных) в этом аудите не запускали. Покрытие мониторингом мы проверяли сверкой конфигурации, а не сканером.
• Отдельного правила, которое пейджит уже открытые проблемы задним числом, у нас нет — как честно сказано в способе 2, новое правило ловит только новые события. Это ограничение инструмента, мы его не обошли, а обошли организационно (разово прошлись по открытым вручную).
• Полноценного нагрузочного профиля самого Zabbix мы не снимали: на нашем масштабе (десяток активных хостов) сервер мониторинга работает с большим запасом, и вопрос «а выдержит ли Zabbix тысячу хостов» — не наш вопрос, и мы на него не отвечаем.

Чек-лист: что проверить у себя за час, без нас

Это можно сделать самостоятельно, сегодня, и это уже даст больше правды о состоянии дел, чем месяц разглядывания дашбордов.

1. Сверьте два списка. Список систем, без которых бизнес встанет, — и список хостов в Zabbix. Расхождение — ваша слепая зона. Особое внимание: контроллеры управления серверами (iDRAC/iLO), NAS, ядро сети, вторая площадка.
2. Найдите триггер доступности вашего сайта. Если публичный сайт перестанет открываться — сработает ли что-нибудь? Если триггера нет, сайт может лежать при зелёном экране.
3. Вызовите тестовый алерт и дождитесь его на телефоне. Не «бот отвечает», а именно сквозная тревога от Zabbix дошла до человека. Проверьте по факту доставки, а не по конфигу.
4. Выключите (или мысленно выключите) сам сервер мониторинга и спросите: кто и через сколько минут узнает? Если ответа нет — у вас нет сторожа над сторожем.
5. Проверьте, чем меряется доступность. Открытый порт или реальный запрос с ответом? И идёт ли проба тем же путём, что трафик пользователей?
6. Посчитайте, когда последний раз приходил хоть один алерт. Долгая тишина — это не обязательно «всё хорошо»; это ровно так же выглядит сломанная доставка.
7. Проверьте анти-флап на шумных триггерах. Если алерты дёргаются по одиночному сбою пробы, их скоро начнут игнорировать — и это опаснее, чем их отсутствие.

Ни один из этих шагов не требует бюджета — только несколько часов внимания и готовности увидеть неприятное. И повторяйте сверку после каждого расширения парка, а не один раз.

Выводы в четыре строки

1. Зелёный дашборд зелёный там, где есть за чем следить, а не там, где всё исправно. Аудит начинается со сверки охвата, а не с глубины метрик: про то, чего в мониторинге нет, экран не краснеет — он молчит.
2. Собирать метрику и оповещать по ней — разные настройки, а доставку алерта проверяют фактом отправки, а не конфигом. Цепочка триггер → правило → канал → человек рвётся молча в любом звене.
3. Над сторожем нужен сторож снаружи, а «порт открыт» ≠ «сервис работает». Сам сервер мониторинга не сообщит о своей смерти — нужен независимый наблюдатель на другом канале; а проба должна гонять реальные данные тем же путём, что трафик пользователей.
4. И зелёный экран, и красный алерт сводите к фактам, а настройку держите кодом. «Critical» бывает защёлкнутым эхом старого события; а когда конфигурация лежит в git, «что у нас заведено и почему» — это чтение, а не археология, и аудит можно повторить.