Наскрізне трасування ламається на межах сервісів
Трасування тримається рівно до першої межі між сервісами: виклик по HTTP усередині кластера видно повністю, а щойно запит іде в чергу, у фонове завдання або до зовнішнього шлюзу, контекст губиться.
Спани не зв'язуються в один трейс, і в панелі залишається фрагмент шляху — до моменту, коли сервіс передав роботу далі. Наскрізне трасування перетворюється на набір незв'язаних відрізків, а зіставляти їх доводиться вручну за логами.
Найдорожче це дається взнаки під час розбору інцидентів. Черговий відкриває логи чотирьох-п'яти сервісів, звіряє мітки часу очима й виявляє, що ідентифікатор запиту в кожного компонента свій.
Вузьке місце шукається перебором: спочатку під підозру потрапляє база, потім пул з'єднань, потім кеш — і лише наприкінці години з'ясовується, що шлях гальмував один зовнішній виклик із повторними спробами. Розірвана спостережуваність сервісів не дає довести причину, тому деградація встигає повторитися.
Щоб трейс не рвався, контекст потрібно передавати через усі транспорти, які є в системі, а не лише через синхронні виклики.
New Relic APM збирає розподілене трасування по сервісах, але картина стає повною лише тоді, коли інструментовано і обробники черг, і планувальники фонових завдань, і клієнти зовнішніх інтеграцій.
Окрема частина роботи — пов'язати записи логів із трейсами за спільним ідентифікатором, щоб перехід від спана до рядка логу займав один клік.
Розбираємо, як це закривається: що налаштувати в агенті, як розмітити сервіси й які перевірки закласти, щоб трейс збирався повністю, а не до першої межі.
Що дає наскрізна спостережуваність по всіх сервісах
Наскрізна спостережуваність — це коли за однією скаргою можна простежити весь шлях запиту: від вхідного сервісу через черги та зовнішні виклики до конкретного запиту до бази.
New Relic APM збирає розподілені трасування, метрики застосунків і дані про середовище в одну картину, тому причина збою шукається не перебором логів по п'яти системах, а за графом залежностей. Нижче — що саме змінюється в роботі команди, коли така зв'язка вже налаштована.
- Час локалізації причини. Трасування пов'язує ділянки за одним ідентифікатором запиту — замість годин на узгодження «чия це ділянка» причина знаходиться за хвилини.
- Вузькі місця сервісів. Видно топ найдовших зовнішніх викликів і запитів до сховища з розбивкою за часом відповіді — зрозуміло, що оптимізувати першим, а що не впливає на результат.
- Хибні тривоги. Правило будується на зв'язці сигналів (частка помилок + тривалість + пропускна здатність), а не на одному порозі — спрацювання без реального відхилення майже зникають.
- Клас прихованих відмов. Деградація, за якої все «зелене», але одна ділянка відповідає втричі довше, виявляється до звернень користувачів.
- Час відновлення. Кожен викат автоматично прив'язується до точки релізу: порівняння «до і після» й відкат спираються на факти, а не на здогади.
- Карта залежностей. Зв'язки між сервісами будуються за фактичним трафіком, а не за документацією, яка відстала від реальності.
- Єдиний контекст розбору. Логи, метрики й трасування відкриваються поруч, тому розбір інциденту не перетворюється на ручний збір вивантажень із різних систем.
Сенс не в панелі моніторингу, а в зміні процесу: налаштовуємо правила оповіщень, регламент розбору й розмітку сервісів так, щоб спостережуваність працювала на чергову команду, а не існувала сама по собі.
Способи збору телеметрії: агент, розмітка, шлюз
Спосіб збору телеметрії обирають за одним критерієм: де ми готові вносити зміни — у конфігурацію вузла, у код застосунку або в окремий сервіс між застосунком і сховищем.
Агент моніторингу ставиться на хост або в контейнер, не потребує правок коду й одразу віддає запити, помилки та час зовнішніх викликів; ціна — тримати й оновлювати його на кожному вузлі.
Інструментування коду дає точні межі бізнес-операцій, але прив'язує нас до мови й до дисципліни команди розробки.
Окремий збирач метрик — компроміс для розподіленої архітектури збору даних: агенти й бібліотеки надсилають дані йому, а він вирішує, що йде далі, як збагачується й фільтрується. У New Relic ці варіанти доповнюють один одного, тому вибір — не «або», а «у якому порядку».
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Агент на хості або в контейнері | Потрібна телеметрія без правок коду й кількох мов | Доступ до вузлів, версії агентів треба тримати синхронно |
| Бібліотека всередині застосунку | Потрібні бізнес-метрики й точні межі операцій | Правки коду, залежність від мови, перезбирання й реліз |
| Окремий збирач-шлюз | Багато джерел, потрібен єдиний прийом і фільтрація | Сам є сервісом: масштабування, оновлення, відмовостійкість |
| Агент на вузлі плюс бібліотека | Потрібні й інфраструктурні, і прикладні дані | Дублювання метрик, потрібна нормалізація імен |
Межі варіантів розмиваються: агент на вузлі вирішує завдання за день, а бібліотека додає те, що ззовні не видно. Далі розбираємо, як поєднати їх без дублів у звітності.
Як проходить впровадження: від схеми до передачі
Впровадження моніторингу рідко зводиться до встановлення агента: спочатку потрібно зрозуміти, які сервіси пов'язані між собою й де губиться контекст запиту. Тому йдемо етапами — від обстеження середовища до передачі регламентів, щоб схема спостережуваності працювала без нас.
- Обстеження середовища. Інвентаризуємо сервіси, середовища й точки входу, фіксуємо, що вже віддає метрики, а що доведеться закривати вручну.
- Проєктування схеми спостережуваності. Домовляємося, що вважаємо окремим сервісом, як пов'язуємо запит між ними й скільки зберігаємо дані — термін обираємо під розбір збоїв.
- Налаштування агентів. Ставимо агент New Relic поруч із застосунком, вмикаємо збір за замовчуванням і точково додаємо ручні заміри там, де автоматика не бачить бізнес-операцію.
- Розподілене трасування. Передаємо контекст через сервіси й черги та налаштовуємо частку збережених запитів: вибірка залишається репрезентативною, а обсяг даних не зростає безконтрольно.
- Панелі й правила оповіщення. Збираємо панелі під чергового, техліда й керівника напряму, а правила налаштовуємо на відхилення від норми, а не на кожен сплеск.
- Навантажувальна перевірка. Проганяємо профіль, близький до робочого, і стежимо, щоб запис даних не з'їдав пропускну здатність і не додавав затримок помітно для користувача.
- Передача регламенту експлуатації. Фіксуємо, хто і як реагує на оповіщення, як відкочують зміни й як підключають новий сервіс у схему.
Політики доступу, ролі та розмежування даних
Розмежування доступу в системі трасування — не бюрократія, а умова, за якої результатам розслідувань можна вірити.
Один спільний обліковий запис із повними правами в New Relic обнуляє аудит: неможливо зрозуміти, хто змінював правило оповіщення й хто вивантажував трейси з параметрами запитів.
Ролі спостерігачів вибудовуємо від структури команд: розробник бачить свої сервіси, черговий — весь контур, зовнішній підрядник — лише погоджену ділянку.
На руки замовник отримує:
- матрицю ролей із прив'язкою до команд і сервісів: хто дивиться метрики, хто — трейси, хто керує правилами;
- політики розмежування даних і маскування: параметри запитів вирізаються до запису, а не після;
- схему потоків даних від збирача метрик до сховища із зазначенням точок знеособлення;
- регламент чергувань і ескалації: строки реакції, порядок передачі зміни, критерії нічного виклику;
- документацію експлуатації: ротація ключів доступу, ревізія прав, підключення нового сервісу до трасування;
- журнал аудиту дій та інструкцію з розбору інцидентів із посиланнями на конкретні панелі й запити;
- чек-лист приймання, за яким конфігурацію можна перевірити без нас: запити, фільтри, зони видимості.
Налаштування алертів без шуму: пороги й групи
За замовчуванням команди ставлять статичні пороги «на око»: час відповіді вище за умовне значення — тривога. У години пік такий поріг спрацьовує десятки разів, черговий звикає ігнорувати канал, і справжня відмова приходить разом із шумом.
Лікується це не вимкненням правил, а розділенням умов за природою метрики — у New Relic це робиться на рівні політик і умов.
Ресурсні метрики — утилізація диска, вичерпання пулу з'єднань, зростання черги — тримаємо на статичних порогах: у них є фізична межа, відхилення завжди значуще.
Залежні від трафіку — час відповіді, частка помилок, пропускна здатність — переводимо на базові пороги з вікном згладжування в кілька днів і вимогою утримувати відхилення довше одного заміру.
Це прибирає спрацювання на одиничному сплеску й залишає ті, що підтверджуються сусідніми метриками сервісу.
Друге джерело шуму — один збій, що породжує сорок тривог. Групування інцидентів за сутністю й ключовими ознаками збирає пов'язані спрацювання в один інцидент із спільним контекстом, а розділення на критичні й попереджувальні рівні не дає фоновим подіям перебивати критичні.
Поріг попередження ставимо навмисно нижче за критичний — він працює як ранній сигнал, а не як привід для нічного дзвінка.
Маршрутизація тривог спирається на теги: у кожної сутності проставлено власника сервісу, і правила доставки розкладають спрацювання за чергуваннями — критичне йде в черговий канал з ескалацією, попередження в командний, нічний фоновий потік згортається в ранковий дайджест.
Придушення шуму включає правила заглушення на час планових робіт і викату релізу, щоб оновлення не виглядало як аварія. Підсумок — частка тривог, за якими справді щось роблять, зростає, а час до реакції падає.
Чим відрізняється трасування запитів від метрик?
Метрика відповідає на питання «що і як часто», трейс — «де саме і чому». Вибір «метрики чи трейси» — хибна розвилка: це послідовні інструменти, а не конкуренти.
Агреговані метрики показують, що проблема є і в якому вікні часу, а трасування запитів веде до конкретної ділянки шляху, яка її створює.
Агреговані метрики рахуються за всіма запитами одразу: частка помилок, 95-й процентиль часу відповіді, кількість звернень за секунду, насичення пулу з'єднань.
Вони дешеві за обсягом і добрі для спостереження — за ними видно, що після викату зросла частка відмов або просів процентиль затримки.
Чого в них немає, так це прив'язки до окремого запиту: метрика скаже, що повільно, але не покаже, на якому кроці обробки втрачено сотні мілісекунд.
Трейс — це запис одного шляху: від вхідної точки через внутрішні сервіси до бази й зовнішніх викликів, із тривалістю кожної ділянки та зв'язком між ними. Він зберігає контекст помилки — який обробник упав, з якими параметрами прийшов запит, що відбувалося в сусідніх сервісах.
Для діагностики збою спочатку звужують вікно за метриками, а потім відкривають трейси саме цього інтервалу.
У New Relic APM обидва шари пов'язані в одній картині: розподілене трасування склеює ділянки шляху між сервісами, а метрики за ними потрапляють у ті самі графіки, за якими йде чергування.
Розбір іде згори вниз — від «зросла частка помилок на оплаті» до «виклик зовнішнього шлюзу перестав вкладатися в таймаут».
Кейс: розбір деградації платіжного сервісу
Платіжний сервіс проводив платежі через ланцюжок із чотирьох ділянок: прийом запиту, перевірку антифроду, звернення до зовнішнього провайдера й запис результату.
Середній час відповіді на вході тримався в нормі, але в частини операцій він підскакував у рази — за зведеним графіком цього не було видно.
До: трасування обривалося на середині ланцюжка
Трасування збиралося лише на перших двох ділянках: далі контекст запиту губився, бо проміжний шар не передавав заголовки.
New Relic отримував розрізнені транзакції без прив'язки до конкретного платежу, і розбір кожного випадку перетворювався на ручне зіставлення журналів за відмітками часу.
Час пошуку причини сягав 4–6 годин, а майже половина розборів закінчувалася висновком «відтворити не вдалося». Правки в антифрод вносилися наосліп: не було видно, що додає затримку — перевірка чи очікування відповіді провайдера.
Після: наскрізна зв'язка за ідентифікатором платежу
Ми провели ідентифікатор платежу через усі ділянки й увімкнули розподілене трасування на проміжному шарі, а помилки розбили за типами й ділянками — відмова провайдера перестала змішуватися з внутрішньою помилкою розбору відповіді.
- Час пошуку першопричини на інцидент: 4–6 годин → 10–20 хвилин.
- Частка випадків із причиною, знайденою під час першого розбору: близько половини → дев'ять із десяти.
- Правки в антифрод: за гіпотезами → за розбивкою затримок за ділянками.
Ефект дала не сама телеметрія, а безперервність трасування: розрив на одній ділянці знецінював дані всіх інших.
Технічні сумніви перед початком робіт
Заперечення перед впровадженням наскрізного трасування зазвичай не про можливості, а про ціну експлуатації: накладні витрати, сумісність і приватність даних. Розбираємо чотири, які найчастіше зупиняють проєкт.
Чи не перевантажить збір даних самі сервіси?
Агент знімає метрики постійно, а розподілене трасування вмикаємо точково — на критичних шляхах і з вибіркою. Накладні витрати утримуємо в межах кількох відсотків часу відгуку, заміряючи їх до і після на одному профілі навантаження. Для сервісів, чутливих до затримок, трасування звужуємо до окремих операцій.
Що робити із застарілими сервісами?
Переписувати їх не обов'язково: сумісність забезпечуємо на рівні середовища — збір через проксі й логи, а не через агент усередині застосунку. Так старі сервіси потрапляють у загальну картину трасування, навіть якщо їхній код ніхто не чіпає.
Як бути з приватністю даних?
Маскування налаштовуємо на боці агента: персональні поля, ідентифікатори й тіла запитів вирізаються до надсилання, назовні йдуть імена операцій і тайминги. Правила маскування лежать у конфігурації й закриті перевірками — у разі зміни схеми даних вони не розходяться з реальністю.
Скільки зберігаються трейси й як обмежити обсяг?
Термін зберігання задаємо політиками: сирі трейси живуть обмежений термін, агреговані метрики — довше, бо займають менше місця й потрібні для трендів. Після ввімкнення вибірки й очищення за терміном обсяг зберігання перестає зростати лінійно.
Обговоримо ваше завдання спостережуваності
Почати варто з опису завдання: які сервіси беруть участь в обробці запиту, де зараз губиться контекст між ними й яке питання потрібно закрити — пошук джерела помилок, розбір повільних ділянок чи контроль часу відповіді на всьому шляху.
Для попереднього розбору достатньо переліку сервісів, їхнього середовища виконання й схеми оточення: окремо контури розробки, тестування та робочий.
Оцінка робіт будується не на око. Рахуємо кількість точок входу, глибину ланцюжка викликів, обсяг потоку запитів і потрібну частку покритих маршрутів.
Якщо спостережуваність уже частково розгорнута, дивимося, де встановлені збирачі даних і які розриви контексту залишаються — це показує, чи вистачить доналаштування, чи потрібне перенесення логіки.
За підсумками розбору повертаємося з планом впровадження й схемою оточення: черговість підключення сервісів, етапи, зони відповідальності, критерії приймання й точки відкату.
Що зазвичай потрібно на вході, щоб перейти до старту робіт:
- перелік сервісів і зв'язків між ними, включно з фоновими завданнями й чергами;
- схема оточення із зазначенням, де який контур і як вони між собою сполучаються;
- доступи до систем спостережуваності й сховищ журналів — сервісні облікові записи з правами лише на читання;
- середовища виконання й версії бібліотек, що формують трасування;
- перелік уже підключених джерел даних і налаштованих оповіщень;
- очікування щодо глибини зберігання трас і швидкості пошуку;
- співробітник, який підтвердить критерії приймання на боці замовника.
Опишіть завдання так, як зручно — коротким листом або зустріччю. Повернемося з оцінкою, планом і зрозумілим обсягом першого етапу.
