Wide Events вместо метрик, логов и трейсов

Разбираем концепцию Wide Events: почему объединение метрик, логов и трейсов в единые события упрощает отладку и делает мониторинг предсказуемым.

Проблема разделения данных в обсервабилити

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

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

Разрыв контекста между метриками и логами

Основная проблема здесь — потеря связи между агрегированным показателем и конкретным событием. Представьте ситуацию: ваш Prometheus сигнализирует о резком скачке задержки (latency) на API-шлюзе. Вы видите график, где линия уходит вверх, и понимаете, что что-то не так. Но что именно?

Чтобы найти причину, вам приходится переключаться в систему сбора логов (например, в ELK или Loki) и пытаться вручную сопоставить время на графике с записями в логах. Вы начинаете фильтровать логи по временному интервалу, по конкретному сервису или по уровню ERROR.

Проблема в том, что метрики — это агрегаты. В них нет контекста конкретного пользователя или ID транзакции. Если в логах нет заранее подготовленного идентификатора, который совпадает с тем, что вы могли бы вытащить из метрик (если бы они были высококардинальными), вы тратите время на гадание.

Например, типичный поиск в Grafana Loki после того, как сработал алерт по метрикам, выглядит так:

logql
# Пытаемся найти логи сервиса за период скачка, 
# но не знаем, какой именно запрос вызвал проблему
{job="api-gateway"} |= "error" | json

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

Сложности корреляции трейсов с состоянием системы

Трейсинг (Distributed Tracing) добавляет ещё один уровень сложности. Когда у вас микросервисная архитектура, один запрос может проходить через пять-шесть узлов. Трейс отлично показывает, на каком этапе возникла задержка, но он почти ничего не говорит о состоянии инфраструктуры в этот момент.

Допустим, ваш трейс показывает, что сервис Order-Service ждал ответа от базы данных 2 секунды вместо привычных 10 мс. Трейс говорит: «Задержка здесь». Но он не скажет, что в это же время на ноде с базой данных закончилась свободная память или начался процесс vacuum в PostgreSQL, который съел все IOPS.

Чтобы связать трейс с состоянием системы, вам нужно:

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

Этот процесс напоминает попытку собрать пазл, где детали лежат в разных коробках. Вы постоянно переключаете контекст между инструментами. Вместо того чтобы изучать единое событие, которое содержит в себе и путь запроса, и метаданные окружения, вы занимаетесь ручной корреляцией.

В концепции Wide Events, которую продвигают эксперты по обсервабилити, предлагается уйти от этого разделения. Вместо того чтобы хранить метрику «количество 500-х ошибок» отдельно от лога «ошибка подключения к БД», нужно создавать одно широкое событие, где в одной записи будут и trace_id, и user_id, и container_id, и даже текущая загрузка CPU. Это превращает мониторинг из поиска иголки в стоге сена в направленное исследование.

Концепция Wide Events как решение

Что такое широкие события

Когда мы говорим о классическом мониторинге, мы привыкли к разделению: метрики показывают, что происходит (растёт загрузка CPU), логи — что именно случилось (ошибка в приложении), а трейсы — где именно возникла задержка. Проблема в том, что эти данные живут в разных мирах. Чтобы связать всплеск на графике Grafana с конкретной строчкой в Loki, инженеру приходится совершать «прыжки» между инструментами, пытаясь вручную сопоставить время и ID запроса.

Концепция Wide Events (широких событий) предлагает другой подход. Вместо того чтобы разбрасывать данные по разным хранилищам, мы собираем всё в один массивный объект. Представьте себе лог-запись, которая содержит в себе не только сообщение об ошибке, но и все ключевые метрики текущего состояния: использование памяти, ID пользователя, версию контейнера, длительность запроса и даже теги из распределённых трейсов.

С практической точки зрения, это превращает мониторинг из набора разрозненных графиков в поток структурированных данных. Если мы используем, например, OpenTelemetry, то вместо отправки отдельных метрик мы формируем Span, который обогащается контекстом.

Пример того, как может выглядеть структура такого события в формате JSON:

json
{
  "timestamp": "2023-10-27T10:15:30.005Z",
  "event_type": "http_request",
  "trace_id": "a1b2c3d4e5f6",
  "span_id": "z9y8x7",
  "service_name": "order-processor",
  "status": "error",
  "http_method": "POST",
  "http_url": "/api/v1/orders",
  "duration_ms": 450,
  "user_id": "user_9921",
  "container_id": "f3a2b1c0d4e5",
  "cpu_usage_percent": 12.5,
  "memory_usage_bytes": 512000000,
  "error_message": "connection timeout to database",
  "db_host": "postgres-primary"
}

В этом объекте уже есть всё: и метрика (CPU, memory), и лог (error_message), и след (trace_id).

Преимущества единого контекста для инженера

Главная цель любого мониторинга — предсказуемость. Когда вы получаете алерт, вы должны понимать причину, а не тратить полчаса на сборку пазла из разных систем. Wide Events решают эту задачу через три ключевых аспекта.

Во-первых, это радикальное упрощение корреляции. В традиционной схеме вы видите на графике метрик error_rate рост. Вы идете в логи, фильтруете их по времени, надеясь попасть в тот же интервал. В случае с широкими событиями вы просто делаете запрос к базе данных (например, в ClickHouse или Elasticsearch), который объединяет эти данные.

Во-вторых, это возможность глубокой фильтрации по произвольным признакам. Если в событии уже зашиты метаданные, вы можете мгновенно ответить на вопросы, которые раньше требовали сложной настройки: «Вырос ли процент ошибок только у пользователей с определённым user_id?» или «Связана ли задержка с конкретным узлом в кластере container_id?».

В-третьих, это экономия когнитивного ресурса. Инженеру не нужно держать в голове карту связей между сервисами, когда контекст уже принесён к нему «на блюдечке».

Если мы посмотрим на процесс отладки через призму SQL-подобных запросов к таким событиям, то вместо переключения вкладок мы просто уточняем запрос. Допустим, нам нужно найти все медленные запросы, которые также сопровождались высокой нагрузкой на память:

sql
-- Пример запроса к хранилищу широких событий
SELECT 
    http_url, 
    user_id, 
    duration_ms, 
    memory_usage_bytes
FROM 
    observability_events
WHERE 
    event_type = 'http_request' 
    AND duration_ms > 500 
    AND memory_usage_bytes > 400000000
ORDER BY 
    duration_ms DESC
LIMIT 10;

Такой подход делает процесс расследования инцидентов линейным и понятным. Вместо того чтобы гадать, почему «всё упало», вы сразу видите корреляцию между параметрами системы и поведением приложения. Подробнее о математической модели такого подхода можно почитать в оригинальных исследованиях по observability.

Практическая реализация подхода

Проектирование структуры события

Когда мы переходим от разрозненных метрик к Wide Events, главная задача — перестать собирать «просто данные» и начать собирать контекст. В классическом подходе вы видите всплеск CPU на графике (метрика), идете в поиск по логам и пытаетесь угадать, какой именно запрос вызвал нагрузку, а затем пытаетесь сопоставить это с ID транзакции в трейсе. Это работа детектива, а не инженера.

Wide Event решает эту проблему, превращая одну запись в богатый массив данных. Вместо того чтобы отправлять в Prometheus число latency=150ms, мы отправляем одно событие, которое содержит в себе всё: и задержку, и ID пользователя, и версию приложения, и даже параметры запроса.

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

Identity (Идентификация): trace_id, span_id, request_id. Это «клей», который связывает событие с остальной системой.
Context (Контекст): user_id, tenant_id, service_version, environment (production/staging).
Payload (Полезная нагрузка): method, path, status_code, duration_ms.
Infrastructure (Инфраструктура): host_name, container_id, region.

Пример того, как может выглядеть JSON-объект одного такого события:

json
{
  "timestamp": "2023-10-27T14:15:01.123Z",
  "event_type": "http_request",
  "trace_id": "a1b2c3d4e5f6g7h8",
  "service": "order-processor",
  "version": "v2.4.1",
  "status": 500,
  "duration_ms": 450,
  "user_id": "user_9982",
  "endpoint": "/api/v1/checkout",
  "host": "vinni-puh-node-01",
  "error_message": "database connection timeout",
  "db_instance": "postgres-main"
}

Такой подход обеспечивает предсказуемость: если у вас упала база данных, вы не просто увидите рост ошибок 5xx, вы сразу увидите, какие именно пользователи и какие версии сервисов пострадали, не переключаясь между вкладками мониторинга.

Инструменты для сбора и хранения данных

Для реализации Wide Events вам не подойдёт классический стек Prometheus + Loki + Tempo в их чистом виде, если вы хотите бесшовной склейки. Prometheus по своей природе не умеет работать с высококардинальными данными (high cardinality) — если вы попытаетесь запихнуть user_id в метрику Prometheus, вы быстро «положите» его базу данных.

Для работы с широкими событиями лучше всего подходят системы, ориентированные на структурированные логи и колоночные хранилища.

ClickHouse. Это мой фаворит для таких задач. Благодаря колоночному хранению, ClickHouse позволяет мгновенно агрегировать миллиарды событий по любым полям. Вы можете хранить там и логи, и метрики (в виде событий), и трейсы.
Grafana Tempo. Если вы всё же используете экосистему Grafana, Tempo позволяет хранить трейсы, но для полноценных Wide Events вам всё равно понадобится мощный слой обработки логов.
Vector (от Datadog). Это отличный инструмент для сбора и трансформации данных. Я часто использую его в своей домашней лаборатории для того, чтобы перехватывать логи, обогащать их метаданными (например, добавлять имя хоста или ID контейнера) и отправлять в ClickHouse.

Чтобы настроить сбор таких данных через Vector, вам нужно создать конфигурацию, которая будет выполнять роль ETL-процесса. Вот пример конфига vector.yaml, который принимает логи, добавляет к ним информацию о системе и отправляет в ClickHouse:

yaml
sources:
  app_logs:
    type: "stdin" # В реальности здесь будет socket или file

transforms:
  enrich_events:
    type: "remap"
    inputs:
      - "app_logs"
    source: |
      # Добавляем системный контекст к каждому событию
      .host = get_hostname!()
      .environment = "production"
      
      # Приводим статус-код к числу для удобства агрегации
      if exists(.status) {
        .status = to_int!(.status)
      }

sinks:
  clickhouse_storage:
    type: "clickhouse"
    inputs:
      - "enrich_events"
    endpoint: "http://localhost:8123"
    database: "observability"
    table: "wide_events"

С такой архитектурой вы получаете единую точку правды. Вместо того чтобы гадать, почему метрика «скакнула», вы выполняете один SQL-запрос к ClickHouse и получаете полный разрез ситуации: от конкретного запроса до состояния инфраструктуры в этот момент. Подробнее о принципах работы с колоночными БД в контексте мониторинга можно почитать в документации ClickHouse.

Сравнение подходов и выводы

Когда традиционный стек всё ещё эффективен

Несмотря на очевидные преимущества Wide Events, я не призываю немедленно выбрасывать Prometheus или ELK на свалку истории. Традиционный подход, разделяющий метрики, логи и трейсы по разным «корзинам», всё ещё имеет право на жизнь в определённых сценариях.

Во-первых, это вопрос масштаба и стоимости хранения. Если ваша задача — просто следить за загрузкой CPU на десяти Raspberry Pi или мониторить uptime сервиса, классические метрики (time-series data) справятся идеально. Они потребляют в разы меньше ресурсов, чем поток структурированных событий. Если вам нужно знать, что «всё упало», вам не нужен контекст каждого запроса — достаточно одного алерта от Prometheus.

Во-вторых, когда инфраструктура стабильна и предсказуема. Если у вас нет сложной микросервисной архитектуры, а есть монолит в Docker-контейнере, то разделение на метрики и логи работает вполне эффективно. Вы видите всплеск 500-х ошибок в Grafana, открываете Kibana и находите соответствующую строку в логах. Это работает, это понятно, и это не требует перестройки всей системы телеметрии.

С практической точки зрения, традиционный стек эффективен, когда:

Вам нужна высокая детализация агрегатов при минимальных затратах (метрики).
У вас низкая связность сервисов (монолиты или простые связки).
Бюджет на хранение данных ограничен.

Переход на Wide Events: с чего начать

Переход на концепцию Wide Events — это не замена инструментов, а изменение способа генерации данных. Вместо того чтобы отправлять в разные системы разрозненные куски информации, мы начинаем обогащать каждое событие контекстом.

Если мы посмотрим на типичный лог, он часто выглядит как сухая строка. В подходе Wide Events мы превращаем его в структурированный JSON, где помимо сообщения об ошибке сразу присутствуют ID пользователя, ID транзакции, версия приложения и даже параметры конфигурации, которые использовались в момент запроса.

Чтобы начать этот путь, не нужно переписывать всё приложение. Можно начать с уровня инфраструктуры или прокси-сервера. Например, настройте Nginx или Caddy так, чтобы они отдавали расширенные логи в формате JSON. Это даст вам первый уровень «широких событий».

Для Nginx это может выглядеть так:

nginx
# Пример настройки расширенного JSON-лога в nginx.conf
log_format wide_event_json escape=json '{'
  '"time_local": "$time_local", '
  '"remote_addr": "$remote_addr", '
  '"request_method": "$request_method", '
  '"request_uri": "$request_uri", '
  '"status": "$status", '
  '"body_bytes_sent": "$body_bytes_sent", '
  '"request_time": "$request_time", '
  '"upstream_response_time": "$upstream_response_time", '
  '"http_x_request_id": "$http_x_request_id", ' # Важно для сквозной трассировки
  '"user_agent": "$http_user_agent"'
'}';

access_log /var/log/nginx/access.log wide_event_json;

Обратите внимание на поле http_x_request_id. Это ключ к предсказуемости. Если ваш сервис (например, на Python или Go) будет принимать этот ID и пробрасывать его дальше во все свои внутренние логи и трейсы, вы получите единую нить расследования.

С чего именно стоит начать внедрение:

Внедрите Request ID. Это фундамент. Без уникального идентификатора запроса, который проходит через все слои системы, Wide Events превращаются в просто «очень подробные логи».
Перейдите на структурированный логинг. Забудьте про plain text. Только JSON. Это позволит вашим системам сбора данных (например, Vector или Fluent Bit) легко парсить поля и сразу индексировать их.
Обогащайте события на выходе. Если ваше приложение не может само добавить контекст (например, версию деплоя), добавьте его на этапе сбора данных с помощью агента.

Такой подход позволяет сократить время поиска причины инцидента (MTTR). Вместо того чтобы переключаться между тремя вкладками браузера, пытаясь сопоставить время в логах с графиком в Grafana, вы открываете одно событие и видите всю картину целиком.

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

Чем Wide Events отличаются от классического трейсинга?

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

Можно ли полностью отказаться от Prometheus и ELK?

Переход на Wide Events не означает, что нужно удалять привычные инструменты, но меняется их роль. Вы всё ещё можете использовать Prometheus для быстрого алертинга по агрегатам, но вместо того, чтобы тратить время на поиск связи между графиком и логом, вы сразу переходите к детальному событию. Это не замена инструментов, а изменение способа передачи данных от приложения к системе мониторинга.

Не вырастет ли объем передаваемых данных при таком подходе?

С точки зрения объёма — да, нагрузка на сеть и хранилище увеличится, так как мы перестаём агрегировать данные на стороне приложения и начинаем слать больше контекста. Однако с практической точки зрения это окупается за счёт сокращения времени на расследование инцидентов (MTTR). Вы платите за хранение данных, чтобы не платить временем инженеров, которые пытаются вручную склеить разрозненные логи и метрики.

Как внедрить Wide Events в уже работающий проект?

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