Налаштування розподіленого трасування через Jaeger: інструментування та розгортання

Чому трасування губиться: що ламається без Jaeger

У розподіленій системі один запит проходить через шлюз, кілька сервісів, чергу та базу.

Але спільної нитки між ними немає: ідентифікатор запиту не передається далі ланцюжком, мітки часу на різних вузлах розходяться, а частина викликів іде асинхронно і взагалі не потрапляє до логу сторони, що викликає. Зібрати з цього шлях запиту неможливо — можна лише припускати, де він зламався.

Далі починається перебір гіпотез. Інженер дивиться метрики, піднімає логи сервісів по черзі, вручну зіставляє часові вікна — і все одно не бачить, на якому саме переході запит деградував.

Загублені трейси означають, що рідкісний, але регулярний збій відтворюється через раз, а причина залишається непрямим припущенням.

Ціна такої діагностики збоїв — не лише години чергового. Поки джерело не знайдено, зростають затримки, накопичуються помилки на стороні клієнтів, а зміни вносяться навмання: правка, яка «мала допомогти», закриває симптом і маскує причину.

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

Що дає наскрізне трасування розподіленої системи

У розподіленій системі один запит проходить через кілька сервісів, і при збої логи показують лише фрагменти: видно, що сервіс відповів довго, але не видно, через що.

Спостережуваність без наскрізного трасування впирається в ручний перебір сервісів, а кожна хвилина пошуку — це хвилина недоступності.

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

Інженер відкриває конкретний повільний запит і бачить вузьке місце за часом і обсягом звернень — без перебору сервісів вручну.

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

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

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

Режими розгортання Jaeger: порівняння варіантів

Вибір режиму розгортання визначає не лише те, як швидко трейс потрапляє в інтерфейс, а й скільки ресурсів закладати в кластер і як розводити середовища.

Саме інструментування сервісів від цього не залежить, а ось сховище трейсів, відмовостійкість і масштабування — залежать повністю. Нижче — варіанти, між якими реально вибирають на старті та при зростанні потоку спанів.

Колектор не зберігає стан: його екземпляри масштабуються горизонтально за балансувальником, а агент на кожному вузлі буферизує спани й переживає перезапуск. Відмовостійкість впирається в сховище — репліки та кворум налаштовуються на стороні бази, а не на стороні трасування.

Ізоляцію середовищ краще робити окремими інстансами колектора й окремими індексами на середовище, інакше тестовий потік розмиває вибірку та роздуває обсяг зберігання.

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

Впровадження Jaeger: етапи інженерної роботи

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

1. Обстеження сервісів і точок входу. Фіксуємо список сервісів, протоколи обміну та місця, де губиться контекст: черги, фонові завдання, зовнішні виклики. На виході — карта, за якою видно, які ділянки шляху зараз не спостережувані.

2. Схема потоків трейсів. Домовляємося про єдиний формат передачі контексту між сервісами, правила найменування операцій та атрибутів. Без цього трейси склеюються в уривки й не показують повний час відповіді.

3. Розгортання Jaeger. Колектор прийому, сховище, інтерфейс пошуку: розносимо прийом і запис, задаємо термін зберігання трейсів та очищення старих, вирішуємо, де ставити агентів — на вузлах чи поруч із додатком.

4. Інструментування сервісів. Вмикаємо автоматичний збір на стандартних бібліотеках, критичні ділянки розмічаємо вручну, щоб у трейсі з'явилися бізнес-атрибути. Тут же задаємо правила вибірки: суцільний збір на піку роздуває сховище, рідкісний — губить аномалії.

5. Перевірка на навантаженні. Проганяємо трафік, близький до бойового, і дивимося три речі: частку склеєних трейсів, накладні витрати на стороні сервісу, поведінку сховища на піку. Правила вибірки правимо за фактом, а не за розрахунком.

6. Передача документації та регламентів. Віддаємо схеми потоків, конфігурацію, панелі моніторингу, правила оповіщень і порядок дій при деградації. Команда додає новий сервіс у спостережуваність уже без нас.

Далі залишаються лише правки: підключення сервісу або зміна сховища — це зміна конфігурації, а не перезбирання системи.

Комплект передачі: схеми трасування, політики відбору та регламенти

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

• Конфігурації збору — файли прийому та обробки трейсів із правилами вибірки: які сервіси трасуються повністю, які за часткою запитів, які виключені через обсяг.
• Схема потоку трейсів — діаграма шляху даних від сервісу до сховища та інтерфейсу пошуку, з позначеними точками відмови та місцями, де трейс губиться.
• Політики доступу — ролі та області видимості: хто бачить усі сервіси, хто лише свої, як видаються та відкликаються права, де лежать ключі.
• Правила зберігання — терміни життя трейсів за типами, умови дострокового очищення, розбиття за індексами та стиснення; окремо довгий термін для трейсів розібраних інцидентів.
• Інструкції чергової зміни — як за хвилину перевірити, що трасування живе, що робити при затримці прийому та як відкотити правку конфігурації.
• Регламент планових перевірок — звірка обсягу сховища, контроль частки відкинутих трейсів, наскрізний тест після оновлення сервісів.
• Карта інструментування — сервіси та бібліотеки з версіями, щоб при оновленні не втратити сумісність і не залишитися без трейсів.
• Журнал змін — хто і навіщо правив правила вибірки; без нього через півроку ніхто не пояснить зникнення трейсів конкретного сервісу.

Кейс: як скоротили час пошуку причини збою

Платформа з кількох десятків сервісів, частина обміну — через черги. При збої черговий бачив сплеск помилок на вході, але причина часто лежала в третьому-четвертому сервісі ланцюжком, а логи кожного сервісу жили окремо. Єдиного ідентифікатора запиту не було — події пов'язували вручну, за часом і непрямими ознаками.

Локалізація причини займала 3-4 години, ще стільки ж — на підтвердження гіпотези. Близько третини інцидентів закривали без поясненої причини: симптом прибирали, корінь не знаходили, і через кілька тижнів він проявлявся в іншому місці. Середній час відновлення тримався на рівні кількох годин.

Що змінили

Впровадили Jaeger і наскрізний ідентифікатор запиту, який передається через усі виклики, включно з асинхронними. Інструментували місця, де найчастіше губився час: звернення до бази, зовнішні виклики, постановку та обробку повідомлень у чергах.

Семплювання налаштували адаптивно — повільні та рідкісні запити зберігаються повністю, потік рутинних не роздуває сховище.

Що стало

Посилання на трейс додається до картки інциденту — розбір починається з факту, а не з перебору версій. Локалізація скоротилася до 10-15 хвилин, час відновлення — у рази, частка інцидентів без поясненої причини впала до поодиноких випадків.

Повторювані збої стало видно за загальною картиною викликів, і їх закривають на розборі, а не після третього звернення.

Чим Jaeger відрізняється від збору логів і метрик

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

Лог фіксує подію з текстом і контекстом окремого сервісу, і в розподіленому контурі його доводиться вручну зіставляти із записами сусідів за часом.

Трасування в Jaeger будується навколо контексту запиту: йому присвоюється ідентифікатор, який передається через усі виклики, а кожен крок залишає запис із тривалістю та зв'язком із батьківським кроком.

Виходить дерево — шлях запиту між сервісами повністю, включно з асинхронними гілками через черги та повторні спроби.

Межа застосовності проста. Логи незамінні, коли потрібен точний текст помилки або значення поля. Числові показники — коли важливі тренди, оповіщення та вартість зберігання: вони компактні та дешеві на довгому горизонті.

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

Доповнюють вони одне одного, а не замінюють: зв'язка «сплеск → конкретний крок → повідомлення про помилку» скорочує пошук причини з годин до хвилин.

При цьому трасувати все підряд не потрібно — семплювання на вході задає частку записуваних запитів, а відбір за помилками та повільними відповідями залишає саме ті, що варто розбирати.

Технічні сумніви: навантаження, обсяг даних, сумісність

Сумніви щодо навантаження та обсягу сховища з'являються, коли трасування вже ввімкнено в кількох сервісах і видно, скільки даних приносить кожна операція. Нижче — відповіді на питання, які інженери ставлять перед тим, як підключати решту сервісів.

Як швидко зростає обсяг сховища?

Обсяг задають три речі: кількість інструментованих операцій, коефіцієнт вибірки та термін зберігання. Сирі інтервали тримаємо кілька днів, агрегати — довше, на кожне ім'я сервісу налаштовуємо політику видалення. Реєстр перестає зростати безконтрольно, а розбір інциденту за минулий тиждень залишається можливим.

Чи сумісно це з нашими середовищами та стеками?

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

Стек також не критичний — бібліотеки інструментування є для основних мов, а нестандартні обв'язки закриваємо ручними інтервалами або шлюзом-посередником.

Що робити з частково інструментованими сервісами?

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

Чи можна знизити збір без перезбирання сервісів?

Так. Вибірка та прийом керуються на стороні збирача: при позаштатному навантаженні достатньо зменшити коефіцієнт або тимчасово вимкнути джерело — додатки продовжують працювати. Повернення до попередньої конфігурації агента теж не потребує релізу.

Обговоримо завдання: що знадобиться з вашого боку

Агент збирає трейси й надсилає їх у Jaeger, але щоб розгорнути колектор і пов'язати його з вашими сервісами, потрібен доступ до інфраструктури та розуміння того, як влаштовані контури.

Нижче — що запитуємо на старті робіт: цього достатньо, щоб повернутися з планом та оцінкою, без уточнювальних раундів у середині впровадження.

• Доступи: облікові записи до кластера та реєстру образів, права на створення об'єктів в окремому просторі імен — без прав на зміну бойових робочих навантажень.
• Перелік сервісів: які додатки інструментуємо, на яких мовах і бібліотеках вони написані, чи є вже вивантаження трейсів хоч у якомусь вигляді.
• Середовища: скільки контурів — розробка, передпродуктивний, бойовий; чи потрібен Jaeger у кожному або достатньо одного з розподілом за підрозділами.
• Вимоги до термінів зберігання: скільки днів трейси мають залишатися доступними для розбору інцидентів і хто за ними звертається.
• Порядок погодження змін: коли можна викочувати правки в конфігурацію сервісів, хто підтверджує, чи потрібен відкат в один крок.
• Схема зв'язків між сервісами: чи є проксі та балансувальники, які потрібно врахувати, щоб контекст не губився.
• Відповідальний за приймання: інженер, який перевірить, що трейси збираються наскрізними та знаходяться за ідентифікатором запиту.

Опишіть завдання та надішліть ці дані — повернемося з планом робіт: етапи, межі нашої відповідальності, порядок викочування за середовищами та точки, де потрібне ваше підтвердження.