Налаштування Datadog APM: що ламається без трасування в проді
Користувач пише в підтримку: застосунок падає під час оформлення замовлення. У моніторингу — сухий факт збою: тип винятку, модель пристрою, версія збірки.
Немає головного — шляху запиту до винної операції: який екран відкривався, який виклик пішов на сервер, скільки він чекав на відповідь і що повернулося.
Без наскрізного трасування мобільного застосунку інженер бачить лише краї: падіння на пристрої та запис на сервері, який вважається успішним. Між ними — сліпа зона моніторингу, де губляться мережеві таймаути, помилки розбору відповіді й підвисання на головному потоці.
Розбір інциденту за логами розтягується на дні: збірку відтворюють на десятках моделей, гіпотези перевіряють перебором, а вузьке місце в проді так і не знаходять — після релізу збій повторюється в іншої частки користувачів.
Ціна сліпоти — не лише години команди. Кожне нерозібране падіння на iOS і Android іде у відгуки та знижує оцінки в магазинах застосунків, а виправлення виїжджає через кілька релізів, бо причина невідома.
Ламається й планування: незрозуміло, що виправляти першим — мережу, розбір відповіді чи пам'ять на старих пристроях.
Розбираємо, як це закривається наскрізним трасуванням: пов'язати клієнтську подію із серверним запитом так, щоб звіт про інцидент збирався за хвилини, а не за дні.
Що дає наскрізне трасування мобільних застосунків
Наскрізне трасування пов'язує дію користувача в застосунку з конкретним запитом на сервері: один ідентифікатор проходить від натискання кнопки через мережевий виклик і базу даних до відповіді.
Інженер бачить не абстрактну помилку, а весь шлях із часом кожної ділянки — де запит загубився і на якому кроці зросла затримка.
Для мобільної команди це змінює три речі одразу. Час локалізації дефекту падає з днів до годин: до того самого ідентифікатора прив'язані збірка, версія системи й модель пристрою.
Частка відтворюваних помилок зростає — замість «у мене не працює» надходить траса, яку можна відкрити й повторити на тому самому сценарії.
| Що вимірюємо | До | Після |
|---|---|---|
| Час локалізації дефекту | години ручного звіряння логів | хвилини: шлях запиту видно повністю |
| Частка відтворюваних помилок | частину збоїв не вдавалося повторити | у кожного збою контекст пристрою й збірки |
| Контроль якості збірок | проблеми знаходили за відгуками | порівняння версій за часткою збоїв і відгуком |
| Моніторинг випусків | реліз відкочували після скарг | сплеск видно на викатці, відкат завчасно |
Окремо знімається простій: поки збій видно лише за скаргами, час простою тягнеться до першого підтвердженого повідомлення. Сплеск помилок на конкретній версії помітний уже на поступовій викатці, тому реліз відкочують до того, як відмова стане масовою.
Datadog зберігає мобільні й серверні дані в одній моделі, тому перехід між ними не потребує ручного звіряння логів.
Режими збору даних і тонке налаштування вибірки
Режим збору телеметрії вирішує, що взагалі потрапить у трасування, а що залишиться невидимим. На мобільних платформах обмеження задає середовище виконання: фонові задачі засинають, мережа зникає в метро й роумінгу, частина буферів губиться під час аварійного завершення.
Тому дані накопичуються локально й ідуть у Datadog APM пачками під час наступного запуску застосунку.
Нижче — три режими, між якими реально обирають на старті впровадження.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Ручна розмітка сценаріїв | Метрики потрібні на кількох критичних шляхах: вхід, оплата, оформлення замовлення | Решта коду не покрита — вузьке місце поза розміткою залишається сліпим |
| Автоматичний збір за всіма викликами | Первинна діагностика, коли невідомо, де саме деградація | Обсяг зібраних даних зростає кратно кількості звернень, слідом зростає витрата батареї |
| Гібрид із частковою вибіркою | Бойовий контур із великим потоком сесій | Потрібна дисципліна в налаштуванні: за невірного коефіцієнта рідкісні падіння випадають із вибірки |
Правило вибору одне: ручна інструментація дає точність на важливих шляхах, автозбір — повноту картини.
У гібридному режимі фіксуйте коефіцієнт вибірки на користувача або на сесію, а не на окремий виклик — тоді ланцюжок від старту застосунку до підтвердження замовлення залишається зв'язним і не рветься на випадкових операціях. Конфігурацію перевіряємо на тестовому контурі й дивимося, які сценарії не долетіли до сховища.
Як проходить впровадження: від аудиту до передачі команді
Впровадження будуємо ітераціями: спочатку фіксуємо, що вже збирається, потім додаємо відсутні точки заміру й лише після цього пов'язуємо клієнтські події із серверними операціями. На кожному кроці залишається робочий інструмент, а не набір налаштувань, який неможливо перевірити. Працюємо в Datadog APM, але послідовність однакова для будь-якого інструмента спостереження.
- Аудит моніторингу застосунку. Розбираємо, які події, відмови й метрики вже збираються, де губиться контекст між сесією користувача й запитом на сервер, а які падіння не видно взагалі.
- Схема точок заміру. Визначаємо, які дії покриваємо: запуск, переходи екранами, мережеві виклики, авторизація, оплата. Перелік узгоджуємо з вашою командою — зайві події дають шум і роздувають обсяг зберігання.
- Правки в клієнті. Налаштовуємо збір на iOS і Android, окремо розбираємо Flutter: частина викликів іде через спільний шар, і його потрібно коректно пов'язати з платформними.
- Підключення серверної частини. Зшиваємо клієнтські трейси із серверними, щоб один повільний запит читався повністю, а не двома розрізненими записами.
- Перевірка на реальних сценаріях. Проганяємо типові й аварійні шляхи: втрата зв'язку, відмова сервісу, скасування операції. Переконуємося, що збій видно й потрапляє в потрібну панель спостереження.
- Передача проєкту команді. Залишаємо конфігурації, схему точок заміру й короткі інструкції, проводимо навчання — далі ваші розробники додають нові події самостійно.
Артефакти впровадження: панелі, політики, регламенти
Після впровадження в команди залишається не звіт про роботи, а робочий контур моніторингу: стан застосунку видно на панелях, сигнал про деградацію надходить без ручних перевірок, а розбір збою йде за записаним порядком.
Доступи до Datadog оформлюємо на ваші облікові записи — після передачі ми не залишаємося єдиними власниками ключів і не потрібні для повсякденної роботи із системою.
- Панелі моніторингу застосунку — час запуску, частка неуспішних сесій, зависання інтерфейсу, зрізи за версіями системи й моделями пристроїв.
- Правила оповіщень — пороги й вікна усереднення підібрані так, щоб сигнал надходив на деградацію, а не на одиничний викид; для кожного вказано отримувача й канал.
- Політики доступу до даних — ролі, розподіл за середовищами, маскування персональних полів і терміни їх зберігання.
- Схема потоків даних — від пристрою до сховища, з позначеними точками знеособлення й виходами в зовнішні системи.
- Інструкції з підключення — як завести новий модуль застосунку в трасування й не роздути обсяг зібраних подій.
- Регламент розбору інцидентів — рівні, терміни реакції, шаблон звіту й порядок відкату на попередню збірку.
- Карта володіння — хто в команді відповідає за панелі, пороги й оновлення конфігурації.
Комплект розрахований на інженера, який раніше не працював із проєктом: за цими документами моніторинг піднімається й налаштовується заново без нашої допомоги.
Кейс: як прибрали сліпу зону у випуску мобільних версій
Замовник прийшов зі скаргою «оплата іноді не проходить». Мобільний клієнт — нативна частина плюс спільний кросплатформний шар, і в продакшені він жив як чорна скринька.
Про збої дізнавалися з відгуків у магазинах застосунків і листів у підтримку, а в логах залишалася помилка без прив'язки до конкретного кроку оплати: на якому з трьох екранів відвалився користувач, перевірити було нічим.
Впровадили Datadog APM так, щоб один слід покривав шлях від натискання кнопки до підтвердження від платіжного шлюзу.
Нативний і кросплатформний шари пов'язали спільним ідентифікатором запиту, поставили ручні спани на вибір способу оплати, надсилання, очікування відповіді й підтвердження, а мережеві виклики перевели на перехоплювач, який проставляє заголовки трасування.
Алерти налаштували не на «помилку в застосунку», а на просідання частки оплат, що дійшли до підтвердження.
Метрики до й після: частка успішних оплат зросла з 88 до 96%, а пошук причини конкретного збою стиснувся з двох-трьох діб до 25-40 хвилин — за трасуванням видно, на якому кроці й у якому шарі рветься ланцюжок.
Частка відмов, які ловляться до релізу, а не після, зросла з нуля до більшості: збірка проходить перевірку на тіньовому трафіку, і регрес з оплати випливає до викатки.
Замовник підтвердив ефект окремо: підтримка перестала бути першою лінією діагностики. Раніше інцидент починався з листування з користувачем, тепер — із трасування, де вже є платформа, версія клієнта й крок сценарію.
Чим відрізняється ручна інструментація від автоінструментації?
Ручна інструментація — це розмітка конкретних сценаріїв у коді: оформлення замовлення, вхід, синхронізація каталогу. Інженер сам задає ім'я операції, набір атрибутів і межі заміру, тому трасування показує шлях користувача, а не будову застосунку. Плата за це — дисципліна: новий сценарій не з'явиться в даних, поки його не розмітили.
Автоматична інструментація працює на рівні платформи й бібліотек: перехоплює мережеві виклики, звернення до бази, показ екранів, час відмалювання.
Покриття з'являється одразу, без правок продуктового коду, але імена операцій генеруються механічно — «HTTP GET», «екран завантажено», — і в потоці багато службового шуму. База на Datadog дає спани, але зібрати з них осмислений користувацький шлях усе одно доводиться вручну.
Розмір застосунку — аргумент проти «увімкнути все»: автозбір тягне за собою модулі та їхні залежності, що помітно на тлі лімітів магазинів застосунків і дозованого завантаження. Ручна розмітка додає лише ваші обгортки, і розмір збірки залишається передбачуваним.
Швидкість випуску версій залежить від того, де живе зміна. Автозбору достатньо оновити бібліотеку — нової розмітки сценаріїв не буде. Ручний підхід прив'язує трасування до релізу: новий шлях користувача означає правку коду, рев'ю та збірку.
На практиці обирають гібрид — автоінструментація як фон, ручна на критичних шляхах, плюс вибірка й фільтри, щоб обсяг даних не зростав швидше за трафік.
Часті технічні питання щодо розгортання й підтримки
Перед стартом інженерні команди ставлять ті самі питання: як вбудувати Datadog APM у вже випущений застосунок, чи зросте витрата заряду, чи можна почати з однієї платформи, кому залишаться доступи й чи вживеться новий збір із поточним. Відповідаємо на кожне.
Чи можна впровадити це у вже випущений застосунок?
Так: ініціалізація в точці входу під прапорцем конфігурації, логіку не чіпаємо. Випускаємо на частку користувачів і звіряємо холодний старт та успішність сесій.
Як це позначиться на витраті заряду?
Збираємо пакетами з локальним буфером, надсилаємо за активного екрана й у Wi-Fi, фонові заміри вимкнені. Порівнюємо добу роботи до й після ввімкнення.
Чи можна почати з однієї платформи?
Так. iOS або Android підключаємо окремо — схема імен спільна, друга платформа встає без перерозмітки. Flutter-шар налаштовується окремо від нативних частин.
Кому залишаться доступи після передачі?
Акаунт оформлено на вас, ключі — у вашому контурі, ми працюємо запрошеними учасниками. Після передачі ролі відкликаємо, схема даних і документація залишаються у вас.
Чи вживеться це з поточним моніторингом?
Так. Зони відповідальності розмежовуємо, частину сигналів залишаємо в попередній системі. Обидва потоки йдуть паралельно, поки не підтвердимо збіг метрик.
Обговоримо задачу й повернемося з оцінкою та планом робіт
Щоб розбір задачі моніторингу не звівся до загальних слів, нам потрібен мінімальний набір ввідних. За ними видно, де Datadog APM закриває розрив між збоєм і його причиною, а де знадобиться правка коду застосунку або складальної обв'язки. Нижче — що надіслати для первинного розбору.
- Склад застосунку й платформ: які модулі залишилися нативними, що винесено в спільний шар, чи підтримується одна кодова база на iOS і Android.
- Поточні інструменти моніторингу: збір звітів про падіння, логи, ручні заміри — що вже збирається й куди йде.
- Критичні користувацькі сценарії: вхід, оплата, оформлення замовлення — шляхи, розрив у яких коштує найдорожче.
- Обмеження щодо доступів: хто власник облікових записів, які політики безпеки, чи потрібен окремий контур для даних.
- Вимоги до приватності: які поля заборонено надсилати, чи потрібна фільтрація ідентифікаторів і геолокації.
- Календар релізів: вікна, коли правки у збірку не зірвуть випуск.
- Очікування щодо результату: метрики, трасування, мережеві затримки, частка покритих шляхів.
Опишіть задачу — склад застосунку, що вже є з моніторингу й на який термін плануєте випуски. Повернемося з оцінкою, планом робіт і переліком доступів, які потрібно видати до старту.
