← вся теориятеория к собесу · Docker и Kubernetes

Инфраструктура сервиса: мониторинг и трейсинг

Наблюдаемость сервиса в проде

Сервис в проде - чёрный ящик, пока ты не сделал его наблюдаемым. Когда в три ночи растут ошибки, спасают не догадки, а телеметрия: логи, метрики, трейсы. На собесе middle-уровня спрашивают именно про эти три столпа и про то, чем мониторинг отличается от observability.

Разберём, что каждый столп отвечает, как устроены типы метрик Prometheus, зачем трейсы и correlation-id, и почему алертить надо на симптом, а не на каждую дрогнувшую цифру.

Три столпа и типы метрик

Логи - дискретные события с контекстом («что случилось»), метрики - числовые агрегаты во времени («сколько и как часто»), трейсы - путь запроса через сервисы («где затормозило»). Мониторинг проверяет заранее известные пороги; observability - свойство системы отвечать на вопросы, которые ты не заготовил, проваливаясь от симптома к причине.

В Prometheus (pull-модель: сервис отдаёт /metrics, сервер скрейпит) три базовых типа. Counter только растёт (события; смотрят rate()). Gauge - мгновенная величина вверх/вниз (активные коннекты, длина очереди). Histogram раскладывает наблюдения по бакетам, чтобы считать перцентили - p95/p99, потому что среднее прячет медленный хвост.

from prometheus_client import Counter, Histogram
REQS = Counter("http_requests_total", "", ["method", "route"])
LAT = Histogram("http_latency_seconds", "")

Трейсы, correlation-id, алерты

В микросервисах один запрос идёт через несколько сервисов, и чтобы увидеть, ГДЕ время, нужен распределённый трейс: каждый сервис создаёт спан, все спаны сшиты общим trace-id, контекст пробрасывается по вызовам. Тот же id (correlation/request-id) протаскивают в структурные (JSON) логи - тогда всю историю запроса собираешь по одному ключу.

Алерты вешают на симптом, который бьёт по пользователю (рост ошибок/латентности, сгорающий error budget по SLO), а не на каждую внутреннюю метрику. Иначе шум рождает усталость, и реальный инцидент проспят. И осторожно с метками: user_id в метке взрывает число временных рядов - высокая кардинальность идёт в логи/трейсы, а не в метрики.

SLO: service level objective

Как отвечать: «Почему для latency берут гистограмму, а не среднее?»

Потому что среднее прячет хвост: 99% быстрых запросов маскируют тот 1% медленных, который и злит пользователей. Гистограмма раскладывает задержки по бакетам, и из них считаются перцентили - p95 и p99 показывают, как плохо худшим запросам. Именно хвост, а не среднее, обычно определяет SLO и восприятие сервиса пользователем.

Ответ показывает, что человек думает о распределении и о пользовательском опыте, а не берёт первую попавшуюся агрегатную цифру.

На чём валят

−Метка высокой кардинальности (user_id, request_id) в метрике - взрыв временных рядов, Prometheus ложится.
−Смотреть среднюю задержку вместо p95/p99 - среднее маскирует медленный хвост.
−Путать Counter и Gauge: применять rate() к gauge или пытаться уменьшать counter.
−Алертить на всё подряд и на внутренние причины без влияния на пользователя - шум, важное проспят.

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.

#observability_monitoring1 / 5
В чём разница между мониторингом и наблюдаемостью (observability)?
A)Это полные синонимы, просто observability — более новое модное слово
B)Мониторинг ловит известное; observability — разбирать неизвестное
C)Мониторинг платный и облачный, а observability — только опенсорс-инструменты
D)Мониторинг работает лишь в проде, а observability включают исключительно на стадии тестирования
показать ответ и разбор
+B)Мониторинг ловит известное; observability — разбирать неизвестное
// разбор: Мониторинг проверяет заранее известные условия («CPU>80%», «5xx растут») и хорош, когда знаешь, что мерить. Observability — свойство системы, дающее по телеметрии отвечать на вопросы, которые не заготовил заранее: провалиться от симптома к причине через метки, трейсы и корреляцию. Одно не заменяет другое.
#observability_monitoring2 / 5
Для чего в приложении используют Sentry (или аналог)?
A)Хранение всех подряд info-логов приложения для последующего полнотекстового поиска
B)Постоянный замер CPU и памяти узлов кластера с построением графиков нагрузки
C)Сбор исключений со стектрейсом, группировкой и контекстом
D)Прогон тестов на каждый коммит и блокировку мержа при падении сборки в пайплайне
показать ответ и разбор
+C)Сбор исключений со стектрейсом, группировкой и контекстом
// разбор: Sentry — трекер ошибок: перехватывает необработанные исключения, шлёт стектрейс с локальным контекстом (переменные, релиз, пользователь, окружение), группирует одинаковые в одну проблему и дедуплицирует всплески. Это точечный инструмент под ошибки — не замена метрикам и не общий лог-склад.
#observability_monitoring3 / 5
Prometheus-клиент даёт типы Counter и Gauge. В чём разница?
A)Counter для целых чисел, Gauge — исключительно для дробных значений
B)Counter хранит историю всех значений, Gauge — только самое последнее без прошлого
C)Они взаимозаменяемы, выбор между ними влияет только на цвет линии на дашборде Grafana
D)Counter только растёт (события), Gauge — текущее значение вверх/вниз
показать ответ и разбор
+D)Counter только растёт (события), Gauge — текущее значение вверх/вниз
// разбор: Counter — монотонно растущий счётчик событий (запросы, ошибки), его нельзя уменьшать; смотрят обычно rate() — скорость роста. Gauge — мгновенная величина, которая ходит вверх и вниз (число активных соединений, длина очереди, температура). Перепутать типы — исказить графики и алерты.
#observability_monitoring4 / 5
Для latency HTTP-запросов берут Histogram, а не Gauge средней задержки. Почему?
A)Гистограмма даёт перцентили (p95/p99), среднее их прячет
B)Gauge не умеет хранить дробные значения задержки в миллисекундах
C)Histogram потребляет меньше памяти, чем один Gauge на всю задержку
D)Среднее по задержке потребовало бы хранить каждый запрос, что дороже гистограммы
показать ответ и разбор
+A)Гистограмма даёт перцентили (p95/p99), среднее их прячет
// разбор: Средняя задержка прячет хвост: 99% быстрых запросов маскируют 1% медленных, которые и злят пользователей. Histogram раскладывает наблюдения по бакетам, и из них Prometheus считает перцентили — p95/p99 показывают, как плохо «худшим» запросам. Именно хвост, а не среднее, обычно определяет SLO.
#observability_monitoring5 / 5
Запрос идёт через api-gateway → сервис заказов → сервис оплаты, и где-то тормозит. Что покажет, ГДЕ именно?
A)Логи одного шлюза — там видно полное время всех внутренних вызовов насквозь
B)Распределённый трейс: спаны сервисов по общему trace-id
C)Средняя загрузка CPU на узлах, по ней сразу ясно, какой сервис виноват в задержке
D)Счётчик общего числа запросов в минуту, из которого выводится узкое место в цепочке вызовов
показать ответ и разбор
+B)Распределённый трейс: спаны сервисов по общему trace-id
// разбор: Распределённый трейс сшивает путь одного запроса: каждый сервис создаёт спан со своим временем, все спаны связаны общим trace-id, а контекст пробрасывается по вызовам. На водопаде видно, какой участок съел время — это то, чего не дадут ни разрозненные логи, ни агрегатные метрики.

дальше

Теорию прочитали. Навык ставится повторением

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

Открыть тренажёр Вся тема: Docker и Kubernetes