Моніторинг продуктивності — що це, метрики та збір даних

Що таке моніторинг продуктивності

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

За даними Google (2024), 53% користувачів закривають додаток, якщо він завантажується довше 3 секунд. Кожна додаткова секунда затримки знижує конверсію на 20% в середньому по категоріях. Це робить моніторинг продуктивності не просто технічною практикою, а бізнес-необхідністю для мобільних продуктів.

Сучасний моніторинг продуктивності охоплює чотири рівні: клієнтська частина (iOS, Android), мережа (API-запити, WebSocket), бекенд-сервіси та інфраструктура. У мобільній розробці фокус зміщено на клієнтські метрики, оскільки саме на пристрої користувача виникає більшість проблем із продуктивністю.

Ключові метрики мобільного додатка

Для повноцінного моніторингу необхідно відстежувати п'ять груп метрик, кожна з яких відповідає за свій аспект користувацького досвіду. FPS (frames per second) показує плавність анімацій та скролу — значення нижче 30 кадрів на секунду відчувається оком як гальмування.

Метрики часу

Час холодного старту додатка — від моменту тапу на іконку до повної готовності UI. Час гарячого старту — повернення з фону. Час відгуку на користувацьку дію (tap-to-response). Startup time для Android вимірюється через ActivityManager, для iOS — через dyld та premain time. За даними Firebase Performance, медіанний час холодного старту для топ-100 додатків становить 1.8 секунди.

Метрики пам'яті та CPU

Споживання оперативної пам'яті не повинно перевищувати 80% від доступного обсягу на пристрої, інакше система починає вивантажувати додаток із фону. Memory footprint відстежується через Xcode Instruments (iOS) та Android Profiler. Витоки пам'яті виявляються по зростанню споживання при повторюваних операціях — наприклад, переході між екранами.

Мережеві метрики

Час виконання HTTP-запиту, розмір відповіді, частота таймаутів та помилок. Network latency особливо критична для мобільних додатків, що працюють в умовах нестабільного з'єднання (3G, метро, ліфт, роумінг). Рекомендується відстежувати p95 час відповіді — саме він показує досвід най«важчих» користувачів з найгіршими мережевими умовами.

Real User Monitoring та Synthetic Monitoring

Real User Monitoring (RUM) збирає дані з реальних пристроїв користувачів у production-середовищі. Цей метод показує фактичні затримки, які відчувають користувачі з урахуванням їхніх пристроїв, версій ОС, мережі та геолокації. RUM дає найбільш точну картину продуктивності, але залежить від того, які користувачі потрапили у вибірку.

Synthetic Monitoring, навпаки, виконує заздалегідь задані сценарії на тестових пристроях у контрольованих умовах. Він дозволяє виявити регресію до того, як вона потрапить до користувачів, та відтворювати проблеми на однаковому оточенні. Firebase Test Lab та BrowserStack надають синтетичні тести на реальних пристроях без ручного запуску.

Оптимальна стратегія — комбінація обох підходів: синтетичні тести ловлять регресії на CI-етапі, а RUM дає реальну картину в production. За даними Datadog (2024), команди, які використовують обидва методи, виявляють на 35% більше проблем із продуктивністю до того, як вони стають інцидентами.

Налаштування Firebase Performance Monitoring

Firebase Performance Monitoring — безкоштовний інструмент від Google для збору метрик продуктивності на iOS та Android. Він автоматично вимірює час старту додатка, HTTP-запити та рендеринг екранів без написання коду. Для встановлення достатньо додати SDK в проект та активувати модуль Performance в консолі Firebase.

Автоматичний збір метрик

Після підключення SDK Firebase Performance автоматично створює trace для кожного HTTP-запиту через URLSession (iOS) або OkHttp (Android). Screen rendering вимірюється для UIViewController та Activity, фіксуючи час від onCreate/viewDidLoad до завершення першого рендеру. Всі метрики агрегуються в консолі Firebase з розбивкою по версіях додатка, пристроям та країнам.

import com.google.firebase.perf.FirebasePerformance
import com.google.firebase.perf.metrics.Trace

class PaymentService {
    private val firebasePerf = FirebasePerformance.getInstance()

    fun processPayment(amount: Double) {
        val trace = firebasePerf.newTrace("payment-flow")
        trace.start()
        trace.putAttribute("amount", amount.toString())
        // виконання платежу
        trace.stop()
    }
}

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

HTTP-моніторинг

Firebase автоматично перехоплює мережеві запити та фіксує URL, код відповіді, розмір payload та час виконання. Для OkHttp на Android автоматична інструментація працює без додаткового налаштування. Network requests відображаються в консолі з групуванням по ендпоінтах, що дозволяє швидко виявити уповільнення конкретного API.

Кастомні trace для бізнес-логіки

Стандартні метрики покривають загальну продуктивність, але для діагностики бізнес-процесів потрібно інструментувати конкретні сценарії. Кастомні trace дозволяють виміряти час виконання аутентифікації, завантаження стрічки новин, обробки зображення або синхронізації даних.

Кожен кастомний trace повинен мати осмислене ім'я у форматі «сценарій-дія» та містити атрибути для фільтрації. Наприклад, trace «image-upload» з атрибутами «file_size» та «compression_quality» дозволить виявити залежність часу завантаження від розміру зображення. Рекомендується не створювати більше 20 кастомних trace на один екран — надмірна інструментація створює шум та ускладнює аналіз.

import FirebasePerformance

func trackImageUpload(data: Data) {
    let trace = Performance.startTrace(name: "image-upload")
    trace?.setValue(data.count, forAttribute: "file_size")
    trace?.setValue("high", forAttribute: "compression")
    // завантаження зображення
    trace?.stop()
}

Приклад на Swift створює trace для завантаження зображення з атрибутами розміру файлу та рівня стиснення. В консолі Firebase ці атрибути стають полями для групування та фільтрації метрик.

Пороги спрацьовування та алертинг

Збір метрик без системи оповіщення не має сенсу. Алертинг повинен оповіщати команду про вихід метрик за допустимі межі, причому пороги спрацьовування поділяються на три рівні: попередження (warning), критичний (critical) та аварійний (outage). Кожен рівень визначає канал оповіщення: warning — у Slack-канал команди, critical — у PagerDuty черговому інженеру, outage — масова розсилка всім stakeholders.

Для мобільних метрик рекомендується використовувати динамічні пороги на основі процентилів: p95 час холодного старту перевищує 4 секунди — критичний алерт. Статичні пороги (наприклад, CPU > 90%) працюють гірше, оскільки не враховують нормальні коливання навантаження по часу доби та дню тижня. Firebase Performance підтримує налаштування алертів через Firebase Console з відправкою в Slack, PagerDuty та електронною поштою з можливістю ескалації при відсутності підтвердження.

За даними Incident Management Survey (2024), команди, які налаштовують алерти на основі процентилів, а не середніх значень, пропускають на 45% менше інцидентів. Середнє значення (average) згладжує викиди — p95 гарантовано показує найгірший сценарій для користувачів, незалежно від часу доби та сезонних коливань навантаження.