Англійська для розробників Jaeger Tracing

Розмови Jaeger відбуваються переважно під час зневадження інциденту, коли запит перетинає декілька служб і жоден журнал не розповідає всю історію, тому словник зосереджений на діапазонах, контексті трасування і компромісах з вибіркою.

Ключовий словник

** Спектр ** — одна операція з часовим інтервалом у межах трасу, що представляє одну одиницю роботи (виклик функції, запит бази даних, запит HTTP) з часом початку, тривалістю і пов’ язаними метаданими. “Додати діапазон навколо цього виклику бази даних — зараз батьківський діапазон показує лише « повільно », і ми не можемо сказати, чи це сам запит, чи щось інше всередині цього блоку.”

** Trace ** — повна збірка проміжків часу, що відображає шлях одного запиту у всіх службах, до яких він звертався, що надає вам змогу побачити від початку до кінця, на що було витрачено часу. “Відстежити цей повільний запит — замість того, щоб вгадувати, яка служба за це відповідає, ми можемо побачити, який саме проміжок часу спожив чотириста мілісекунд.”

** Розповсюдження контексту трасування ** — передавання ідентифікаційних даних трасування (ІД трасування, ІД діапазону) між службами за допомогою заголовків, таким чином діапазони, створені різними службами, буде зв’ язано у єдиний послідовний трасування. “Ця служба не поширює контекст трасування на виклики нижче по течії — саме тому її діапазони показуються як від’ єднаний, окремий трасування замість частини початкового.”

** Вибірка ** — практика запису лише підмножини трас (а не кожного окремого запиту) для керування обсягом зберігання і швидкістю роботи трасування у масштабі. “Ми вибираємо один відсоток, тому цей конкретний повільний запит з повідомлення про помилку не вказано в Jaeger — тимчасово збільште частоту, або додайте вибірку на основі хвоста, яка завжди зберігає помилки.”

** Критичний шлях ** — послідовність обсягів у межах трасування, яка безпосередньо визначає загальну затримку запиту, на відміну від обсягів, які виконувалися паралельно і не додавали до загального часу. “Ці два проміжки працювали паралельно, отже жоден з них не знаходиться на критичному шляху — фактична вузька місцина це послідовний проміжок, який чекає на завершення обох з них, перш ніж він може початися.”

Звичайні фрази

• Чи можете ви додати проміжок часу навколо цього конкретного виклику, щоб ми могли ізолювати, куди насправді йде час?»
• Чи це єдиний слід, чи контекстне поширення десь розірвало його і розділило на дві частини?»
• «Чи ми вибираємо це на достатньо високому рівні, щоб дійсно вловити запит в звіті про помилку?»
• Чи є ця лінія на критичній траєкторії, чи вона проходить паралельно з чимось іншим?»

Приклади висловлювань

Зневадження повільного запиту: “Трак показує, що цей один проміжок часу займає триста мілісекунд сам по собі - це справжнє вузьке місце, все інше в запиті порівняно швидко.”

Діагностика пошкодженого сліду: “Розмахи цієї служби не з’ являються під батьківським трасуванням — перевірте, чи дійсно вона поширює заголовок контексту трасування на виклик нижче.”

Обговорення стратегії вибірки: “Фіксований відсоток вибірки на рівні одного відсотка означає, що ми пропускаємо більшість помилок, оскільки помилки за визначенням рідкісні — перейти на вибірку за хвостом, щоб ми завжди зберігали сліди, які закінчилися невдачею.”

Професійні поради

• Заохочуйте розробників додавати ** розділи ** навколо певних підозрілих операцій, а не лише на межі служби — грубі розділи приховують саме ті деталі, які потрібні для інциденту.
• Діагностуйте від’ єднані або часткові трасування, спочатку перевіривши ** розширення контексту трасування ** — найпоширенішою причиною є відсутність заголовка на межі служб.
• Використовувати розумніші стратегії ** вибірки ** (наприклад, вибірку за допомогою хвоста, яка завжди зберігає помилки і повільні запити) замість наївної вибірки з фіксованою частотою, яка має тенденцію пропускати сліди, які вам насправді важливі.
• Навчайте команди визначати критичний шлях у трасі перед оптимізацією — проміжки, які працюють паралельно, не варті таких же зусиль з оптимізації, як послідовне вузьке місце.

Практичні вправи

1. Поясніть співробітнику команди, чому груба межа на межі служби приховує подробиці, необхідні для зневадження інциденту.
2. Описати, як виглядає пошкоджене поширення контексту слідування у Jaeger і як його виявити.
3. Напишіть речення, у якому буде запропоновано вибірку за допомогою хвоста замість наївної фіксованої частоти вибірки.

Наприклад, мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова

Будьмо чесними - вивчення технічної англійської, особливо навколо таких інструментів, як Jaeger, може бути приголомшливим. Це не просто про те, щоб знати * визначення * “span” або “trace”; це про створення чітких, коротких повідомлень, які передають критичну інформацію вашій команді, особливо коли час обмежений і рівень розчарування високий. Для не-рідних носіїв, це може бути поєднано з тонкими відмінностями у фразування, немовлених очікувань навколо формальності, і властивою складністю опису розподілених систем.

Одна поширена перешкода виникає під час перегляду коду. Уявіть, що ви отримуєте коментар на кшталт: « Цей діапазон не корельований належним чином — досліджуйте ». Хоча це здається простим, але в ньому бракує контексту. Ефективнішим підходом було б: «Я помітив, що тривалість цього проміжку значно довша, ніж очікувалося; чи можете ви переглянути логіку в межах функції process_request, щоб переконатися, що вона збігається з загальним потоком слідування і що ми захоплюємо всі необхідні події?» Зауважте, як додавання деталей - посилання на конкретну функцію і пов’язання її з * слідування * - перетворює потенційно неясну критику в діючу зворотну зв’язок. Аналогічно, в розмовах Slack, уникайте простого зауваження «Jaeger повільний». Замість цього спробуйте: «Я бачу підвищену затримку в сліді user_authentication сервісу. Чи можемо ми дослідити потенційні вузли або обмеження ресурсів? “Додання конкретних деталей - назви служби і метрики (затримки) - негайно прояснює проблему.

Іншою областю, де нюанс має значення, є написання описів PR. Просте твердження, наприклад, «Виявлено проблеми з розширенням Jaeger», не надає достатньої інформації для оцінювання впливу. Краще описати це так: «Впроваджено поліпшену вибірку в рамках служби payment_processing, щоб зменшити обсяг слідування і поліпшити кореляцію з навколишніми службами. Ця зміна вирішує проблему високої затримки потоку checkout, про яку раніше повідомлялося за допомогою Jaeger, зокрема, покращує видимість діапазонів, пов’ язаних з перевіркою картки. ” Це детальний опис дозволяє рецензентам зрозуміти * чому * ви внесли зміни і як вони пов’ язані з більш широкими проблемами продуктивності.

Також важливо розуміти, що прямі переклади часто не спрацьовують при описі складних розподілених систем. Такі поняття, як «аналіз кореневої причини» або «відстеження від початку до кінця» можуть бути важко передати точно, тому зосередження на * результаті * - зменшення затримки, ідентифікація вузьких місць - часто є більш ефективним, ніж жорстко дотримуватися буквального перекладу. Не бійтеся запитати про пояснення, якщо ви не впевнені, як щось було виражено; більшість досвідчених розробників оцінять ваші зусилля зрозуміти і ефективно спілкуватися.

# Example Jaeger CLI command to filter traces based on service name
j extract --service "payment_processing" -o trace.zip

Ця команда демонструє практичне використання термінології - фільтрування за service ім’ям - в екосистемі Jaeger, яка часто обговорюється при зневадженні проблем з продуктивністю розподілених систем.