OpenTelemetry готує стандарт передавання trace context між CLI, CI та дочірніми процесами

OpenTelemetry виніс у статус Release Candidate специфікацію передавання контексту через змінні середовища. Її мета — з'єднати в один trace операції, які проходять не через HTTP або брокер повідомлень, а через ланцюжок локальних процесів: CI runner запускає shell, shell викликає build tool, той створює тести чи допоміжні команди. Без спільного механізму кожен етап часто починає окремий trace, і оператор бачить розірвану картину.

Навіщо потрібен новий carrier

У distributed tracing propagator записує trace ID, span ID та інші поля у carrier, а наступний компонент читає їх і приєднує новий span до наявного trace. Для мережевого запиту таким carrier зазвичай є HTTP-заголовки. Але між батьківським і дочірнім процесом заголовків немає: найприроднішим каналом стає environment, який дитина успадковує під час запуску.

Специфікація визначає узгоджений спосіб упаковувати propagation fields у змінні середовища. Це дає різним мовним SDK, CLI-інструментам і workflow-системам спільну точку сумісності. Наприклад, wrapper у GitHub Actions зможе створити span, підготувати середовище, а запущений build tool — продовжити той самий trace без приватного формату інтеграції.

Де це може працювати

OpenTelemetry називає кілька практичних сценаріїв: shell scripts, GitHub Actions, Jenkins, Argo Workflows, batch jobs, data pipelines та command-line utilities на кшталт otel-cli. Особливо корисний підхід там, де один процес породжує багато коротких команд і потрібно зрозуміти не лише загальний час job, а й конкретну ділянку, яка створила затримку або помилку.

Стандарт не вмикає телеметрію сам по собі. Дочірній процес усе одно має створювати spans через SDK або інструментацію, а exporter — доставляти їх у backend. Environment carrier лише переносить батьківський контекст. Він також не замінює HTTP propagation, коли виконання переходить до іншого сервісу через мережу.

Чому Release Candidate, а не Stable

Автори вважають базовий формат достатньо зрілим, але збирають досвід реальних реалізацій перед стабілізацією. Потрібні відгуки від підтримувачів мовних SDK, авторів CLI та platform engineering команд: чи однаково працює успадкування у різних shell, як поводяться workflow runners, чи немає конфліктів із системами, які очищують або дозволяють лише визначений список environment variables.

Мінімальний період зворотного зв'язку триватиме до 2 листопада 2026 року і щонайменше 14 днів після останнього нового пов'язаного issue. Це означає, що формат уже можна тестувати, але production-команди не повинні сприймати його як незмінну довгострокову гарантію. Назви полів або деталі обробки ще можуть уточнюватися.

Безпека: контекст не є секретом, але може бути чутливим

Змінні середовища доступні всьому коду всередині процесу, а на деяких системах — також іншим процесам або користувачам із достатніми правами. Тому через propagation variables не можна передавати токени, паролі чи приватні ключі. Особливої уваги потребує baggage: розробники нерідко додають туди user ID, назву клієнта або інші бізнес-атрибути, які потім непомітно проходять через багато компонентів.

Отримувач має вважати propagation fields недовіреним вводом і передавати їх налаштованому propagator для перевірки. На межі довіри — наприклад, перед запуском коду з pull request або стороннього plugin — baggage краще фільтрувати, а в окремих сценаріях починати новий trace із link до попереднього замість прямого успадкування.

Контейнери та Kubernetes

Environment carrier не переходить автоматично між контейнерами або Pod. Змінні потрібно явно прокинути під час створення процесу чи workload, а це може суперечити декларативній моделі оркестратора. Для Kubernetes-завдань логічним місцем інтеграції можуть бути controller, operator або admission-механізм, але кожен такий варіант потребує окремого аналізу безпеки та життєвого циклу.

Так само не слід бездумно записувати propagation environment у логи діагностики. Trace ID зазвичай не є секретом, однак у поєднанні з іншими даними він може допомогти корелювати внутрішні події. Baggage узагалі варто обмежувати allowlist і коротким терміном життя.

Як перевірити специфікацію у своїй команді

• Виберіть один CI pipeline із кількома дочірніми процесами та зафіксуйте, де trace сьогодні розривається.
• Перевірте, чи підтримують environment carrier ваші мовні SDK або допоміжний CLI.
• Додайте allowlist полів і переконайтеся, що secrets та персональні дані не потрапляють у baggage.
• Протестуйте Linux, Windows і використовувані shell окремо, включно з очищенням environment у контейнерах.
• Змоделюйте недовірений pull request і перевірте, що він не може підмінити контекст або дописати небезпечні атрибути.
• Не фіксуйте RC-формат як незмінний внутрішній контракт до виходу Stable.

Практичний висновок

Нова пропозиція закриває давню прогалину observability: межа процесу не завжди є мережею, але trace context усе одно має пройти далі. Для CI/CD, data engineering і складних CLI-ланцюжків стандартизований environment carrier може замінити набір несумісних wrapper-скриптів. Головне обмеження — environment є широкодоступним каналом, тому успіх залежить не тільки від сумісності SDK, а й від суворої гігієни baggage та правильно визначених меж довіри.