Зачем нужны Wide Events вместо метрик и логов

Разбираем концепцию широких событий (Wide Events) и почему классический подход «метрики, логи, трейсы» уступает место единому контексту в мониторинге.

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

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

В моей практике часто бывало так: Grafana показывает резкий скачок latency на одном из сервисов (метрика), я иду в Loki или Elasticsearch, чтобы найти ошибки (логи), и пытаюсь сопоставить время скачка с конкретными записями. Но время в системах сбора может расходиться на доли секунды, а идентификаторы запросов в логах могут не совпадать с тем, что зафиксировала система сбора метрик. Мы тратим драгоценное время на «склеивание» контекста, вместо того чтобы разбираться в причинах сбоя.

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

Основная проблема в том, что метрики и логи по своей природе принципиально разные. Метрики — это агрегированные числа. Они экономны, предсказуемы и отлично подходят для построения графиков, но они лишены деталей. Вы видите, что количество 500-х ошибок выросло, но не знаете, на каком именно пользователе или с каким параметром запроса это произошло.

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

Если мы посмотрим на типичный подход, то увидим пропасть. Допустим, у нас есть сервис на Python, который пишет логи в стандартный поток:

python
import logging

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

def process_request(user_id, request_id, payload_size):
    # Лог содержит детали, но это просто текст
    logger.info(f"Processing request {request_id} for user {user_id}, size: {payload_size}")
    # ... логика ...

А метрики мы отдаём через Prometheus:

python
from prometheus_client import Counter

REQUEST_COUNT = Counter('http_requests_total', 'Total HTTP Requests', ['method', 'endpoint', 'status'])

# Метрика содержит только агрегаты
REQUEST_COUNT.labels(method='GET', endpoint='/api/data', status='200').inc()

В этой схеме между user_id из лога и метрикой http_requests_total нет прямой связи. Если на графике метрик вы увидите аномалию, вы не сможете мгновенно «провалиться» в конкретные логи этого пользователя, потому что в метрике нет его ID, а в логе нет агрегированного счетчика. Мы пытаемся восстановить цепочку событий вручную, полагаясь на то, что временные метки (timestamps) совпадут.

Сложность корреляции событий при инцидентах

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

Представьте ситуацию: ваш сервис в домашней лаборатории начал потреблять аномально много памяти.

Вы видите алерт в Prometheus (метрика).

Вы проверяете dmesg или системные логи через journalctl, чтобы понять, не убил ли процесс OOM Killer:

bash
journalctl -u my-service --since "10 minutes ago"

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

Проблема в том, что между «метрика показала рост» и «лог объяснил причину» лежит пропасть данных. Если инцидент вызван специфическим сочетанием параметров (например, конкретным типом запроса и размером полезной нагрузки), вы его не найдете в метриках, потому что вы не добавили эти параметры в labels (а делать это для всех параметров нельзя — вы быстро получите «взрыв» кардинальности в Prometheus).

В итоге инженер вынужден заниматься «гаданием на кофейной гуще»: переключаться между вкладками, копировать ID запросов, пытаться сопоставить время. Это именно тот разрыв, который концепция Wide Events призвана устранить, объединяя измерения и детали в едином потоке данных. Подробнее о том, как работают современные подходы к сбору данных, можно почитать в документации OpenTelemetry.

Что такое Wide Events и как они работают

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

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

Структура одного события вместо набора разрозненных данных

В традиционной схеме вы получаете набор разрозненных точек. Например, метрика http_requests_total скажет вам, что запросов стало больше, а лог в текстовом виде выдаст что-то вроде ERROR: connection timeout. Чтобы связать их, вам нужно знать, какой именно пользователь или какой именно контейнер вызвал эту ошибку.

Wide Event объединяет это. Представьте, что вместо записи «запрос завершён» вы отправляете структуру, где в одном объекте собраны:

Результат операции (статус-код, время выполнения).
Идентификаторы (user_id, request_id, session_id).
Инфраструктурный контекст (имя ноды, версия приложения, ID контейнера).
Бизнес-контекст (тип подписки, сумма корзины, регион).

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

json
{
  "event": "http_request_completed",
  "timestamp": "2023-10-27T14:20:01.123Z",
  "duration_ms": 145,
  "status_code": 200,
  "method": "GET",
  "path": "/api/v1/products",
  "user_id": "user_8842",
  "plan_type": "premium",
  "container_id": "web-app-7f8d9",
  "node_name": "Piatachok",
  "region": "eu-central-1",
  "db_query_count": 3,
  "cache_hit": true
}

С практической точки зрения это меняет правила игры. Вам больше не нужно делать grep по логам, пытаясь найти user_id, который фигурирует в метрике. Все параметры уже находятся в одной строке. Если вы видите всплеск задержек (latency), вы можете мгновенно сгруппировать эти события по plan_type или node_name и увидеть, что проблема касается только пользователей с бесплатным тарифом на конкретной ноде.

Преимущества обогащения событий метаданными

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

В классическом подходе, если вы решили, что вам нужно отслеживать задержки в разрезе версии API, вам нужно:

Изменить код приложения.
Добавить новую метрику.
Обновить конфигурацию системы сбора метрик.
Перерисовать график в Grafana.

С Wide Events вы просто добавляете новое поле в JSON-объект события. Если это поле уже есть в потоке данных, вы можете начать строить по нему графики и фильтры немедленно.

Для реализации такого подхода на уровне инфраструктуры часто используют middleware. Если мы работаем с Node.js или Go, мы можем написать обёртку для HTTP-клиента, которая будет собирать контекст. Например, в системном окружении можно использовать OpenTelemetry, чтобы автоматически добавлять атрибуты к спанам.

Пример того, как можно программно подготовить такие данные перед отправкой (псевдокод):

go
// Вместо записи отдельной метрики и лога, 
// мы формируем один богатый объект
event := WideEvent{
    Name:       "http_request",
    Duration:   time.Since(start),
    StatusCode: resp.StatusCode,
    // Обогащение контекстом из окружения
    NodeName:   os.Getenv("NODE_NAME"), 
    Container:  os.Getenv("HOSTNAME"),
    // Бизнес-контекст из контекста запроса
    UserID:     ctx.Value("user_id"),
    UserPlan:   ctx.Value("plan_type"),
}

// Отправляем одним вызовом
telemetry.Emit(ctx, event)

Это позволяет избежать ситуации, когда вы «знаете, что всё плохо, но не знаете почему». Обогащение данными превращает мониторинг из системы оповещения о фактах в инструмент глубокого исследования причин. Вы не просто видите, что «сервер упал», вы видите, что «сервер Пятачок упал из-за нехватки памяти в контейнере web-app при обработке запросов от пользователей с типом подписки premium».

Сравнение подходов к сбору данных

Традиционная модель: три столпа observability

Когда мы говорим об управлении инфраструктурой, нас приучили к классической триаде: метрики, логи и трассировка. В моей практике, когда я настраивал мониторинг для кластера на Proxmox, этот подход казался единственно верным. Мы разделяли данные по их «природе», и у каждого инструмента была своя зона ответственности.

Метрики — это агрегированные числовые значения. Они идеальны для понимания общего состояния системы: загрузка CPU на «Пятачке», свободное место на ZFS-пуле или количество запросов в секунду. Но у них есть фундаментальный недостаток — потеря контекста. Если вы видите скачок latency на графике в Grafana, метрика скажет вам, что произошло, но она не скажет, почему.

Логи — это попытка вернуть детализацию. Мы пишем в journald или отправляем данные в Loki, чтобы при возникновении ошибки прочитать конкретную строку. Но логи фрагментарны. Чтобы связать ошибку в приложении с системным событием, приходится заниматься «детективной работой»: сопоставлять временные метки, искать ID запроса в разных файлах и надеяться, что таймзоны на всех нодах настроены одинаково.

Трассировка (tracing) пытается склеить эти части, показывая путь запроса через микросервисы. Это мощно, но сложно и дорого в плане ресурсов.

С практической точки зрения, традиционная модель заставляет инженера постоянно переключать контекст:

Посмотрели на метрику (Grafana) — «О, CPU подскочил».
Перешли в логи (Loki/Kibana) — «Так, в это время упал процесс».
Пошли в трейсы (Jaeger) — «Ага, запрос застрял на базе данных».

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

Модель широких событий: единый поток контекста

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

Представьте, что вместо того, чтобы записывать отдельно «запрос пришёл» (метрика) и «ошибка в БД» (лог), мы отправляем один JSON-объект. В этом объекте будет и время выполнения, и статус ответа, и ID пользователя, и версия приложения, и даже параметры конфигурации сервера, на котором это произошло.

Если мы посмотрим на структуру такого события, она будет выглядеть примерно так:

json
{
  "timestamp": "2023-10-27T10:15:30.005Z",
  "event_type": "http_request",
  "duration_ms": 142,
  "status_code": 500,
  "user_id": "user_882",
  "node_name": "Vinni-Pukh",
  "container_id": "a1b2c3d4e5f6",
  "db_query_time_ms": 120,
  "error_message": "connection timeout",
  "app_version": "v2.4.1"
}

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

Например, вместо того чтобы гадать, почему тормозит база, вы можете мгновенно отфильтровать все события, где duration_ms > 100 и сгруппировать их по node_name или app_version. Вы сразу увидите, что проблема не во всей системе, а, скажем, только на конкретной ноде в вашем домашнем кластере.

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

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

Практическое применение и внедрение

Выбор инструментов для работы с событиями

Когда мы переходим от разрозненных метрик к концепции Wide Events, классический стек «Prometheus + ELK» начинает буксовать. Prometheus по своей природе — это TSDB (Time Series Database), он заточен под числовые значения с фиксированным набором лейблов. Если вы попытаетесь запихнуть в метрику Prometheus контекст пользователя, ID транзакции или версию браузера, вы быстро упретесь в «cardinality explosion» — взрывной рост количества временных рядов, который просто положит сервер.

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

Специализированные колоночные базы данных. Это золотой стандарт. Такие решения, как ClickHouse, позволяют хранить миллиарды событий с сотнями полей. Благодаря колоночному хранению, если вам нужно посчитать среднее время ответа, система прочитает только колонку duration, не трогая остальные данные.
Облачные Observability-платформы. Решения вроде Honeycomb или Lightstep изначально строились вокруг событийной модели. Они позволяют проводить глубокую аналитику (например, «покажи мне все события, где user_id из сегмента X столкнулся с ошибкой в версии Y»), но стоят приличных денег при больших объемах.
Распределённые системы сбора (Collectors). Чтобы доставить событие от приложения до базы, вам нужен эффективный агент. Я рекомендую использовать OpenTelemetry Collector. Он позволяет трансформировать, обогащать и фильтровать события прямо «на лету».

Если вы настраиваете сбор событий в своей домашней лаборатории, проще всего развернуть связку OpenTelemetry + ClickHouse через Docker Compose. Вот пример базового конфига для коллектора, который принимает данные и пересылает их дальше:

yaml
# otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:
    # Группируем события, чтобы не делать слишком много мелких запросов к базе
    send_batch_size: 1000
    timeout: 10s

exporters:
  clickhouse:
    endpoint: "tcp://clickhouse:9000"
    database: "observability"
    table: "wide_events"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [clickhouse]

Оптимизация стоимости хранения и передачи данных

Широкие события — это избыточность. Если в логах мы писали только ошибку, то в Wide Event мы пишем всё: от ID сессии до параметров окружения. Если не подойти к этому системно, место на дисках в вашем хранилище (будь то TrueNAS или выделенный сервер) закончится быстрее, чем вы успеете настроить алерты.

Чтобы сохранить предсказуемость расходов, я использую три стратегии:

1. Сэмплирование (Sampling). Вам не нужно хранить 100% успешных запросов. Если система работает штатно, достаточно 1–5% событий для построения графиков. Но как только фиксируется ошибка (HTTP 5xx или превышение latency), мы должны сохранять это событие целиком. В OpenTelemetry это реализуется через tail-based sampling, когда решение о сохранении принимается уже после того, как событие прошло через цепочку сервисов.

2. Агрегация на стороне коллектора. Вместо того чтобы отправлять каждое событие в базу, можно превращать поток событий в агрегаты. Например, вместо записи каждого чиха, коллектор может раз в минуту отправлять одно событие со статистикой: «за 60 секунд было 1000 запросов, средний latency 50мс, ошибок 0».

3. Жизненный цикл данных (TTL). Не все данные одинаково полезны в долгосрочной перспективе. Я придерживаюсь правила:

Детальные события (High Cardinality): храним 3–7 дней. Этого достаточно для отладки инцидентов.
Агрегированные метрики: храним 30–90 дней.
Бизнес-метрики (LTV, количество заказов): храним годами.

В ClickHouse это настраивается очень просто через механизм TTL. Например, можно автоматически удалять старые данные или перемещать их на более медленные и дешевые диски:

sql
-- Пример настройки TTL для таблицы событий
ALTER TABLE observability.wide_events
MODIFY TTL event_time + INTERVAL 7 DAY;

-- Или более сложный вариант: через 3 дня переносим на HDD, через 7 удаляем
ALTER TABLE observability.wide_events
MODIFY TTL event_time + INTERVAL 3 DAY TO VOLUME 'hdd_storage',
         event_time + INTERVAL 7 DAY;

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

Заключение

Практический итог

Переход от разрозненных метрик и логов к широким событиям — это не просто смена формата данных, а смена парадигмы. В классической схеме мы тратим слишком много времени на «склеивание» контекста: сначала видим всплеск на графике в Prometheus, потом идем в Grafana Loki искать логи по таймстампу, а затем пытаемся сопоставить это с трейсами в Jaeger. В процессе этого сопоставления часть информации неизбежно теряется.

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

Когда стоит внедрять этот подход

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

Критичные узлы. Начните с сервисов, которые находятся в центре вашей архитектуры (например, API-шлюзы или основные базы данных).
Смена формата логирования. Вместо того чтобы писать в лог текстовую строку, начните генерировать структурированный JSON.

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

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

text
2023-10-27 14:05:01 ERROR: User 123 failed to checkout. Connection timeout.

И как это превращается в Wide Event (в упрощенном JSON-виде):

json
{
  "timestamp": "2023-10-27T14:05:01.000Z",
  "event_type": "checkout_failed",
  "user_id": 123,
  "service_name": "order-processor",
  "version": "v2.4.1",
  "error_code": "ETIMEDOUT",
  "latency_ms": 5002,
  "db_host": "postgres-primary",
  "request_id": "a1-b2-c3-d4"
}

Разница очевидна: во втором случае у вас есть готовые измерения для построения любых графиков без дополнительного парсинга.

Что может пойти не так

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

Чтобы сохранить предсказуемость системы, придерживайтесь двух правил:

Селективность. Передавайте только те атрибуты, по которым вы реально будете делать фильтрацию или агрегацию. Не нужно пихать в событие весь дамп объекта пользователя.
Типизация. Следите за тем, чтобы типы данных в ключах были консистентными. Если в одном сервисе user_id — это число, а в другом — строка, ваши системы аналитики (вроде ClickHouse или Elasticsearch) начнут выдавать ошибки при индексации.

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

FAQ

Заменяют ли Wide Events привычные метрики полностью?

Не совсем. Wide Events не отменяют метрики, а меняют способ их получения. В классической схеме вы сначала считаете число (например, количество 500-х ошибок в Prometheus), а потом идете в логи, чтобы понять, почему они возникли. С широкими событиями вы сразу получаете и факт ошибки, и все её атрибуты: ID пользователя, версию приложения, конкретный инстанс и даже параметры запроса.

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

Как Wide Events помогают в отладке микросервисов?

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

Представьте, что ваш сервис «Пятачок» начал отдавать задержки. Вместо того чтобы искать в логах разрозненные строки, вы анализируете одно событие, которое содержит:

trace_id для связи с другими сервисами;
db_query_time для понимания нагрузки на базу;
container_id для проверки состояния конкретной ноды.

Если вы используете OpenTelemetry, процесс обогащения события выглядит как добавление атрибутов к текущему спану. Вот пример того, как это может выглядеть в коде на Go:

go
// Добавляем контекст к событию, чтобы оно стало "широким"
span := trace.SpanFromContext(ctx)
span.SetAttributes(
    attribute.String("user.tier", "premium"),
    attribute.String("region", "eu-central-1"),
    attribute.Int("items_in_cart", 5),
    attribute.Float64("request.latency_ms", 124.5),
)

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

Нужно ли менять текущий стек мониторинга для перехода на этот подход?

Переход не требует сноса всего, что вы строили годами, но потребует смены фокуса при выборе инструментов хранения и обработки данных. Классические TSDB (Time Series Databases), такие как Prometheus, заточены под хранение чисел и не умеют эффективно работать с высококардинальными данными (когда у вас миллионы уникальных комбинаций тегов).

Для работы с Wide Events вам понадобится база данных, которая умеет эффективно индексировать произвольные поля. Обычно это системы класса Observability Data Platforms, работающие по принципу колоночного хранения.

Если вы хотите начать внедрение постепенно, можно использовать связку из текущего стека:

Продолжайте собирать базовые метрики в Prometheus для алертинга по порогам.
Начните отправлять обогащенные события в ClickHouse или Elasticsearch.
Используйте Grafana для визуализации обоих типов данных в одном месте.

Для настройки отправки таких событий в формате JSON через системный демон (например, если вы используете Vector или Fluent Bit), конфигурация может выглядеть так:

toml
# Пример части конфига Vector для трансформации в широкое событие
[transforms.enrich_events]
type = "remap"
inputs = ["source_logs"]
source = '''
.user_id = parse_json!(.message).user_id
.error_code = .status_code
.service_name = "vinni-pukh"
.environment = "production"
'''

Это позволит вам плавно перейти от простого «мониторинга состояния» к полноценному «анализу поведения системы».

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

Чем Wide Events отличаются от обычных логов?

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

Можно ли заменить метрики широкими событиями?

Полностью заменить метрики не получится, так как они решают другую задачу — агрегацию огромных объёмов данных с минимальными затратами ресурсов. Метрики идеальны для построения графиков и обнаружения аномалий в реальном времени. Однако Wide Events позволяют получить ту глубину контекста, которой метрикам не хватает. Правильный подход — использовать метрики для алертинга, а широкие события — для быстрого понимания причин, когда алерт уже сработал.

Не станет ли хранение таких событий слишком дорогим?

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

Как начать переход на Wide Events в существующей инфраструктуре?

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