Наблюдаемость: распределённые трейсы, USE/RED и семплирование

p95 задержки утроилась за ночь с 80 мс до 240 мс. У вас есть логи балансировщика нагрузки, приложения и базы данных. Три лога, три часовых пояса, три grep-сессии. Без распределённых трейсов выяснить «куда делись 160 мс» занимает часы. С OpenTelemetry — 30 секунд: найдите span, который вырос, и у вас есть подозреваемый.

OpenTelemetry и W3C Trace Context

Современная наблюдаемость инструментирует каждый сетевой хоп с помощью общего идентификатора. Стандарт W3C Trace Context определяет два HTTP-заголовка:

• traceparent: 00-<16-байтовый trace-id>-<8-байтовый span-id>-<флаги> — глобально уникальный trace ID и ID текущего span.
• tracestate: специфичные для вендора метаданные (Datadog trace ID, флаги Jaeger и т.д.).

Каждый компонент на пути запроса — браузер, CDN edge (через Cloudflare Workers), балансировщик нагрузки, сервер приложений, вызов к базе данных, вызов внешнего API — читает входящий traceparent, создаёт дочерний span с новым span-id, выполняет работу, отправляет данные о времени и передаёт тот же trace-id в заголовках исходящих запросов.

Результат: backend наблюдаемости (Tempo, Jaeger, Honeycomb, Datadog APM) может отобразить весь запрос как каскад span — каждый хоп, каждая зависимость, каждый запрос к БД, каждый вызов внешнего API — с точным временем начала и длительностью. Поиск «куда делись 500 мс» сводится к просмотру самого длинного span.

Трейс 7a8f3c... длительность 587мс

span: HTTP request                              0–587мс (587мс)
span: DNS lookup                              0–4мс    (4мс)
span: TCP connect                             4–32мс   (28мс)
span: TLS handshake                           32–67мс  (35мс)
span: HTTP request send                       67–69мс  (2мс)
span: Server processing                       69–512мс (443мс)
  span: Auth middleware                       69–73мс  (4мс)
  span: Database query SELECT users           73–78мс  (5мс)
  span: Database query SELECT user_settings   78–82мс  (4мс)
  span: External API call third-party.com     82–489мс (407мс)
  span: Response serialisation                489–512мс (23мс)
span: HTTP response receive                   512–587мс (75мс)

Распространение через CDN edge

CDN edge-узлы (Cloudflare Workers, Fastly Compute, AWS CloudFront Functions) теперь поддерживают распространение трейсов. Когда запрос приходит на edge:

1. Edge читает traceparent из входящего запроса.
2. Создаёт edge-span со своим span-id.
3. Записывает время до первого байта от origin.
4. Передаёт traceparent (с оригинальным trace-id, span-id edge) на origin.

Результат: трейс показывает задержку CDN edge как отдельный span. Если edge span равен 5 мс, а origin span — 400 мс, понятно, что оптимизировать нужно origin, а не CDN. Без распространения трейсов видно только одно суммарное значение 405 мс и нужно угадывать разбивку.

Операционные фреймворки USE и RED

Два дисциплинированных фреймворка инструментирования предотвращают «расползание метрик» — сбор 500 метрик без понимания, какие из них важны.

Метод USE (Brendan Gregg) для ресурсов (CPU, память, диск, сетевые интерфейсы, пулы соединений):

• Utilization (Утилизация) — какая доля ресурса используется? (CPU 80%, пул соединений 95%)
• Saturation (Насыщение) — стоит ли работа в очереди из-за заполненности ресурса? (глубина очереди запросов, длина очереди run queue)
• Errors (Ошибки) — ресурс даёт сбои? (TCP-ошибки, ошибки диска, OOM kills)

Метод RED (Tom Wilkie) для сервисов (API, микросервисы):

• Rate (Частота) — сколько запросов в секунду?
• Errors (Ошибки) — какая доля возвращает ошибки?
• Duration (Длительность) — каково распределение задержки (p50, p95, p99)?

Использование обоих вместе. RED говорит что сломано (частота ошибок сервиса выросла). USE говорит почему (насыщение CPU вызвано CPU-bound обработчиком, или насыщение пула соединений из-за медленной БД). Вместе они сокращают MTTR с часов до минут.

Стратегии семплирования

Трассировка каждого запроса при 1 млн req/s производит терабайты данных трейсов в день — это запретительно дорого. Две стратегии балансируют полноту и стоимость:

Head-based семплирование. Решение о трассировке принимается при входе запроса — фиксированный процент (например, 1% запросов). Дёшево и детерминировано: trace-id несёт решение о семплировании, распространяемое на все нижестоящие компоненты. Недостаток: большинство ошибок и медленных запросов случается в 99%, которые вы не трассировали. Для ваших самых серьёзных инцидентов у вас нет трейсов.

Tail-based семплирование. Буферизировать все span в памяти, принимать решение после получения результата запроса:

• 100% запросов с ошибочным статусом (4xx, 5xx)
• 100% запросов с длительностью > порога (p99 cutoff)
• 0,1% быстрых успешных запросов (базовый уровень)

Реализуется OpenTelemetry Collector с процессором tail_sampling. Недостаток: требует буферизации всех span на время окна принятия решения (обычно 30–60 с), используя память пропорционально запросам в полёте. При 1 млн req/s с окном 30 с — 30 млн span в памяти, управляемо при правильном шардировании.

Адаптивное семплирование. Динамически регулирует частоту семплирования в зависимости от нагрузки или времени суток. Во время инцидентов повышает до 100% для трейсов ошибок; в тихие периоды снижает до 0,01%.

Правильный паттерн: head-based для базовых данных устойчивого состояния (дёшево); tail-based для ошибок + медленных запросов (гарантирует трейсы там, где важно); адаптивное для управления стоимостью при переменной нагрузке.