Мониторинг отвечает на вопросы, которые мы знали заранее: «жив ли сервис», «не кончается ли диск». Наблюдаемость (observability) это свойство системы, позволяющее по её внешним сигналам ответить на вопрос, который заранее никто не задавал: «почему у клиентов из Казани с Android медленно грузится корзина с 9 до 10 утра». Мониторинг ловит известные проблемы, наблюдаемость помогает разобраться с неизвестными.
Три сигнала
- Метрики: числа во времени (запросов в секунду, доля ошибок, загрузка CPU). Дёшево хранить, быстро агрегировать, идеально для алертов и трендов. Но детали теряются: метрика скажет, что 2% запросов падают, но не скажет, какие.
- Логи: события с деталями (кто, что, с какими параметрами, какая ошибка). Дорого хранить в объёме, зато есть контекст.
- Трейсы: путь одного запроса через все сервисы с длительностью каждого шага. Отвечают на вопрос «где именно тратится время».
Часто добавляют четвёртый сигнал, профили: на какие функции тратится CPU и память.
Сигналы ценны вместе: алерт по метрике, переход к трейсам медленных запросов (exemplars), из трейса к логам по trace_id.
Что мерить: три методики
RED для сервисов (запросы):
- Rate: запросов в секунду;
- Errors: доля или число ошибок;
- Duration: распределение времени ответа (перцентили).
USE для ресурсов (CPU, диск, сеть, пулы соединений):
- Utilization: доля времени, когда ресурс занят;
- Saturation: насколько работа ждёт ресурс (очередь, load average, ожидание пула);
- Errors: ошибки ресурса.
Четыре золотых сигнала из книги Google SRE: latency, traffic, errors, saturation. По сути RED плюс насыщение.
Практичное правило: для каждого сервиса дашборд RED на входе, для каждой зависимости (база, кеш, очередь) RED на исходящих вызовах, для узлов USE.
Белый и чёрный ящик
- White-box: метрики изнутри приложения (сколько запросов обработал, сколько ждал пул).
- Black-box: проверка снаружи, как это видит пользователь (синтетический запрос раз в минуту из нескольких точек,
blackbox_exporter).
Нужны оба: внутренние метрики могут быть идеальны, пока DNS или сертификат не дают пользователям даже дойти до сервиса.
Среднее врёт
Среднее время ответа 120 мс может скрывать, что 5% запросов идут 3 секунды. Задержку описывают перцентилями: p50 (медиана), p95, p99. Перцентили нельзя усреднять между серверами: p99 по кластеру не равен среднему из p99 узлов. Поэтому собирают гистограммы и считают перцентиль по суммарной гистограмме.
Кардинальность
Кардинальность это число уникальных комбинаций меток метрики. http_requests_total{method, status, route} при 5 методах, 10 статусах и 50 маршрутах даёт до 2500 рядов, это нормально. Добавьте метку user_id, и рядов станет миллионы: память Prometheus кончится. Высококардинальные данные (ID пользователя, заказа, запроса) место в логах и трейсах, а не в метках метрик.
Сколько это стоит
Наблюдаемость легко начинает стоить сопоставимо с самим продуктом. Рычаги: ретеншн (сколько хранить), сэмплирование трейсов, уровни логов, отказ от лишних меток, агрегирование старых данных до меньшей детальности.
Частые ошибки
- Алерты на каждую метрику, дашборд из 80 панелей.
- Среднее время ответа вместо перцентилей.
user_idв метках метрик.- Логи без
trace_id: нельзя связать с запросом. - Только внутренние метрики без проверки снаружи.
Что спросят на собесе
- Чем мониторинг отличается от наблюдаемости.
- Метрики, логи, трейсы: что когда использовать.
- RED, USE, золотые сигналы.
- Почему среднее время ответа плохая метрика.
- Что такое кардинальность и чем опасна.