Пользователь видит медленное сохранение, а каждый сервис по отдельности выглядит здоровым. API ответил быстро, очередь приняла сообщение, обработчик не упал. Но между этими наблюдениями потерялось главное: относятся ли они к одному действию и где прошло время?
Трассировка помогает связать работу в разных процессах. OpenTelemetry описывает propagation как передачу контекста, по которому сигналы можно сопоставить между границами сервисов. Контекст запроса нужно явно передать через транспорт, а принимающая сторона должна его извлечь. OpenTelemetry: context propagation
Начать с пользовательского действия
Возьмём учебный экспорт отчёта. Пользователь запускает его в браузере, API создаёт задание, рабочий процесс собирает файл, интерфейс показывает ссылку. Простого времени ответа POST недостаточно: для человека действие заканчивается, когда файл доступен.
На схеме полезно разделить длительности: приём запроса, ожидание в очереди, собственно вычисление и публикация результата. Если файл готовится двадцать секунд, а девятнадцать из них задание ждёт свободного исполнителя, оптимизация SQL внутри последней секунды почти не изменит пользовательское ожидание. Это условный пример, но он задаёт правильный вопрос к измерениям.
Корневое действие и дочерние участки работы получают собственные идентификаторы. Не следует заменять ими идентификатор заказа или пользователя: бизнес-сущность живёт дольше одного запроса и может участвовать в нескольких независимых операциях.
Где передавать контекст
Для HTTP стандарт W3C задаёт заголовки traceparent и tracestate. В traceparent есть идентификаторы трассы и родительского участка, а также флаги. Формат и проверка допустимых значений определены стандартом; вручную собирать рабочую реализацию парсера обычно незачем. W3C Trace Context
Учебный заголовок без реальных пользовательских данных:
traceparent: 00-0123456789abcdef0123456789abcdef-0123456789abcdef-01У очереди нет обязательного HTTP-заголовка: контекст помещают в согласованные метаданные сообщения и извлекают на стороне обработчика. Важно проверить это в используемой библиотеке. Наличие трассировки в веб-фреймворке не доказывает, что она автоматически проходит через конкретный брокер и фоновый исполнитель.
Отдельно рассматривают пакетную обработку и повторные попытки. Если один запуск собирает несколько событий, выбор причинной связи должен отражать реальную работу. Искусственно приклеить все задания к последнему HTTP-запросу означает получить красивую, но неверную картину.
Не складывать всё в baggage
Baggage позволяет переносить дополнительные пары ключ–значение, но эти значения могут уйти дальше по цепочке. OpenTelemetry прямо рекомендует не помещать туда credentials, ключи и персональные данные. OpenTelemetry: baggage
В учебном экспорте достаточно технического признака типа задания и разрешённых атрибутов. Полный фильтр отчёта, email заказчика или содержимое документа не становятся безопасными оттого, что попали в телеметрию. Для каждой группы атрибутов стоит определить назначение, круг получателей и срок хранения.
Контекст от внешнего клиента также не является удостоверением личности. Пользовательский trace ID помогает корреляции, но не даёт права читать чужую трассу или менять внутренние решения сервиса.
Проверить сквозной сценарий
Запускают одну операцию на синтетических данных и находят её путь через API, очередь и обработчик. Затем создают две параллельные операции: их события не должны смешиваться из-за неверного хранения контекста между задачами.
В сценарии с повтором проверяют, видны ли отдельные попытки и причина задержки. При отключённом сборщике телеметрии основная работа приложения должна вести себя по заранее выбранной политике, а не зависать неожиданно на отправке наблюдений.
Наконец, трасса не заменяет весь мониторинг. Одна сохранённая история хорошо объясняет конкретный случай; для оценки частоты проблемы нужны агрегированные показатели. Полезная наблюдаемость связывает эти уровни и позволяет перейти от общего ухудшения к проверяемой истории запроса.