Метрики, логи и трейсы

Три источника сигнала, у каждого своя работа и своя цена.

Три сигнала

Метрика — число во времени. Дёшево хранить, дёшево агрегировать, легко строить графики и алерты. Отвечает на вопрос «что-то не так и насколько».

Лог — запись о конкретном событии с контекстом. Дороже хранить, зато содержит детали. Отвечает на «что именно случилось».

Трейс — путь одного запроса через все сервисы с таймингами. Дороже всех. Отвечает на «где потратилось время».

Как это работает в инциденте

Порядок обычно такой:

1. Метрика показала: выросла доля 5xx.
2. Трейс показал: время уходит в сервисе платежей, на вызове внешнего API.
3. Лог показал: таймауты соединения с конкретным хостом.

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

Кардинальность — главная ошибка

У метрики есть метки: http_requests_total{method="GET", status="200"}. Каждая уникальная комбинация значений создаёт отдельный временной ряд.

Если добавить меткой ID пользователя или полный URL с параметрами, рядов станет столько же, сколько пользователей или уникальных URL. Хранилище метрик рассчитано на тысячи рядов, не на миллионы — рано или поздно оно ляжет, обычно в самый неподходящий момент.

плохо:  http_requests_total{path="/lessons/linux/what-is-linux"}
хорошо: http_requests_total{path="/lessons/:section/:lesson"}

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

Логи

Структурированные логи (JSON) заметно удобнее текстовых: по ним можно фильтровать, не подбирая регулярные выражения.

{"level":"error","msg":"payment failed","order_id":"4821","provider":"stripe","duration_ms":3021}

Полезные привычки:

• В каждую запись — идентификатор запроса, чтобы связать записи разных сервисов.
• Уровни используются осмысленно: error — то, на что нужно реагировать, а не «что-то пошло не совсем гладко».
• Никаких секретов, токенов и персональных данных: логи живут долго и доступны шире, чем база.

Что мерить в первую очередь

Для сервиса, отвечающего на запросы, минимальный полезный набор — четыре величины: количество запросов, доля ошибок, задержка (обязательно перцентили, не среднее) и насыщенность ресурса — то, что кончится первым: CPU, память, соединения к базе.

Среднее время ответа почти бесполезно: при 95% быстрых ответов и 5% десятисекундных среднее остаётся приличным, а каждый двадцатый пользователь видит зависание.