Dynatrace APM: чому мобільний застосунок «гальмує» непомітно
Типова картина: користувачі скаржаться на підвисання та відвали, а серверна частина показує рівний графік — час відповіді в нормі, помилок немає, ресурси не впираються в стелю. Розрив пояснюється просто: серверні метрики бачать лише ті запити, які до сервера дійшли.
Усе, що відбувається до цього — старт застосунку, відмальовування екранів, робота з локальним сховищем, мережа оператора, — залишається поза оглядом. Саме там і ховається вузьке місце.
Dynatrace APM закриває цю сліпу ділянку: агент ставиться в сам застосунок і знімає дані з пристрою користувача, а не з сервера. Видно, на якому екрані користувач завмирає, скільки займає холодний старт, які виклики до сервера не доходять і чому.
Відмови на пристрої перестають бути анонімними — замість «у когось не працює» з'являється конкретна версія застосунку, модель пристрою, версія системи та оператор зв'язку.
Далі картина складається в причинно-наслідковий ланцюжок. Якщо гальмує лише один оператор — проблема в мережі, а не в коді. Якщо провал на конкретній моделі — справа в сумісності або в нестачі пам'яті. Якщо повільний виклик повторюється в усіх — вузьке місце в самому застосунку.
Моніторинг мобільного застосунку в Dynatrace APM пов'язує скаргу, технічну причину та уражену частку користувачів, тому правки йдуть у те місце, яке справді впливає на досвід, а не в те, яке найгучніше скаржиться.
Розбираємо нижче, як це розгортається на проєкті: що саме знімається з пристрою, як відокремити мережеві збої від помилок коду і як налаштувати оповіщення, щоб про деградацію ми дізнавалися раніше за користувачів.
Що дає наскрізний моніторинг: ефект у вимірюваних величинах
Наскрізне трасування пов'язує дію користувача на пристрої з конкретним запитом до серверної частини та записами в базі. Раніше ці дані жили в різних системах: мобільний краш-лог окремо, метрики сервера окремо, і зіставити їх можна було лише вручну за часом.
Тепер одна сесія розгортається в повний ланцюжок викликів — від натискання до відповіді бекенду, з часом на кожній ділянці.
Час відгуку перестає бути усередненою цифрою. Видно, що 90-й процентиль тримається в нормі, а хвіст зростає за рахунок конкретного запиту до сервісу авторизації. Це змінює пріоритети: оптимізують не те, що частіше гальмує, а те, що визначає найгірший досвід.
Частка неуспішних сесій рахується за користувачами, а не за запитами. Сесія, де людина закрила застосунок після трьох помилок підряд, потрапляє в статистику один раз — і це чесніше, ніж тисяча ретраїв одного клієнта.
Клас відмови визначається автоматично: мережа, помилка сервера, падіння на пристрої або таймаут інтеграції. Інженер отримує не «щось зламалося», а конкретну категорію з прив'язкою до версії застосунку, моделі пристрою та оператора зв'язку.
Окрема цінність — контроль релізів. Порівняння метрик до і після викатки показує, чи зросла частка неуспішних сесій на новій версії, і відкат приймається за даними, а не за скаргами в підтримку.
Способи збору даних: порівняння підходів до інструментування
Спосіб підключення моніторингу визначає, які дані ви взагалі побачите. Повне інструментування через агент на пристрої дає розподілені трасування за кожним викликом, включно з внутрішніми методами, але потребує перезбирання застосунку та врахування політик приватності.
Мережевий перехоплення трафіку (проксі або VPN-профіль) не чіпає код, зате втрачає контекст усередині процесу і не бачить фонові задачі та роботу з локальним кешем.
Нижче — реальні варіанти, між якими обирають на старті, та їхні обмеження. Комбінувати їх можна: агент закриває глибину, перехоплення — швидкий старт без релізу.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Агент на пристрої (повне інструментування) | Потрібні розподілені трасування, метрики падінь і зависань UI, зв'язок із бекендом | Перезбирання та реліз, зростання розміру збірки, налаштування приватності даних |
| Ручні метрики через SDK | Точковий контроль ключових сценаріїв (оплата, вхід, оформлення) | Покриває лише розмічені шляхи, решта — сліпа зона |
| Перехоплення трафіку (проксі) | Швидкий аудит мережі без зміни застосунку, розбір проблем інтеграцій | Немає контексту всередині процесу, не бачить фонові задачі та локальний кеш |
| Синтетичні перевірки | Контроль доступності та часу відгуку критичних сценаріїв ззовні | Не відображають реальну поведінку та пристрої користувачів |
| Логи та краш-репорти | Базова діагностика падінь та аномалій | Немає наскрізного зв'язку із запитами, ручна кореляція інцидентів |
На практиці найчастіше агент на пристрої доповнюють перехопленням на етапі впровадження: спочатку знімають картину мережі без релізу, потім додають глибокі трасування. Так команда отримує дані одразу, а не чекає наступної збірки.
Як відбувається впровадження: етапи інженерної роботи
Впровадження починаємо з аудиту телеметрії: дивимося, які події застосунок уже надсилає, де губиться контекст між сесією користувача та серверним запитом, які збої залишаються невидимими.
За підсумками фіксуємо перелік сигналів, які потрібно збирати, і точки, де зараз немає даних для розбору інцидентів.
- Аудит поточної телеметрії. Розбираємо наявні логи, краш-репорти та метрики, відзначаємо розриви: не відстежуються мережеві виклики, немає прив'язки до версії збірки, губиться ідентифікатор сесії при перезапуску.
- Проєктування схеми збору. Визначаємо, які події, метрики та трасування знімаємо з клієнта, що агрегуємо на боці сервісів, як пов'язуємо мобільну сесію з бекендом — єдиний ідентифікатор проходить через усі шари.
- Розмітка застосунку та сервісів. Вбудовуємо збір у ключові сценарії: запуск, авторизація, оплата, робота з даними. Окремо позначаємо дії користувача, щоб падіння конверсії читалося за кроками, а не «десь у застосунку».
- Налаштування дашбордів та оповіщень. Збираємо екрани під реальні питання: частка успішних сценаріїв, час відповіді зовнішніх сервісів, частота збоїв за версіями. Пороги оповіщень виставляємо так, щоб черговий отримував сигнал до того, як про проблему напишуть користувачі.
- Перевірка на стенді. Прогоняємо сценарії зі штучними збоями та затримками, переконуємося, що сигнал доходить до системи, коректно групується і потрапляє в потрібне оповіщення. Окремо перевіряємо поведінку при поганій мережі та офлайні.
- Передача в експлуатацію. Віддаємо налаштовану систему з регламентом чергування, описом типових інцидентів і порядком дій, навчаємо команду читати дашборди та розбирати збої за трасуванням.
Після передачі система продовжує жити: правила збору та пороги оповіщень переглядаються в міру зростання застосунку, щоб моніторинг не перетворювався на шум.
Артефакти на виході: конфігурації, схеми та регламенти
Інтеграція Dynatrace закінчується не увімкненим агентом, а набором артефактів, за якими систему можна супроводжувати без нас.
Кожен пункт передається в репозиторій замовника і версіонується разом із кодом застосунку — при наступному релізі видно, що і навіщо змінювалося в конфігурації.
- Конфігурація моніторингу — файли з налаштуваннями збору метрик, правилами розмітки запитів і порогами спрацювання. Окремо фіксуємо, які події вважаються аварійними, а які — фоновим шумом.
- Схема потоків даних — звідки збираються метрики, через які вузли проходять, де зберігаються і як довго. За нею новий інженер за годину розуміє, де шукати причину просідання.
- Політики доступу — матриця ролей: хто бачить дашборди, хто змінює пороги, хто отримує повідомлення. Доступи видаються за принципом мінімально необхідних.
- Регламент чергування — порядок дій при спрацюванні: кому надходить сигнал, за який час потрібно підтвердити, коли ескалувати. З прописаними зонами відповідальності між командою застосунку та інфраструктурою.
- Інструкції щодо типових збоїв — покрокові сценарії для частих інцидентів: зростання частки помилкових запитів, просідання відгуку на конкретному екрані, відвал інтеграції з бекендом.
- Карта дашбордів — які панелі дивляться щодня, які відкривають лише під час розбору інциденту. Без цього черговий тоне в графіках.
- Процедура відкату — як зняти або послабити правила збору, якщо вони заважають релізу, і що при цьому втрачається в спостережуваності.
Усе це оформлюється як робоча документація, а не як звіт «для галочки»: її правлять при кожній зміні застосунку. Опишіть вашу задачу — повернемося з оцінкою та планом, які артефакти потрібні саме вам.
Кейс: як скоротили час пошуку причини відмов
Проєкт — мобільний банк із мільйонною аудиторією на iOS та Android. Скарги на «зависання під час оплати» надходили до підтримки, але відтворити їх не вдавалося: логи розмазані між клієнтом і бекендом, а кореляція між сесією користувача та запитом до сервісу була відсутня.
Інженери витрачали на локалізацію причини в середньому 6-8 годин, і в половині випадків інцидент закривали як «не відтворюється».
Що змінили
Впровадили Dynatrace як єдину систему моніторингу продуктивності застосунку: пов'язали клієнтські сесії із серверними транзакціями наскрізним ідентифікатором, увімкнули автоматичне відстеження мережевих викликів, крашів і «завмерлих» екранів.
Налаштували оповіщення за ключовими бізнес-сценаріями — вхід, платіж, переказ — із прив'язкою до конкретної версії застосунку та моделі пристрою.
Що стало
Час локалізації причини відмови скоротився з 6-8 годин до 20-40 хвилин: інженер відкриває проблемну сесію, бачить весь ланцюжок — від натискання кнопки до відповіді сервісу — і одразу розуміє, де вузьке місце. Частка інцидентів, закритих як «не відтворюється», впала з 50% до 8%.
Окремо виграли на релізах: перед викаткою порівнюємо метрики нової версії з попередньою і ловимо деградацію до того, як її помітять користувачі.
Через два місяці після запуску команда перестала збирати наради щодо кожного збою — дані вже зібрані та прив'язані до сценарію. Розбір інциденту перетворився з розслідування на читання готової картини.
Чим відрізняється моніторинг пристрою від серверного?
Серверні метрики описують стан бекенду: завантаження процесора, час відповіді API, глибину черг, частку помилок на стороні сервісу. Поки ці показники в нормі, вважається, що застосунок працює.
Але між сервером і екраном телефона лежить довгий шлях — мережа оператора, радіомодуль, операційна система пристрою, фонові процеси, версія збірки. Проблема виникає на будь-якій із цих ділянок, і сервер про неї просто не знає.
Розрив спостережуваності — це ситуація, коли серверна частина відповідає за 200 мілісекунд, а користувач бачить завислий екран.
Причини бувають різні: слабкий сигнал у метро, агресивна економія батареї, яка зупиняє фонову синхронізацію, конфлікт з іншою програмою, витік пам'яті на конкретній моделі пристрою.
Жодна з них не відображається в серверних метриках, тому що запит до сервера або не дійшов, або дійшов і був обслугований штатно.
Моніторинг пристрою дивиться на те, що відбувається, з іншого боку — з боку користувацького досвіду.
Він фіксує час холодного старту, плавність прокрутки, частку зависань інтерфейсу, падіння застосунку, тривалість мережевих операцій на конкретному каналі зв'язку, а також розбивку за моделями пристроїв і версіями операційної системи.
Саме ці дані показують, що збій відтворюється в частини аудиторії з певною конфігурацією, а не в усіх підряд.
Ключова відмінність — у точці заміру і в тому, чий досвід вона описує. Серверні метрики відповідають на питання «чи справляється інфраструктура», моніторинг пристрою — «чи задоволений людина, яка тримає телефон у руках».
Обидві картини потрібні одночасно: перша показує ресурси і вузькі місця бекенду, друга — реальні умови експлуатації, які неможливо відтворити в тестовому середовищі.
Dynatrace APM пов'язує ці два шари в один ланцюжок: від дотику до екрана до відповіді сервера і назад.
Коли користувач скаржиться на повільне завантаження, інженер бачить, на якій ділянці втрачено час — у мережі, на пристрої чи в сервісі, — і не витрачає дні на пошук причини навмання.
Без такого пов'язування команда лагодить сервер, який і так працював, поки користувацький досвід продовжує деградувати.
Часті технічні сумніви перед стартом
Перед стартом інтеграції майже завжди виринають одні й ті самі питання: чи не просів застосунок, чи не доведеться переписувати модулі, чи не перетвориться збір телеметрії на окрему статтю витрат на зберігання. Нижче — відповіді по суті, без маркетингу.
Чи сповільнить моніторинг сам застосунок?
Накладні витрати агента — частки відсотка від часу відмальовування кадру та мережевих операцій. Вимірювання й надсилання телеметрії відбуваються у фоновому потоці, пакетами, а не на кожен виклик.
На практиці користувач різниці не помічає: час холодного старту та чутливість інтерфейсу залишаються в межах похибки. Якщо застосунок уже на межі за пам'яттю, агент налаштовується на знижений режим деталізації — спочатку знімаємо базові метрики, глибокий розбір вмикаємо точково.
Чи сумісно це з нашим стеком і версіями ОС?
Агент підтримує нативні та кросплатформні застосунки, актуальні гілки мобільних ОС та їхні попередні мажорні версії. Якщо частина коду на застарілому фреймворку, це не блокер: моніторинг підключається до шару застосунку, а не до кожного модуля.
На етапі обстеження ми звіряємо вашу матрицю пристроїв і версій із підтримуваним списком і говоримо прямо, де будуть прогалини в даних.
Скільки даних піде і як це контролювати?
Обсяг залежить від того, що ви вирішили збирати. За замовчуванням — агреговані метрики та трасування семплюються, а не пишуться цілком. Правила зберігання задаються заздалегідь: термін життя сирих даних, частка семплювання, відсікання шумних подій.
Так обсяг залишається передбачуваним, а налагодження конкретного збою — можливим, бо потрібні трасування зберігаються.
Чи безпечна телеметрія — чи не витечуть дані користувачів?
У телеметрію не потрапляють персональні дані: маскування полів і заборона на передачу чутливих значень налаштовуються на старті. Передача йде захищеним каналом, доступ до панелей розмежовується за ролями.
Політику зберігання та видалення узгоджуємо з вашими вимогами — це частина робіт, а не опція після запуску.
Якщо щодо якогось пункту залишаються сумніви — опишіть вашу конфігурацію, повернемося з оцінкою та планом інтеграції.
Обговоримо ваше завдання і повернемося з планом
Щоб повернутися з оцінкою термінів і планом впровадження, а не із загальними словами, нам потрібен мінімум вхідних даних: платформа та версії операційних систем, які підтримує застосунок, поточний спосіб збірки та релізний цикл, перелік зовнішніх сервісів і внутрішніх модулів, доступ до репозиторіїв і тестового контуру. Якщо вже є APM-агент або збір метрик — покажіть, що саме збирається зараз і де дані губляться.
З боку замовника достатньо виділити одну людину, яка підтверджує пріоритети та відповідає на питання щодо архітектури. Решта — наша робота.
У відповідь ми готуємо:
- план впровадження за етапами: підготовка середовища, підключення агента, налаштування збору даних, розмітка ключових сценаріїв, виведення в дашборди;
- склад робіт із межами відповідальності — що робимо ми, що залишається на боці замовника;
- оцінку термінів за кожним етапом і точки, де потрібна ваша приймання;
- схему розмітки критичних користувацьких шляхів: вхід, оплата, оформлення замовлення, синхронізація;
- перелік метрик і алертів, які команда отримає на виході, з порогами спрацювання;
- вимоги до доступів, середовищ і тестових облікових записів;
- план відкату, якщо агент впливає на стабільність збірки або поведінку застосунку;
- регламент підтримки: хто і як реагує на інциденти після запуску.
Опишіть завдання — які збої турбують зараз, на яких платформах і в яких сценаріях, який результат вважаєте успішним. Ми повернемося з оцінкою термінів, складом робіт і планом впровадження, за яким можна приймати рішення.
