Observability: метрики, трейсы и логи в production-системах

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

За последнее десятилетие индустрия выработала концепцию observability — комплексного подхода к видимости системы изнутри. Три столпа observability — метрики, трейсы, логи — каждый отвечает на свой класс вопросов. Зрелая команда понимает, какой инструмент применять к какой задаче, и не тратит время на расследование через логи того, что должно решаться через трейсы. Разбираем устройство современной observability, технологии экосистемы, типичные ошибки внедрения.

Три столпа observability

Концепция трёх столпов сформировалась в 2017–2018 годах с появлением термина observability в инженерной литературе. До этого индустрия говорила про мониторинг — более узкое понятие, фокусирующееся на проверке заранее определённых состояний системы. Observability ставит более амбициозную цель: уметь отвечать на любые вопросы о состоянии системы, в том числе те, которые мы не предвидели заранее.

Метрики: численная картина состояния

Метрики — численные показатели, измеряемые с фиксированной периодичностью. Counter (счётчик увеличений), Gauge (текущее значение, может расти и падать), Histogram (распределение значений) — три основных типа. Метрики хранятся в time-series базах, агрегируются по периодам, визуализируются в дашбордах, используются для алертов.

Сильная сторона метрик — низкая стоимость хранения и быстрота агрегации. Метрика «количество запросов в секунду» за сутки занимает килобайты данных, выводится мгновенно за любой период, легко складывается между сервисами. Метрики идеальны для понимания общего состояния системы: загрузка процессора, ошибки, время ответа, использование памяти.

Слабость метрик — потеря контекста. Метрика говорит «было 100 ошибок 500», но не говорит, какие именно запросы, от каких пользователей, на каких эндпоинтах. Для детального расследования нужны другие сигналы. Метрики — отличный «детектор аномалий», но плохой «отладчик».

The Four Golden Signals и RED-метрики

За годы практики индустрия выработала наборы стандартных метрик. Самые известные — Four Golden Signals от Google SRE и RED-метрики (Rate, Errors, Duration) от Tom Wilkie.

Four Golden Signals: latency (время ответа), traffic (нагрузка на систему), errors (ошибки), saturation (насыщенность ресурсов). Эти четыре сигнала покрывают большинство ситуаций, в которых возникают проблемы. Любой сервис в продакшене должен экспортировать все четыре.

RED-метрики — упрощённая версия для микросервисов: Rate (количество запросов), Errors (количество ошибок), Duration (длительность запросов). Более сжато, чем Four Golden Signals, проще внедрять, охватывает основные потребности микросервиса.

USE-метрики (Utilization, Saturation, Errors) от Brendan Gregg — для измерения состояния ресурсов (CPU, memory, disk, network). Дополняют RED, который смотрит на сервис со стороны запросов; USE смотрит со стороны нагрузки на ресурсы.

Prometheus как стандарт сбора метрик

Prometheus — open-source система мониторинга, ставшая де-факто стандартом для метрик в облачных и микросервисных архитектурах. Запущена в SoundCloud в 2012, в 2016 принята в CNCF, к 2026 году доминирует в экосистеме Kubernetes и cloud-native приложений.

Архитектура Prometheus — pull-based: сервер сам опрашивает целевые сервисы по HTTP, забирая текущие значения метрик. Это упрощает service discovery, позволяет проверять «живой» статус через сам факт ответа, дает контроль за частотой сбора на стороне сервера. Push-модель (когда сервисы сами шлют метрики) используется реже, через push gateway для batch-задач.

PromQL — язык запросов Prometheus — мощный и одновременно понятный. Базовые операции (сложение метрик, фильтрация по лейблам, агрегация) укладываются в несколько строк. Сложные операции (rate с windows, percentile через histogram_quantile, joins между метриками) требуют изучения, но дают огромные возможности для глубокого анализа.

Трейсы: путь запроса через систему

Distributed tracing — техника отслеживания одного запроса через множество сервисов. Каждое обращение пользователя к системе создаёт собственный trace ID, который пропагируется через все вызовы между сервисами. Каждый сервис добавляет к трейсу свой span — отрезок выполнения с метаданными.

Результат — древовидная структура, показывающая полный путь запроса: какие сервисы вызывались, в каком порядке, сколько времени каждый занял, где возникли ошибки. Это основной инструмент для понимания latency-проблем в микросервисах: трейс мгновенно показывает, какой именно вызов «съел» секунды.

В отличие от метрик, трейсы дают конкретные данные о конкретных запросах, не агрегированные. Можно увидеть «вот этот запрос пользователя X занял 4 секунды, потому что подсервис Y отвечал медленно из-за БД-запроса Z». Метрики никогда не дадут такой детализации.

OpenTelemetry: единый стандарт

До недавнего времени в индустрии конкурировали несколько проектов distributed tracing: Jaeger от Uber, Zipkin от Twitter, OpenTracing, OpenCensus. Каждый имел свою API, форматы, инструментацию. Команды теряли время на интеграцию разных систем.

В 2019 году появился OpenTelemetry (OTel) — слияние OpenTracing и OpenCensus в единый стандарт CNCF. К 2026 году OTel стал индустриальным стандартом для инструментации приложений. Один SDK на каждом языке программирования, унифицированный формат данных, совместимость со всеми популярными бэкендами (Jaeger, Zipkin, Tempo, Honeycomb, Datadog).

OpenTelemetry покрывает три столпа сразу: traces, metrics, logs. Это превращает его в универсальный инструмент инструментации. Команда внедряет OTel один раз, потом может менять backend для каждого сигнала без изменения кода приложения. Это резко снижает vendor lock-in и упрощает миграции.

OpenTelemetry — главное изменение в observability за последние пять лет. Стандартизация инструментации устранила фрагментацию рынка и сделала миграции между observability-провайдерами реалистичными.

Логи: события с контекстом

Логи — самый старый из трёх сигналов observability. Текстовые записи о событиях в системе с временной меткой, уровнем серьёзности (debug, info, warn, error), сообщением и опциональным контекстом. Логи существовали в программировании с появления самого программирования.

Современный подход к логам отличается от ранней практики «выводи всё, что считаешь нужным». Структурированные логи — записи в формате JSON (или подобном) с явными полями (timestamp, level, service, trace_id, user_id, и так далее). Это позволяет фильтровать, искать, агрегировать логи системно, а не через regex по тексту.

Главная сложность с логами в продакшене — объём. Активный сервис может генерировать миллионы строк в час. Хранение и обработка такого объёма стоят значительных денег. Стратегии оптимизации: уровни логирования (debug в dev, info в prod), sampling (запись только части запросов), retention policies (хранение свежих логов в горячем хранилище, старых — в холодном).

ELK, Loki, OpenSearch: стеки для работы с логами

Несколько популярных решений для централизованного логирования.

ELK Stack (Elasticsearch + Logstash + Kibana) — классический стек, доминировавший в 2010-х. Elasticsearch как хранилище и поисковая система, Logstash для ингестии, Kibana для визуализации. Мощный, гибкий, но дорогой в эксплуатации на больших объёмах.

OpenSearch — open-source форк Elasticsearch после смены лицензии Elastic в 2021 году. AWS поддерживает, активно развивает, совместим с большинством инструментов ELK. Стал популярной альтернативой для команд, желающих остаться на полностью open-source стеке.

Grafana Loki — относительно новый игрок, спроектированный под cloud-native окружения. Принципиальное отличие — индексируются только labels (не полный текст лога), что делает Loki значительно дешевле в хранении и эксплуатации. Поиск по тексту работает медленнее, чем в Elasticsearch, но для большинства задач достаточно.

Datadog, Splunk, Honeycomb — коммерческие платформы, объединяющие логи, метрики, трейсы в единую систему. Дороже open-source решений, но избавляют от необходимости поддерживать собственную инфраструктуру.

Корреляция между сигналами

По-настоящему мощной observability становится, когда три сигнала связаны друг с другом. Запрос с trace_id попадает в метрики, логах и трейсы — все три с одинаковым идентификатором. От алерта по метрикам можно перейти к проблемным трейсам, оттуда — к логам конкретных запросов.

Стандартный путь расследования инцидента: алерт по метрикам сигнализирует о проблеме (рост latency, ошибок) → дашборд метрик подтверждает и сужает время инцидента → трейсы за этот период показывают, какие именно сервисы и какие операции медленные → логи проблемных запросов раскрывают детали ошибок.

Корреляция требует дисциплины в инструментации. Сервис должен включать trace_id в каждую запись лога, использовать одинаковые лейблы в метриках и трейсах, передавать контекст между всеми вызовами. OpenTelemetry упрощает эту работу через автоматическую пропагацию контекста.

Cardinality: вечный враг наблюдаемости

Одна из главных операционных проблем observability — cardinality. Это количество уникальных комбинаций лейблов в метрике. Метрика http_requests_total с лейблами method и status имеет небольшую cardinality (4 метода × 10 статусов = 40 серий). Та же метрика с дополнительным лейблом user_id имеет cardinality в миллионы — каждый пользователь создаёт свою серию.

Высокая cardinality убивает производительность систем мониторинга. Хранение растёт линейно с количеством серий, запросы становятся медленными, использование памяти растёт. Известная фраза в SRE-сообществе: «cardinality kills observability».

Стратегии управления cardinality: не использовать высоко-вариативные значения как лейблы (user_id, request_id, IP), использовать ограниченные перечисляемые значения, агрегировать перед записью метрики, использовать sampling для высоко-вариативных данных. Запросы по user_id обычно делаются через логи и трейсы, не через метрики.

SLI, SLO, error budgets

Observability — фундамент для практики SRE (Site Reliability Engineering). SLI (Service Level Indicator) — конкретная метрика, измеряющая надёжность: доля успешных запросов, p99 latency, доля запросов с ответом меньше 200мс. SLO (Service Level Objective) — целевое значение SLI: «99.9% запросов должны быть успешными за месяц». Error budget — допустимая доля отказов: 100% — SLO = 0.1% за месяц.

Error budget превращает абстрактное «надо быть надёжными» в конкретную метрику принятия решений. Если бюджет израсходован, команда переключается с разработки фичей на работу над надёжностью. Если бюджет не израсходован, можно деплоить агрессивнее, экспериментировать с новыми технологиями.

Alerting: уведомления о проблемах

Метрики — основа алертинга. Команда определяет условия, при которых дежурный инженер должен получить уведомление: error rate выше 1%, latency p95 выше 500мс, error budget burn rate выше определённого порога.

Хорошая система алертинга балансирует между двумя крайностями. Слишком чувствительная — даёт false positive, инженеры устают и игнорируют уведомления (alert fatigue). Слишком грубая — пропускает реальные проблемы. Зрелая команда регулярно ревьюит алерты, удаляет неэффективные, добавляет новые на основе ретроспектив инцидентов.

Современный подход — алертинг по SLO burn rate. Не «error rate выше X», а «при текущей скорости ошибок error budget будет израсходован за N часов». Это даёт более релевантные уведомления: вспышка ошибок на пять минут не даёт алерт, потому что общий бюджет не страдает, но постепенное накопление мелких ошибок алертится за день до фактического превышения.

Profiling: четвёртый столп?

В последние годы часто говорят о четвёртом столпе observability — continuous profiling. Это сбор детальной информации о потреблении ресурсов внутри приложения: какие функции занимают CPU, какие объекты живут в памяти, где блокируются потоки.

Инструменты вроде Pyroscope, Parca, Grafana Phlare позволяют непрерывно собирать профили в продакшене с минимальным overhead. Это даёт ответ на вопрос «почему сервис медленный изнутри», который традиционные метрики, трейсы и логи не покрывают.

Continuous profiling — относительно новая практика, ещё не такая зрелая, как остальные столпы. Но направление развития ясное: команды, серьёзно занимающиеся производительностью, всё чаще включают профилирование в свою observability-инфраструктуру.

Часто задаваемые вопросы

С чего начать внедрение observability в маленьком проекте?

С метрик. Это самый простой и дешёвый сигнал. Подключить Prometheus или managed-аналог, добавить экспортёры в сервисы, настроить базовые дашборды и алерты по RED-метрикам. Дальше — добавить структурированные логи. Distributed tracing внедряется позже, когда система становится распределённой настолько, что без него уже не понять.

Сколько логов хранить в продакшене?

Зависит от регуляторных требований и объёма данных. Типичные настройки: горячее хранилище для последних 7–14 дней с быстрым доступом, тёплое для 1–3 месяцев, холодное (S3, Glacier) для длительного хранения. Для compliance в финансовой сфере и здравоохранении часто требуется 7+ лет хранения, что обычно делается через archive в дешёвом облачном хранилище.

Какой бэкенд для traces выбрать — Jaeger, Tempo, или Honeycomb?

Jaeger — зрелое open-source решение, доминирует в Kubernetes-окружениях. Tempo от Grafana — современная альтернатива с лучшей интеграцией с Grafana-стеком. Honeycomb — коммерческое решение с уникальными возможностями анализа high-cardinality данных. Выбор зависит от существующего стека: для Grafana-команд — Tempo, для общего open-source — Jaeger, для команд с серьёзными observability-задачами — Honeycomb или Datadog.

Нужны ли отдельные дашборды для каждого сервиса?

Нужны на двух уровнях. Сервисные дашборды с RED-метриками для каждого микросервиса — для дежурных инженеров и владельцев сервисов. Общие дашборды бизнес-метрик и SLO — для команд и руководства. Универсальные шаблоны (тот же дашборд, параметризованный именем сервиса) помогают избежать ручной работы при создании дашборда для каждого нового сервиса.

Что такое sampling в трейсинге и зачем он нужен?

Sampling — запись только части запросов в трейсы. Если каждый запрос системы генерирует трейс, хранилище быстро забивается, а большинство трейсов будут совершенно обычные и неинтересные. Sampling сохраняет, например, 1% случайных запросов плюс все запросы с ошибками плюс все медленные. Это даёт хорошее покрытие при значительной экономии ресурсов.

Можно ли обойтись без OpenTelemetry, используя нативный SDK провайдера?

Можно, но не рекомендуется в долгосрочной перспективе. Vendor SDK создаёт lock-in: при желании поменять провайдера нужно переделывать всю инструментацию. OpenTelemetry даёт ту же функциональность с возможностью смены backend без изменения кода. Производительность OTel сопоставима с native SDK, разница не оправдывает lock-in.

Заключение

Observability в современных распределённых системах — не опциональная функция, а критический компонент инфраструктуры. Без неё команда работает вслепую: знает, что что-то сломалось (от пользователей или мониторов uptime), но не понимает, что именно и почему. Часы и дни уходят на расследования, которые в хорошо инструментированной системе занимают минуты.

Три столпа observability — метрики, трейсы, логи — комплементарны. Каждый отвечает на свой класс вопросов: метрики дают общую картину состояния, трейсы показывают путь конкретных запросов, логи раскрывают детали событий. Зрелая команда использует все три согласованно, с корреляцией через общие идентификаторы и стандартизированную инструментацию.

OpenTelemetry стал главной структурной инновацией последних лет, унифицировав инструментацию и избавив от vendor lock-in. SLO, error budgets и burn-rate алертинг — практики, превратившие observability из реактивного «расследования» в проактивное управление надёжностью. Команды, инвестирующие в зрелую observability-инфраструктуру, получают конкурентное преимущество в скорости реакции на проблемы, качестве пользовательского опыта и предсказуемости поведения системы в продакшене.