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

Разбираем концепцию Wide Events: как отказ от разделения на метрики и логи помогает лучше понимать состояние распределённых систем и упрощает мониторинг.

Проблема классической триады observability

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

Проблема не в самих инструментах, а в том, как мы их разделяем. Мы привыкли собирать цифры в Prometheus, текст в Loki или Elasticsearch, а связи между ними пытаться выстроить вручную в голове или через сложные дашборды. В распределённой среде, где один запрос проходит через пять микросервисов, такой подход создаёт иллюзию контроля, которая рассыпается при первом же серьёзном сбое.

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

Основная беда классического подхода — потеря контекста при переходе от «что происходит» к «почему это происходит».

Метрики — это агрегаты. Они идеальны для того, чтобы заметить аномалию. Например, вы видите на графике в Grafana, что процент ошибок 5xx на вашем Nginx резко подскочил. Это сигнал: «Что-то не так». Но метрика не скажет вам, какой именно пользователь вызвал ошибку или с какими параметрами пришёл запрос. Чтобы понять причину, вам нужно переключиться на логи.

И вот здесь начинается главная сложность. Чтобы найти нужную запись в логах, вам нужно сопоставить временную метку из метрики с временными метками в лог-системе. Но время в распределённых системах — штука коварная. Даже минимальный дрейф часов между нодами или разница в точности записи (миллисекунды против микросекунд) заставляет вас тратить драгоценное время на «поиск иголки в стоге сена».

Представьте типичную ситуацию:

В Prometheus вы видите всплеск http_requests_total{status="500"}.
Вы идте в систему сбора логов.
Вы пытаетесь отфильтровать логи за тот же период, но из-за того, что логи пишутся асинхронно, вы видите либо слишком много лишнего, либо вообще не попадаете в момент ошибки.

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

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

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

Допустим, у вас есть сервис, который работает в Docker. Вы используете стандартный стек: Prometheus для сбора метрик контейнера и Fluent Bit для отправки логов.

yaml
# Пример типичного docker-compose для сервиса
services:
  app:
    image: my-app:latest
    logging:
      driver: "json-file" # Логи пишутся в файлы на диске
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M

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

В распределённых системах, описанных в концепции Observability Engineering, такая корреляция становится невозможной без внедрения сквозных Trace ID. Однако даже с трейсингом вы сталкиваетесь с проблемой «разных миров»:

Метрики — это числовые ряды (Time Series).
Логи — это неструктурированный или полуструктурированный текст.
Трейсы — это графы вызовов.

Когда происходит сложный каскадный сбой, инженер вынужден постоянно переключать контекст между разными интерфейсами. Вы смотрите на график нагрузки на CPU, потом на график задержек (latency), потом в логи приложения, потом в системный журнал journald, чтобы проверить, не упал ли какой-нибудь системный демон.

Вместо того чтобы анализировать причину сбоя, вы тратите 80% времени на то, чтобы просто синхронизировать данные из разных источников и убедиться, что вы смотрите на одну и ту же проблему, а не на её следствие в другом сервисе. Это и есть главная неэффективность классической триады: она даёт много данных, но крайне мало связей между ними.

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

Когда я только начинал администрировать серверы, мониторинг представлялся мне набором разрозненных инструментов. У нас были метрики в Graphite, чтобы смотреть на загрузку CPU, текстовые логи в ELK для поиска ошибок и трейсы, чтобы понять, где застрял запрос. Проблема в том, что эти данные живут в разных мирах. Вы видите всплеск Latency на графике, идете в логи, но не можете быстро сопоставить конкретный запрос с тем самым графиком.

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

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

Традиционный подход заставляет нас разделять данные. Метрика — это число (например, http_requests_total), лог — это строка текста, а трейс — это цепочка спанов. В распределённой системе, где один запрос проходит через пять микросервисов, восстановить полную картину по этим разрозненным кускам — задача не из лёгких.

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

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

json
{
  "timestamp": "2023-10-27T10:15:30.005Z",
  "event_type": "http_request",
  "trace_id": "a1b2c3d4e5f6",
  "duration_ms": 142,
  "status_code": 200,
  "user_id": "user_882",
  "service_name": "auth-service",
  "container_id": "docker_container_xyz",
  "region": "eu-central-1",
  "error": null
}

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

Преимущества единого формата данных

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

Во-первых, это устраняет проблему корреляции. В классической схеме вам нужно вручную сопоставлять временные метки в логах с точками на графиках метрик. В случае с Wide Events корреляция вшита в сам формат данных. Если у вас упала производительность, вы просто фильтруете события по полю duration_ms > 500 и сразу видите, какие именно параметры (например, конкретный container_id или версия базы данных) коррелируют с задержкой.

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

В-третьих, это обогащение контекстом. В обычных метриках крайне дорого и сложно хранить высококардинальные данные (high cardinality), такие как user_id или order_id. Если вы попытаетесь добавить user_id в Prometheus, вы быстро получите взрывной рост потребления памяти из-за количества временных рядов. Wide Events решают эту проблему, так как они предназначены для хранения структурированных данных, а не только для агрегации счетчиков.

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

python
import logging
import json

# Настройка логгера для вывода JSON
logger = logging.getLogger("wide_events")
handler = logging.StreamHandler()
formatter = logging.Formatter('%(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)
logger.setLevel(logging.INFO)

def log_event(event_data):
    # Мы передаем не строку, а словарь, который превращается в JSON
    logger.info(json.dumps(event_data))

# Пример использования в обработчике запроса
log_event({
    "event": "request_processed",
    "duration_ms": 45,
    "path": "/api/v1/login",
    "user_id": "12345",
    "status": 200
})

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

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

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

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

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

Идентификация: trace_id, span_id, request_id. Это позволяет связать событие с конкретным запросом в распределённой системе.
Контекст окружения: версия приложения, ID контейнера, имя ноды (например, мой Vinni-Pukh), версия конфигурации.
Бизнес- и технические атрибуты: ID пользователя, тип операции, время выполнения, статус и, самое важное, все параметры, которые раньше разлетались по разным метрикам.

Вместо того чтобы отправлять в Prometheus отдельный счетчик http_requests_total{method="POST", endpoint="/api/v1/order", status="201"}, мы формируем один JSON-объект.

Пример структуры типичного Wide Event для API-шлюза:

json
{
  "timestamp": "2023-10-27T14:20:01.452Z",
  "event_type": "http_request",
  "trace_id": "a1b2c3d4e5f6g7h8",
  "service": "api-gateway",
  "node": "Vinni-Pukh",
  "duration_ms": 124,
  "status_code": 201,
  "method": "POST",
  "path": "/api/v1/order",
  "user_id": "user_9921",
  "order_value": 1500.50,
  "region": "eu-central-1",
  "app_version": "v2.4.1"
}

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

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

Традиционный стек (Prometheus + ELK) плохо подходит для Wide Events, потому что он заставляет нас разделять данные. Prometheus не переварит высокую кардинальность (high cardinality), если вы попытаетесь запихнуть в него user_id, а Elasticsearch может стать слишком дорогим при хранении огромного объёма сырых данных.

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

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

Пример конфигурации Vector, который принимает данные по HTTP, добавляет к ним метку хоста и отправляет в ClickHouse:

toml
# Принимаем события через HTTP
[sources.api_events]
type = "http_server"
address = "0.0.0.0:8080"

# Обогащаем событие системными данными
[transforms.add_metadata]
type = "remap"
inputs = ["api_events"]
source = '''
.node = get_hostname()
.ingested_at = now()
'''

# Отправляем в ClickHouse
[sinks.clickhouse_out]
type = "clickhouse"
inputs = ["add_metadata"]
endpoint = "http://clickhouse-server:8123"
database = "monitoring"
table = "wide_events"
compression = "gzip"

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

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

Когда Wide Events избыточны

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

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

Простые монолитные приложения. Если у вас один сервис, работающий на одной ноде, разделение на метрики (сколько запросов в секунду) и логи (что именно пошло не так) работает идеально. Вам не нужно тянуть тяжелую инфраструктуру для сбора контекстных событий, чтобы понять, что база данных недоступна.
Ограниченные ресурсы на периферии. Если вы используете Raspberry Pi для сбора данных с датчиков или в качестве легкого шлюза, отправка развернутых JSON-событий с десятками полей быстро забьёт канал связи и съест весь ресурс CPU. В таких случаях лучше оставить классические Prometheus metrics, которые весят считанные байты.
Системы с экстремально высокой частотой событий. Если ваш сервис обрабатывает миллионы мелких транзакций в секунду, попытка превратить каждую из них в «широкое событие» с полным контекстом приведет к взрывному росту объёмов хранения.

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

Итоговая оценка эффективности

Если мы сравним традиционный подход и концепцию Wide Events, то увидим, что мы меняем экономию на предсказуемость.

В классической схеме вы часто сталкиваетесь с «разрывом контекста». Вы видите на графике Grafana резкий скачок 500-х ошибок (метрика), переходите в Loki, чтобы найти логи, и пытаетесь по request_id сопоставить их с трейсами в Tempo. Это требует времени и настройки связей между тремя разными типами данных.

С Wide Events вы получаете единую точку правды. Одно событие содержит в себе и факт ошибки, и параметры запроса, и состояние системы в этот момент.

Для оценки эффективности можно использовать простую таблицу:

Характеристика	Традиционный стек (Metrics + Logs + Traces)	Подход Wide Events
Сложность настройки	Высокая (нужна корреляция ID)	Средняя (нужен единый формат)
Объём данных	Низкий (метрики компактны)	Высокий (каждое событие детально)
Скорость расследования	Зависит от качества связей	Максимальная (всё в одном месте)
Стоимость хранения	Прогнозируемая	Растущая вместе с трафиком

С точки зрения системного инженера, Wide Events — это переход от «сбора улик» к «записи показаний бортового самописца». Это делает отладку распределённых систем, таких как мой кластер на Proxmox, гораздо менее хаотичной.

Чтобы подготовить систему к такому формату, важно сразу определить структуру события. Например, в конфигурации вашего коллектора (допустим, это OpenTelemetry Collector) важно настроить фильтрацию, чтобы не отправлять лишний мусор:

yaml
# Пример части конфигурации OpenTelemetry Collector
processors:
  attributes:
    actions:
      - key: deployment.environment
        value: "production"
        action: insert
      - key: node.name
        # Добавляем имя ноды для предсказуемости при поиске
        value: ${env:NODE_NAME}
        action: insert

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [attributes, batch]
      exporters: [loki, tempo] # Направляем обогащенное событие в хранилище

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

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

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

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

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

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

Можно ли внедрить Wide Events в уже существующую инфраструктуру?

Переход не обязательно должен быть одномоментным и радикальным. Можно начать с обогащения наиболее критичных участков системы, например, на уровне API Gateway или ключевых микросервисов. Сначала вы внедряете структурированный формат событий для самых важных транзакций, а затем постепенно заменяете ими классические метрики и логи по мере того, как команда привыкает работать с единым контекстом.

Позволяют ли Wide Events заменить системы мониторинга вроде Prometheus?

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