Допустим:
filesystem usage = 98%
Метрика есть.
График есть.
Но trigger не настроен.
Получаем:
данные собираются
↓
проблема существует
↓
никто не уведомлён
Мониторинг технически работает.
Эксплуатационно — нет.
Шестая проблема: alert существует, но бесполезен
Обратный сценарий:
WARNING WARNING WARNING WARNING WARNING
десятки раз каждый день. Если большинство уведомлений не требуют действий, появляется alert fatigue — специалисты начинают воспринимать поток событий как фон. Поэтому важен не сам факт наличия trigger. Хорошее уведомление должно помогать ответить минимум на три вопроса:
Что произошло? Насколько это важно? Что делать дальше?
Седьмая проблема: мы контролируем компонент, но не зависимость
Например:
application → OK database → OK
Но приложение зависит ещё от внешнего сервиса:
application
↓
SMS gateway
или:
application
↓
external authentication provider
Если эта зависимость не контролируется, пользователи могут столкнуться с отказом, который наши dashboards вообще не объясняют. Поэтому полезно строить не просто список hosts, а карту зависимостей сервиса.
Восьмая проблема: есть метрики, но нет контекста
Например:
CPU = 85%
Это хорошо или плохо? Без контекста неизвестно. Для batch-сервера это может быть нормальным режимом работы. Для API-сервера рост:
20% → 85%
одновременно с:
response time ↑
может быть важным симптомом. Одна и та же цифра приобретает смысл только вместе с:
- — динамикой;
- — типом системы;
- — нагрузкой;
- — зависимостями;
- — ожидаемым поведением.
Что я бы проверял при оценке мониторинга системы
Не только:
«Добавлен ли сервер в Zabbix?»
А последовательно:
- Видим ли мы сам узел?
- Видим ли критичные компоненты?
- Проверяем ли работоспособность сервиса, а не только процессов?
- Видим ли ключевые зависимости?
- Контролируем ли пользовательский сценарий?
- Есть ли признаки деградации до полного отказа?
- Настроены ли уведомления?
- Получает ли их нужный человек?
- Можно ли по данным понять причину?
- Проверено ли, что monitoring действительно обнаруживает отказ?
Последний пункт особенно важен.
Мониторинг тоже нужно проверять отказом
Допустим, настроен trigger:
nginx unavailable
Но никто никогда не проверял:
остановить nginx
↓
получить problem
↓
получить notification
↓
восстановить nginx
↓
получить recovery
Тогда мы знаем лишь:
правило существует.
Но ещё не знаем:
работает ли вся цепочка обнаружения и оповещения.
trigger configured
≠
failure detectable
≠
notification delivered
Что считать хорошей наблюдаемостью
Не количество:
items graphs dashboards triggers
а способность системы мониторинга быстро ответить: Что сломалось? Где это произошло? Когда началось? Кого затронуло? Какая зависимость могла стать причиной? Насколько быстро ситуация ухудшается? Как проверить восстановление? Если данные позволяют отвечать на эти вопросы — мониторинг действительно помогает эксплуатации. Если нет — мы просто собираем много телеметрии.
Главное
agent available
≠
service monitored
metrics collected
≠
failure detectable
trigger exists
≠
engineer notified
dashboard exists
≠
system observable
Цель мониторинга — не собрать максимальное количество метрик. Цель — обнаружить существенное отклонение достаточно рано, дать контекст для диагностики и подтвердить восстановление системы.
Нужно спроектировать или проверить мониторинг инфраструктуры?
Выполняю аудит, диагностику и проектирование Zabbix-инфраструктуры, а также настройку и оптимизацию мониторинга.
Услуги на Kwork: https://kwork.ru/user/borib
#Разбор #Monitoring #Observability #Zabbix