Wide Events и Observability 2.0: альтернатива трём столпам

В главе «Разница между мониторингом и наблюдаемостью» мы говорили про классическую рамку observability: метрики + логи + трейсы. Это так называемые «три столпа», которые преподают в каждой SRE-книге последние 15 лет.

Но есть подход, который в последние годы набирает силу и бросает вызов этой рамке. Его называют Wide Events, Observability 2.0 или Event-based observability. Идея простая: вместо трёх разных типов данных с разными инструментами — одно широкое событие со всем контекстом, которое само по себе отвечает на любой вопрос.

Что такое Wide Event

Wide Event — это одно структурированное событие, которое описывает какое-то значимое действие в системе (HTTP-запрос, запуск задачи, покупка, авторизация). В отличие от классического лога «время — уровень — сообщение», в Wide Event пишется всё, что может пригодиться для анализа:

{
  "event_type": "http_request",
  "timestamp": "2026-07-23T14:23:45.123Z",
  "request_id": "req_abc123",
  "trace_id": "trace_xyz789",

  // контекст пользователя
  "user_id": "user_456",
  "user_tier": "premium",
  "user_country": "RU",
  "user_signup_date": "2024-01-15",

  // контекст HTTP
  "http.method": "POST",
  "http.url": "/api/v2/payments",
  "http.status_code": 200,
  "http.latency_ms": 145,
  "http.user_agent": "Mozilla/5.0...",

  // контекст бизнеса
  "payment.amount": 1500,
  "payment.currency": "RUB",
  "payment.method": "card",
  "payment.merchant_id": "merchant_789",

  // контекст инфраструктуры
  "service.name": "payment-api",
  "service.version": "2.1.0",
  "deployment.environment": "production",
  "host.region": "eu-central-1",
  "k8s.pod": "payment-api-7d4b-abc",

  // технические детали
  "db.queries": 3,
  "db.total_ms": 45,
  "cache.hits": 2,
  "cache.misses": 0,

  // результат и мета
  "result": "success",
  "feature_flags.active": ["new_pricing_v2", "fast_checkout"]
}

Обратите внимание на количество полей. В классическом логе было бы: 2026-07-23T14:23:45Z INFO POST /api/v2/payments 200 145ms. Чтобы восстановить контекст, нужно идти в другие системы (метрики, трейсы, база пользователей). Wide Event даёт всё сразу.

Почему это меняет правила

С классическими тремя столпами вы попадаете в несколько ловушек:

1. Кардинальность при агрегации. Хотите посчитать конверсию по тиру пользователя? Нужно знать user_tier для каждого запроса. В Prometheus это label — а каждый уникальный label создаёт новую time-series. 10 тиров × 100 эндпоинтов × 5 статусов = 5000 series. Wide Events не агрегируют — событие либо есть, либо нет.

2. Корреляция между системами. Запрос пришёл от пользователя premium, пошёл через 4 микросервиса, дважды упал в retry. В классическом подходе вы склеиваете логи по request_id, метрики по service, трейсы по trace_id. Wide Event хранит всю картину в одном месте.

3. Запросы, которые не предусмотрели. Классика: SRE-инженер спрашивает «а сколько у нас запросов от пользователей из стран СНГ, которые используют новую фичу X, упали вчера с 5xx?». С метриками — нужно было заранее собрать эти лейблы. С Wide Events — просто фильтруешь по полям.

4. High-cardinality вопросы. Хотите посмотреть на конкретного пользователя? В Prometheus это невозможно. В Wide Events — WHERE user_id = 'user_456'.

Кто это продвигает

Главные сторонники подхода:

  • Charity Majors (бывший CTO Honeycomb) — главный евангелист идеи. Книга Observability Engineering (2022, O’Reilly) — манифест подхода
  • Honeycomb — компания, построившая бизнес на Wide Events
  • OpenTelemetry — стандарт движется в эту сторону, объединяя логи и спаны

Контраргументы обычно от людей, инвестировавших в классический стек (Prometheus + Grafana + Loki). Они говорят: «Wide Events — это просто структурированные логи, ничего нового». Частично правда — структурированные логи были всегда. Разница в подходе: не пишите тысячу разных типов событий, пишите несколько широких событий с полным контекстом.

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

Сценарий Классические три столпа Wide Events
Сбор данных Каждый сигнал через свой SDK/агент Один инструмент, один формат
Хранение Метрики в TSDB, логи в индексе, трейсы в Jaeger Все события в одной колоночной БД
Запрос «сколько ошибок у premium-пользователей из РФ за последний час?» Нужно заранее подготовить метрики по этим разрезам Один запрос с фильтрами по полям
Debug конкретного запроса Склеивать логи + трейсы + метрики по корреляционным ID Открыть одно событие — там всё
Стоимость хранения Дешёвая (агрегаты, индексы) Дорогая (хранить все события с полным контекстом)
Запросы к высокой кардинальности Невозможно Естественно
Real-time алерты на агрегатах Идеально подходит Тоже возможно, но дороже

Когда Wide Events работают лучше

  • Микросервисы с распределённой трассировкой — контекст теряется между сервисами, Wide Events склеивают
  • Продукты с разнообразными пользователями — нужна аналитика по разрезам, которые не предусмотреть заранее
  • Сложные бизнес-процессы — где важно понять «что случилось с заказом №X»
  • Высокая кардинальность — когда label-ы в Prometheus взорвут память

Когда классические три столпа лучше

  • Высокочастотные агрегаты — счётчики запросов в секунду, средняя latency. Wide Events для этого дороги.
  • Жёсткие бюджеты на хранение — Wide Events генерируют в разы больше данных.
  • Простые системы — если у вас 5 микросервисов и 100 RPS, классика дешевле.
  • Real-time алертинг по фиксированным метрикам — Prometheus alerting работает отлично, не надо менять.

Практический пример

Классический подход в Python:

# Метрика
metrics.counter("http.requests", tags={"method": "POST", "path": "/pay", "status": 200})

# Лог
logger.info(f"User {user_id} paid {amount} RUB")

# Трейс
with tracer.start_span("process_payment") as span:
    span.set_attribute("user_id", user_id)
    # ...

Wide Event подход:

event = {
    "event_type": "payment.processed",
    "timestamp": now_iso(),
    "request_id": request_id,
    "user.id": user_id,
    "user.tier": get_user_tier(user_id),
    "payment.amount": amount,
    "payment.currency": "RUB",
    "payment.result": "success",
    "service.name": "payment-api",
    "service.version": "2.1.0",
    "deployment.env": "production",
    "trace.id": trace_id,
}
structured_logger.info(event)  # один лог, всё в нём

Дальше это событие попадает в систему типа Honeycomb, ClickHouse с колоночным хранением или Datadog Events. Аналитик может задать любой вопрос: «сколько платежей от premium-пользователей из РФ упало вчера с 5xx?», «покажи все события для пользователя user_456 за последние 30 дней», «как изменилась конверсия после релиза 2.1.0?».

Инструменты для Wide Events

Инструмент Тип Когда подходит
Honeycomb SaaS с event-based storage Зрелый продукт, дорогой, идеален для старта
Datadog Events Часть Datadog APM Если уже используете Datadog
ClickHouse + Vector Open source self-hosted Дёшево, гибко, требует инженерных ресурсов
New Relic NRDB Часть New Relic Если уже используете New Relic
Tempo + Loki + Prometheus Open source классика Не Wide Events, но можно использовать Wide Events как структурированные логи

OpenTelemetry и Wide Events

OpenTelemetry исторически поддерживает три отдельных сигнала (traces, metrics, logs). В новых релизах движется к их объединению через концепцию Event — это сигнал, который может нести и span-данные, и метрики, и логи в одной сущности. До полной конвергенции ещё далеко, но направление задано.

Резюме

Wide Events — это альтернативная парадигма observability, где вместо трёх типов данных с разными инструментами используется одно широкое структурированное событие со всем контекстом. Подход особенно силён в микросервисных системах с разнообразной аналитикой.

Не нужно выбрасывать Prometheus. Классика остаётся для агрегатов и алертинга по фиксированным метрикам. Wide Events добавляются рядом для глубокой аналитики, debug сложных случаев и high-cardinality запросов. Это не «или/или», а «и/и».

Если вы только строите observability с нуля — подумайте, какой подход ближе вашей культуре и бюджету. Если у вас зрелый стек Prometheus + Loki + Jaeger — попробуйте Wide Events на одном новом сервисе, оцените пользу, и решайте по результатам.

См. также: «Разница между мониторингом и наблюдаемостью», «Телеметрия», «OpenTelemetry», «SLO как код».