Налаштування Real User Monitoring (RUM) для мобільного додатку: навіщо це потрібно?
Уявіть: користувач на Xiaomi Redmi Note 9 скаржиться, що екран списку товарів гальмує. Синтетичний моніторинг показує ідеальні 60 FPS, а на LTE в регіоні — network timeout на 8-й секунді. Без RUM ви дізнаєтеся про це тільки з відгуків у Play Market. RUM фіксує кожне відвисання UI, кожен анріл, кожну мережеву помилку. Наш досвід показує: 30% критичних багів не видно в синтетичних тестах. Впровадження RUM у 50+ проектах скорочує час діагностики в 3 рази та економить до $1500 на місяць за рахунок швидкого виявлення вузьких місць.
Різниця між RUM та синтетичним моніторингом
RUM збирає дані з реальних пристроїв, тоді як синтетика працює в контрольованому середовищі. Синтетичний моніторинг не покаже, що на Huawei P40 екран оплати гальмує через overdraw у FrameLayout. RUM фіксує кожну подію: View, Action, Resource, Error, Long Task. Серед них Long Task — найбільш діагностично цінний показник. Документація Datadog RUM стверджує, що понад 50% перформанс-інцидентів виявляються саме через Long Task.
Які дані збирає RUM?
Стандартний набір подій у мобільному RUM:
- View — перехід на екран (відкриття, закриття, тривалість)
- Action — тап, свайп, scroll, LongPress
- Resource — HTTP-запит: URL, метод, статус, розмір, latency
- Error — handled exception, unhandled exception, ANR, крэш
- Long Task — операція на main thread > 100ms (Android) / main runloop > 16ms (iOS)
З усіх подій найбільш діагностично цінне — Long Task у кореляції з View. Якщо Long Task у 250ms трапляється в момент переходу на екран оплати у 15% користувачів — це конкретний перформанс-баг, а не «щось іноді лагає».
Чому Long Task — головний індикатор проблем?
Long Task безпосередньо вказує на блокування UI. Наприклад, в одному проекті після інтеграції RUM з'ясували, що під час завантаження списку замовлень на Android відбувається важке сортування на main thread (Long Task 400ms). Рішення: перенести сортування в корутину. Без RUM ця проблема залишилася б непоміченою.
Порівняння інструментів RUM
| Інструмент | Особливості | Семплінг | Середня вартість за 100k сесій |
|---|---|---|---|
| Datadog RUM | Повний стек mobile+server, W3C tracing | До 100%, гнучкий | $300–$450 |
| Sentry | Безкоштовний tier, хороші release comparisons | За замовчуванням 100% | $0 (до ліміту) |
| Firebase Performance | Безкоштовно, тільки Google-екосистема | Автоматичний | $0 |
| New Relic Mobile | Потужний NRQL, enterprise | До 100% | $500+ |
Для більшості продуктів Firebase Performance — хороший старт (безкоштовно, zero-config для мережі). Але як тільки потрібна кореляція з серверними трейсами або кастомні бізнес-атрибути, переходять на Datadog або Sentry. Datadog обробляє в 10 разів більше подій, ніж Firebase Performance, при порівнянній вартості.
Як вибрати sessionSampleRate?
sessionSampleRate визначає відсоток сесій, які надсилаються до RUM. При високому DAU (наприклад, 1 млн) 100% сесій — дорого. Стандартна практика: 100% для нових релізів перші 48 годин, потім знижуємо до 20–30%. Для пошуку рідкісних помилок (наприклад, ANR на 0.5% пристроїв) знадобиться високий семплінг. Збалансований вибір — 50%.
Налаштування на прикладі Datadog RUM
Інтеграція SDK
import DatadogRUM RUM.enable(with: RUM.Configuration( applicationID: "your-rum-app-id", sessionSampleRate: 80, // 80% сесій telemetrySampleRate: 20, trackBackgroundEvents: false // не трекаємо фонові події )) Інструментація екранів вручну (SwiftUI)
struct ProductListView: View { var body: some View { List(products) { product in ProductRow(product: product) } .trackRUMView(name: "ProductList") } } Моніторинг конкретного мережевого запиту
// З URLSession + Datadog let delegate = DDURLSessionDelegate() let session = URLSession(configuration: .default, delegate: delegate, delegateQueue: nil) Datadog автоматично інжектує x-datadog-trace-id у кожен запит через цей session — жодних додаткових перехоплювачів.
Типові проблеми при впровадженні RUM
Частий баг — View закривається занадто рано. Наприклад, у UIKit без явного виклику stopView агент закриває View при viewWillDisappear, але якщо контролер показує bottom sheet поверх себе — View закриється і відкриється знову, створивши дублюючий запис. Рішення:
// iOS — явне управління View lifecycle override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) RUM.monitor?.startView(viewController: self, name: "ProductDetail") } override func viewWillDisappear(_ animated: Bool) { super.viewWillDisappear(animated) if isMovingFromParent { RUM.monitor?.stopView(viewController: self) } } Процес впровадження RUM
| Етап | Тривалість | Результат |
|---|---|---|
| Аналіз поточного додатку | 0.5 дня | Список вузьких місць |
| Вибір інструменту та архітектура | 0.5 дня | Технічне завдання |
| Інтеграція SDK та інструментація | 1–2 дні | Робочий прототип на стейджингу |
| Тестування та A/Б-тест з синтетикою | 1 день | Верифікація даних |
| Деплой на продакшн та запуск дашбордів | 0.5 дня | Моніторинг у реальному часі |
Що входить в роботу?
- Вибір інструменту під стек та бюджет (Datadog / Sentry / Firebase / New Relic)
- Підключення SDK з оптимальним sessionSampleRate
- Інструментація View-переходів (iOS, Android, Flutter)
- Налаштування HTTP-перехоплювача для трекінгу мережевих ресурсів
- Конфігурація consent-логіки під GDPR
- Побудова дашборду: р75/p95 View load time, Error Rate, Long Task Rate
- Навчання команди роботі з дашбордами
Терміни та вартість
Базова настройка RUM займає 1–2 дні. Кастомні атрибути та дашборди — ще 1–2 дні. У середньому впровадження окупається за 2–3 місяці за рахунок скорочення часу на пошук багів. Вартість розраховується індивідуально залежно від складності додатку та обраного інструменту. Зв'яжіться з нами для точної оцінки. Наша команда має 7+ років досвіду в мобільній розробці. Отримайте консультацію з вибору інструменту RUM.