Покращення спостережуваності асинхронного процесу в Dapr
Цей пост розповідає про те, як учасники спільноти хмарних технологій обʼєднали свої зусилля для вдосконалення інтеграції OpenTelemetry в Dapr, зокрема в частині асинхронних робочих процесів. У ньому також висвітлюються поточні зусилля з приведення Dapr у відповідність до семантичних домовленостей OpenTelemetry за допомогою OpenTelemetry Weaver та досліджується, як ця співпраця може стати корисним прикладом для інших проєктів CNCF. Жодна з цих робіт не починалася як офіційна ініціатива. Вона виникла в результаті обговорень, експериментів та спільної мети зробити телеметрію більш зрозумілою та послідовною в усій екосистемі.
Проблеми поширення трасувань у складних координованих процесах
Механізм робочого процесу Dapr забезпечує простий спосіб реалізації довготривалих, синхронного та асинхронного оркестрування. Оркестрування робочого процесу виконується всередині Dapr sidecar, тоді як код робочого процесу та активності виконується всередині застосунку за допомогою SDK Dapr. Комунікація між ними відбувається через потік gRPC з тривалим терміном існування.
Це ефективно, але ускладнює поширення контексту трасування W3C. HTTP та унарні виклики gRPC природно передають заголовки traceparent та tracestate з кожним запитом. Довготривалий потік цього не робить. Після відкриття потоку кроки робочого процесу не можуть додавати нові метадані. Це означає, що механізм робочого процесу може створювати відрізки з правильним контекстом всередині sidecar, але повідомлення про активність надходять у застосунок без батьківського контексту. Вихідні виклики в дії потім створюють власні трасування.
Результатом є фрагментація: відрізки робочого процесу, відрізки дій та відрізки на рівні користувача зʼявляються в бекенді трасування, але не утворюють цілісної ієрархії.
Ця діаграма ілюструє проблему: навіть якщо механізм робочого процесу створює відрізки, контекст розривається на межі потоку gRPC, тому код дії не може приєднатися до трасування робочого процесу.
Складність типового оркестрування робочих процесів
На перший погляд робочі процеси здаються простими, але коли ми починаємо їх відстежувати, стає очевидним, скільки в них рухомих частин. Робочий процес — це не один запит. Це тривала послідовність рішень і переходів між станами, кожна з яких може взаємодіяти з різними системами нижчого рівня. Деякі з цих взаємодій є синхронними, наприклад, коли дія звертається до зовнішньої служби і чекає на результат. Інші є асинхронними, наприклад, планування роботи, очікування зовнішніх сигналів або пауза до спрацьовування таймера. Ці відмінності мають значення, оскільки вони змінюють спосіб проходження запитів через систему і визначають, як має виглядати трасування.
Кожен робочий процес також має свою власну ідентичність. Ідентифікатор екземпляра робочого процесу концептуально повʼязує всі його етапи, навіть якщо вони розділені в часі. Робочий процес може тривати секунди або години. Він може бути відновлений після збою або продовжений після перезапуску сервера. Довготривале виконання означає, що механізм робочого процесу зберігає стан, відтворює події та просуває робочий процес, коли змінюються зовнішні умови. З погляду трасування це дуже відрізняється від звичайного запиту або фонового завдання. Одне виконання робочого процесу може охоплювати багато мережевих викликів, періодів очікування, повторних спроб і часткового прогресу.
Тому відстеження робочого процесу означає фіксацію як синхронних викликів, що виконуються негайно, так і асинхронних меж, де механізм робочого процесу планує або відновлює роботу. Це означає повʼязування коду користувача, що виконується в одному процесі, з логікою оркестрування, що виконується в іншому. А також означає збереження контексту незмінним через стійкі межі, щоб трасування відображало фактичний життєвий цикл робочого процесу, а не серію ізольованих операцій.
Ці характеристики роблять трасування робочого процесу складним завданням. Вони також роблять його цінним. Коли трасування точно відображає оркестрування, воно стає потужним інструментом для розуміння того, як робочий процес поводиться з часом і як його етапи впливають один на одного.
Відновлення контексту через межі робочого процесу
Для вирішення цієї проблеми були необхідні скоординовані зміни в декількох репозиторіях. Першим кроком було ввімкнення durabletask-go — бібліотеки, що використовується для відстеження оркестрування робочих процесів, — для серіалізації контексту W3C у повідомленнях про активність робочого процесу перед їх надсиланням через потік.
Завдяки вбудовуванню traceparent і tracestate безпосередньо в повідомлення про активність, механізм робочого процесу може поширювати контекст, не покладаючись на метадані gRPC для кожного повідомлення.
З боку застосунку durable task-java SDK було оновлено для зчитування цього контексту та його відновлення перед запуском коду дії. Версію цього можна побачити в дослідницькій гілці
Після відновлення контексту в застосунку автоматичне інструментування OpenTelemetry для Java стає ефективним. Оскільки агент OpenTelemetry Java бачить дійсний батьківський контекст, він може автоматично інструментувати вихідні HTTP-виклики та інші операції. Код застосування не потребує модифікації.
OpenTelemetry Operator відіграв важливу роль під час цих експериментів, автоматично вводячи Java-агент у контейнери застосунків робочого процесу. Це дозволило нам зосередитися на розумінні та вдосконаленні поширення контексту без ручного налаштування інструментарію.
Нарешті, середовище виконання Dapr було вдосконалено, щоб надати пріоритет чітким відносинам між батьківськими та дочірніми елементами робочого процесу з метою поліпшення зрозумілості для розробників. Потрібна подальша робота, щоб оцінити, де звʼязки між елементами можуть краще відображати певні асинхронні звʼязки.
Нова картина в Jaeger
Після того, як ці елементи були встановлені, поліпшення стало дуже очевидним при перегляді в Jaeger. Раніше вхідний запит, оркестратор робочого процесу та вихідні виклики кожної дії показувалися як окремі трасування.
Після змін водоспад Jaeger показує єдине безперервне трасування. Вхідний запит охоплює верхню частину. Під ним відображається оркестратор робочого процесу. Кожна дія вкладена в оркестратор робочого процесу. Вихідні виклики відображаються під відповідною дією.
Робочий процес нарешті виглядає як один цілісний життєвий цикл.
Безперервний водоспад робить не тільки структуру, але й темп робочого процесу легким для розуміння. Періоди очікування, повторні спроби, переходи між станами та тривалі операції відображаються саме там, де вони мають бути.
Від безперервності трасування до семантичної узгодженості
Після того, як робочі процеси Dapr почали генерувати повні трасування, виникли нові питання: що повинні представляти ці відрізки? І як їх слід називати? Dapr взаємодіє з багатьма компонентами, такими як таймери, сховища стану, брокери публікацій або підписки, привʼязки, секрети та API конфігурації. Без стабільної семантики різні SDK або компоненти середовища виконання можуть по-різному представляти подібні операції.
Щоб вирішити цю проблему, Dapr впроваджує OpenTelemetry Weaver, який дозволяє проєктам зберігати семантичні конвенції в машиночитному форматі. Цей початковий PR представляє Weaver для Dapr.
Weaver надає Dapr єдине місце для визначення атрибутів телеметрії для робочих процесів, взаємодій станів, викликів компонентів, доставки публікацій або підписок тощо. Це допомагає уніфікувати поведінку SDK і привести Dapr у відповідність до більш широкої семантичної моделі OpenTelemetry. Це лише початок впровадження, і ще потрібно попрацювати над приведенням у відповідність решти взаємодій Dapr.
Краще моделювання асинхронної поведінки
Переглядаючи вдосконалені трасування робочого процесу, ми також почали досліджувати, як Dapr може краще представляти асинхронне виконання за допомогою типів відрізків. Історично, механізм робочого процесу виводив майже всі відрізки, повʼязані з робочим процесом, як відрізки клієнта. Це відображає той факт, що механізм викликає операції, але не чітко виражає різницю між плануванням роботи та її фактичним виконанням. Ця відмінність стає більш важливою, коли трасування робочого процесу утворюють безперервну, читабельну ієрархію.
В асинхронних системах семантика продюсера часто надає чіткіший сигнал під час планування роботи, тоді як семантика споживача може відображати момент виконання цієї роботи. Вихідні виклики, зроблені всередині коду активності, залишатимуться клієнтськими відрізками, а внутрішні переходи робочого процесу залишатимуться внутрішніми відрізками. Такий підхід може допомогти інструментам трасування передавати поведінку робочого процесу більш природно.
Жодна з цих змін на сьогодні не є частиною Dapr. Це раннє дослідження, спричинене вдосконаленнями трасування, та напрямок, який ми почали обговорювати з розробниками Dapr. Мета полягає не в тому, щоб перепроєктувати телеметрію Dapr, а в тому, щоб почати формувати модель, яка більш точно відображає асинхронну поведінку та відповідає семантичним рекомендаціям OpenTelemetry. Ми очікуємо, що ця робота буде розвиватися спільно в міру залучення більшої кількості учасників.
Чому ця робота важлива для всієї екосистеми хмарних технологій
Хоча ця співпраця була зосереджена на Dapr, основні виклики присутні в багатьох хмарних проєктах. Проксі, сервісні мережі, маршрутизатори подій, механізми робочих процесів і контролери часто стикаються з подібними питаннями: як поширювати контекст W3C через sidecars або не-HTTP шляхи, як визначити семантичні домовленості, як моделювати асинхронну поведінку і як забезпечити узгодженість SDK.
Співпраця між проєктами допомагає вирішити ці проблеми. Подібні зусилля з удосконалення були зроблені в Linkerd і Traefik. Кожен новий проєкт, який відповідає семантиці OpenTelemetry, покращує загальний досвід операторів, які покладаються на сигнали від декількох компонентів.
Погляд у майбутнє
Зі зростанням популярності OpenTelemetry в середовищі CNCF, можливо, настав час для більш широкого обговорення в спільноті OpenTelemetry того, як найкраще підтримувати розробників проєктів. Багато хто хоче вдосконалити свою телеметрію, але не знає, з чого почати. Іншим потрібні рекомендації з таких тем, як типи відрізків, впровадження Weaver або моделювання асинхронних операцій.
Ця дискусія не обовʼязково має розпочинатися у формі офіційної робочої групи. Навіть неформальний простір може допомогти проєктам порівняти підходи, поділитися найкращими практиками та уникнути повторного винаходження моделей, які вже вирішені в інших місцях. Взаємодія між учасниками Dapr та OpenTelemetry показує, наскільки далеко може зайти співпраця, коли спільноти працюють разом.
Якщо ви підтримуєте або берете участь у проєкті CNCF і хочете посилити його інтеграцію з OpenTelemetry, запрошуємо вас долучитися до обговорення. Спільна телеметрія допомагає створювати розподілені системи, які є більш передбачуваними, зрозумілими та простішими в експлуатації.