Телеметрия: логи, метрики, трейсы. Как заставить систему рассказывать о себе

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

Телеметрия — это практика сбора данных о работе системы в реальном времени и их передача для мониторинга и анализа. В мире SRE она опирается на три фундаментальных столпа: логи (logs), метрики (metrics) и трейсы (traces). Понимание разницы между ними и умение их правильно использовать - это то, что отличает продвинутую команду от той, что постоянно гадает на кофейной гуще.

1. Логи (Logs): "Что произошло?"

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

  • Формат: неструктурированный или полуструктурированный текст (часто JSON).
  • Детализация: высокая. Могут содержать полные ошибки (stack traces), ID пользователей, параметры запросов.
  • Объём: огромный. Могут генерировать терабайты данных.
  • Пример: 2025-12-25T10:55:45Z INFO [auth-service] User 12345 successfully logged in from IP 192.168.1.1

Аллегория: Бортовой самописец (чёрный ящик) самолёта. Он записывает всё: каждое действие пилота, показания всех датчиков, переговоры. Бесценен для расследования катастрофы, но для управления полётом в реальном времени пилот не смотрит в него постоянно.

Как использовать в SRE:

  • Отладка и расследование инцидентов: когда что-то сломалось, логи — первое место, куда смотрят, чтобы найти ошибку и её контекст.
  • Аудит и безопасность: отслеживание действий пользователей и подозрительной активности.
  • Важное правило:логи должны быть структурированы. Искать ошибку по тексту "Failed to process order" в гигабайтах текста — ад. Искать по полю {“event_type”: “order_failure”, “order_id”: “abc123”} - быстро и точно.

Опасно и глупо: есть соблазн логировать всё подряд. Это приводит к гигантским затратам на хранение и сложностям анализа. Нужно логировать осмысленно и контекстно.

2. Метрики (Metrics): "Сколько? Как быстро?"

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

Характеристики:

  • Формат: числа, обычно с тегами/лейблами (например: http_requests_total{path="/api/v1/order", status="500"}).

  • Детализация: низкая (агрегированная). Вы не увидите отдельный запрос, но увидите общую картину.

  • Объём: относительно небольшой. Десятки-сотни тысяч временных рядов.

  • Пример: service_latency_ms{quantile="0.95"} 150 — 95% запросов выполняются быстрее 150 мс.

Аллегория: Приборная панель автомобиля. Вы не видите каждое вращение коленвала, но видите ключевые агрегированные показатели: скорость, обороты двигателя, уровень топлива, температуру. По ним вы понимаете общее состояние и принимаете решения в реальном времени (сбросить газ, заправиться).

Как использовать в SRE:

  • Мониторинг и алертинг: это основа для SLO. Вы ставите алерт, когда метрика (например, частота ошибок) выходит за заданные границы.
  • Визуализация и анализ трендов: Дашборды на Grafana показывают, как метрики ведут себя в течение времени. Рост задержки перед сбоем - критически важный сигнал.
  • Планирование ёмкости: Анализ роста трафика (запросов в секунду) для понимания, когда нужно добавить ресурсы.
  • Золотое правило: Метрики должны быть дешёвыми для сбора и хранения. Их сбор не должен влиять на производительность самого сервиса.

Опасность: Когда мы собираем слишком много метрик ("метрический шум") или слишком мало. Необходим баланс и фокус на том, что действительно отражает здоровье сервиса с точки зрения пользователя (ключевые SLI). Собирать метрики для того, "чтобы они были" - бессмысленно и дорого.

3. Трейсы (Traces): "Где и сколько?"

Трейсы (или распределённые трейсы, distributed traces) - это записи пути выполнения одного логического запроса (транзакции) через все компоненты распределённой системы. Они показывают, какие микросервисы запрос посетил, сколько времени провёл в каждом, и где возникли проблемы.

Характеристики:

  • Формат: иерархическая структура (дерево span'ов), привязанная к уникальному trace_id.
  • Детализация: высокая на уровне пути выполнения, но не на уровне данных.

  • Объём: значительный, но обычно меньше, чем у логов, так как трейсится не 100% запросов, а только выборка.

  • Пример: Запрос POST /order (корневой span) вызвал auth-service (дочерний span, 5 мс), затем payment-service (дочерний span, 120 мс), затем inventory-service (дочерний span, 30 мс). Видно, что проблема в payment-service.

Аллегория: GPS-трекер и детализированный маршрутный лист курьера. Вы видите не только что он доехал из точки А в Б (метрика), но и весь его путь: где он стоял в пробке 20 минут (задержка в payment-service), где заехал на склад (вызов inventory-service). Это позволяет найти узкие места в логистической цепочке.

Как использовать в SRE:

  • Профилирование производительности и поиск «горячих точек»: трейсы - лучший инструмент, чтобы ответить на вопрос "Почему всё стало медленным?". Они сразу показывают, в каком конкретно сервисе или даже методе началась деградация.
  • Понимание зависимостей: карта трейсов визуализирует, как микросервисы взаимодействуют друг с другом, что критично при инцидентах.
  • Отладка сложных, сквозных сценариев: например, почему у пользователя не создался заказ, если каждый отдельный сервис в логах пишет "OK".

Опасность: сложность настройки и внедрения (требует инструментов вроде Jaeger или коммерческих APM-решений и модификации кода). Также нужно аккуратно управлять sampling rate (процентом запросов, которые трейсятся), чтобы не перегрузить систему.

Синергия: 1 + 1 + 1 > 3

Настоящая сила телеметрии раскрывается, когда три столпа работают вместе, связанные общим контекстом (например, через trace_id или request_id).

Сценарий инцидента:

  1. Метрика показывает всплеск 500-х ошибок в order-service.

  2. Вы открываете трейс одного из неудачных запросов и видите, что он надолго «завис» в вызове payment-service.

  3. Вы переходите к логам payment-service, фильтруя их по trace_id из трейса, и мгновенно находите конкретную ошибку: Timeout connecting to database.

Без трейсов вы бы часами сопоставляли логи разных сервисов.

Без логов вы бы знали, что проблема в payment-service, но не видели бы причину.

Без метрик вы бы вообще не узнали о проблеме, пока пользователи не начали массово жаловаться.

От мониторинга к наблюдаемости (Observability)

Чем мониторинг отличается от наблюдаемости - в главе "Разница между мониторингом и наблюдаемостью (observability)".

Мониторинг - это когда вы задаёте системе заранее известные вопросы ("CPU загружен?", "Сервис отвечает?") и смотрите на заранее подготовленные дашборды.

Наблюдаемость (observability) - это когда вы можете задать системе любой, даже неожиданный вопрос о её внутреннем состоянии, и получить ответ на основе телеметрии. ("Почему виртуальные машины пользователей из Иркутска падают на 30% чаще в 14:07 по UTC?").

Логи, метрики и трейсы - это сырая нефть для наблюдаемости. Задача SRE не просто собирать её, а построить современный НПЗ: системы сбора (Fluentd, OpenTelemetry), хранения (Loki/Prometheus/специализированные БД), анализа и визуализации (Grafana), которые превращают этот поток данных в понимание, предсказания и, в конечном счёте, в надёжность.

Нельзя управлять тем, что не видишь и не понимаешь, надеюсь, все это понимают.