Observability 2.0: широкие события и сдвиг стоимости

Команда из 40 сервисов тратит два инженер-недели в квартал на cardinality budget’ы и три часа на инцидент на кросс-pillar переходах. Инженерная стоимость трёх отдельных observability backend’ов теперь превышает SaaS-счёт единого. Pillar’ы были не ошибкой — они были оптимальными по стоимости до 2020 года.

Критика 2.0

Чарити Майорс (сооснователь Honeycomb, инженер, поставивший «observability» на карту для distributed systems в 2017) утверждает в блог-серии 2024–2025: три pillar’а — не естественная таксономия — они артефакт ограничений хранилищ конца 2000-х.

• Метрики существовали, потому что нельзя было позволить хранить каждое событие.
• Логи существовали, потому что их нельзя было агрегировать при чтении.
• Трейсы существовали, потому что ни один из двух других не нёс кросс-сервисную причинность.

При columnar storage engine’ах, дешёвом объектном хранилище ($0,023/ГБ в S3) и современных query planner’ах все три сворачиваются обратно в одну форму: широкие структурированные события — одна запись на единицу работы, несущая каждое поле включая high-cardinality (user_id, build_sha, feature_flag_state, region), хранимая в одном columnar engine, запрашиваемая с произвольной нарезкой.

Продукт Honeycomb — это оно. ClickHouse-based стеки (Signoz, новый backend Sentry, внутренний стек Cloudflare) — это оно. Пост Honeycomb «OpenTelemetry Is Not Three Pillars» явно переосмысливает OTel-сигналы как «способы отправлять и хранить единую underlying модель телеметрии».

Что меняется на инженерном уровне

В 1.0 стеке каждый запрос эмитит в три места:

• Инкременты counter’ов → metric SDK
• Лог-строки → log SDK
• Span’ы → trace SDK

Каждый сигнал сэмплируется или агрегируется по-разному, поля денормализованы, и join между ними зависит от последовательного добавления shared join-ключей. Три billing-метра, три операционные поверхности.

В 2.0 стеке каждый запрос эмитит одно широкое событие на границу сервиса — JSON-запись со всеми атрибутами (user_id, route, status, duration, build_sha, feature_flags, trace_id) — и backend вычисляет метрики через GROUP BY при запросе, получает логи фильтрацией, восстанавливает трейсы join’ом по trace_id. Columnar engine делает все три запроса быстрыми поверх одних данных. Cardinality в 2.0 больше не является драйвером стоимости — это главный сдвиг.

Решение о миграции

Архитектура 2.0 не является универсально превосходящей. Senior-вопрос: «жизнеспособна ли cost-база 2.0 для моей нагрузки?»

2.0 побеждает когда:

• Перерасходы cardinality budget’а стоят больше инженерных часов, чем экономит счёт
• Фрустрация кросс-pillar переходов тормозит реагирование на инциденты
• Объём трафика и архитектурный sprawl — главные драйверы стоимости, не форма хранения

1.0 побеждает когда:

• Очень долгий retention (5+ лет) для low-cardinality метрик — предагрегация трудно превзойти на cold storage
• Сильное предпочтение open-source, избегая SaaS vendor lock-in
• Бюджет доминируют метрики, а не объём логов или трейсов

Многие используют оба: 2.0 backend для реагирования на инциденты и ad-hoc вопросов, 1.0 metrics tier (Prometheus + remote storage) для 5-летних SLO trend дашбордов и регуляторной отчётности.

Путь миграции — dual-write, а не rip-and-replace: направить OTel exporters на оба backend’а на 60–90 дней, строить 2.0 дашборды рядом с 1.0, выводить 1.0 только после того как каждая команда перевела свои on-call runbook’и.