Наблюдаемость незаметно становится одной из самых дорогих статей инфраструктуры: один label с user_id взрывает кардинальность метрик, debug-логи растут гигабайтами, трейсы пишутся на 100%. Откуда берётся стоимость каждого столпа, как её резать без потери сигнала (сэмплинг, агрегация, дропы в пайплайне), и почему wide events («observability 2.0») меняют компромисс между кардинальностью и пользой
Проброс контекста и сэмплинг — только половина трейсинга; вторая в том, что трейс это структурированные данные, из которых можно извлечь больше, чем waterfall. Дизайн спанов и семантические конвенции OTel, span-метрики (RED прямо из трейсов через spanmetrics), exemplars — прыжок из всплеска метрики в конкретный трейс, и trace-based SLO. Как перестать инструментировать вслепую
Метрики по делу: типы (counter/gauge/histogram), методологии RED и USE, кастомные бизнес-метрики через OTel Metrics, PromQL и главная ловушка Prometheus — кардинальность лейблов. Экспорт OTel в Prometheus. Практика на Go и Java.
Распределённый трейсинг держится на одном: контекст должен пережить каждую границу. Разбираем W3C trace context дословно с провода, проброс через HTTP, PostgreSQL и NATS, два воспроизводимых разрыва трейса, head- и tail-семплинг с фактическими долями и две ловушки TraceQL, которые дают правдоподобные неверные числа.
Как инструментировать сервисы через OpenTelemetry: разделение SDK и API, три сигнала, auto- и manual-инструментализация, spans и context propagation, экспорт в Collector по OTLP. Практика на Go (SDK + slog-bridge) и Java (OTel-агент), с замерами накладных расходов на живом стенде.
Vector, OpenTelemetry Collector и Fluent Bit на одном потоке логов: ресурсы, цена трансформации, потери при отказе бэкенда, приём OTLP-трейсов — и во что обходится связка Vector → Collector по OTLP
Зачем нужен отдельный слой сбора телеметрии, как Collector устроен, сколько ресурсов потребляет, какие deployment-паттерны бывают, типичные ошибки и когда он действительно оправдан
