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

Що таке Remote Logging

Remote Logging — це процес збору логів з віддалених пристроїв та їх передачі на центральний сервер для аналізу. У контексті мобільної розробки remote logging включає не лише звіти про збої (crash reporting), але й кастомні події, breadcrumbs, метрики продуктивності та сценарії користувачів.

Основна відмінність remote logging від crash reporting — проактивність. Crash reporting збирає лише дані про збої додатку, які вже сталися. Remote logging збирає послідовність подій до збою: які екрани відкривав користувач, які запити робив, які дані вводив. Це дозволяє відтворити сценарій помилки без спілкування з користувачем.

Apple надає вбудований механізм віддаленого збору логів через .logarchive, але для production-додатків практично завжди використовуються сторонні сервіси. Android SDK включає Logcat, який доступний віддалено через ADB, але не для пристроїв кінцевих користувачів без налагодження.

Архітектура віддаленого збору логів

Архітектура remote logging складається з трьох компонентів: клієнтський SDK на пристрої, який збирає та буферизує логи, транспортний протокол для відправки даних та сервер для зберігання та візуалізації.

Клієнтський SDK буферизує логи в оперативній пам'яті та періодично скидає їх на сервер пачками (batches). Якщо пристрій офлайн, логи зберігаються в локальному файлі та відправляються при наступному підключенні до мережі. Розмір буфера та інтервал відправки налаштовуються: типові значення — 50 подій або 30 секунд.

Транспортні протоколи

HTTPS REST — найпоширеніший протокол для remote logging. SDK серіалізує логи в JSON та відправляє POST-запитами на endpoint сервера. gRPC — альтернатива з бінарною серіалізацією (Protocol Buffers), яка на 30–40% компактніша за JSON та швидша на мобільних пристроях з нестабільним з'єднанням. WebSocket використовується для логування в реальному часі під час налагодження, але рідко в production через енергоспоживання.

Firebase Crashlytics: збір збоїв та логів

Firebase Crashlytics — безкоштовний сервіс Google для збору звітів про збої та кастомних логів. Він вбудований в Firebase SDK та не потребує окремого сервера. Crashlytics автоматично збирає stack trace, стан пристрою, версію ОС та відкриті екрани на момент збою.

Кастомні логи в Crashlytics додаються через метод log() — вони не відправляються на сервер негайно, а зберігаються в кільцевому буфері та прикріплюються до наступного звіту про збій. Це ключова відмінність від Sentry, де кожен лог — окрема подія. Максимальний обсяг кастомних логів в Crashlytics — 64 КБ на один збій.

// Firebase Crashlytics — кастомні логи на Android
import com.google.firebase.crashlytics.FirebaseCrashlytics

class CheckoutViewModel {
    fun processPayment(amount: Double) {
        FirebaseCrashlytics.getInstance()
            .log("Payment started: amount=$amount")
        try {
            process(amount)
        } catch (e: Exception) {
            FirebaseCrashlytics.getInstance()
                .recordException(e)
        }
    }
}

Firebase Crashlytics підтримує setUserIdentifier для зв'язування збоїв з конкретними користувачами. Це допомагає визначити, чи є баг масовим або впливає лише на одного користувача. setCustomKey додає довільні ключі до кожного звіту — версію A/B-тесту, регіон, тарифний план.

Sentry: breadcrumbs та контекст користувача

Sentry — платформа для моніторингу помилок, яка зберігає не лише звіти про збої, але й всі кастомні події (breadcrumbs) як самостійні записи. На відміну від Crashlytics, Sentry дозволяє переглядати послідовність подій до помилки в хронологічному порядку — breadcrumbs видно в інтерфейсі без необхідності відновлювати їх з логу збою.

Автоматичні breadcrumbs в Sentry

Sentry SDK автоматично збирає breadcrumbs для системних подій: зміни життєвого циклу UIViewController (viewDidLoad, viewWillAppear), дотики, натискання кнопок, HTTP-запити через URLSession. Всі ці події відображаються в таймлайні помилки разом з кастомними breadcrumbs. Для Android аналогічно збираються lifecycle Activity та Fragment, onClick-події та мережеві запити через OkHttp.

Sentry SDK для iOS та Android автоматично збирає breadcrumbs UI-подій: дотики, навігація, життєвий цикл. Розробник може додавати кастомні breadcrumbs через addBreadcrumb() із зазначенням типу, категорії та рівня. Sentry підтримує distributed tracing: логгер пов'язує breadcrumbs на клієнті з запитами на бекенді через trace ID.

import Sentry

func trackCartEvent(action: String, itemId: String) {
    let crumb = Breadcrumb()
    crumb.level = .info
    crumb.category = "cart"
    crumb.message = "Cart \(action): \(itemId)"
    crumb.data = ["action": action, "item_id": itemId]
    SentrySDK.addBreadcrumb(crumb)
}

Logcat та віддалений доступ через ADB

Logcat — штатна система логування Android, доступна через Android Debug Bridge (ADB). Logcat збирає всі системні та прикладні повідомлення, розбиті за рівнями (V, D, I, W, E, F) та тегами. Віддалений доступ до Logcat працює через ADB по USB або Wi-Fi, але тільки для пристроїв в режимі налагодження — production-додатки на пристроях без USB-підключення недоступні.

Для remote logging в production на Android використовуються альтернативи: Logcat сам по собі не вміє відправляти логи на сервер. Його роль — локальна діагностика. Але існують обгортки (Timber, LogcatLive), які форвардять повідомлення в Firebase або Sentry, зберігаючи звичний API Log.d / Log.e. Timber дозволяє перемикати обробники без зміни коду додатку — debug-дерево пише в Logcat, release-дерево відправляє на сервер з батчингом та стисненням.

Батчинг та оптимізація трафіку

Батчинг — групування кількох логів в один HTTP-запит для економії трафіку та батареї. Замість 50 окремих POST-запитів SDK відправляє один масив JSON. Типові стратегії: відправка за розкладом (кожні 30 секунд), за кількістю (кожні 50 подій) або за подією (тільки при критичній помилці).

Для додатків з мільйонами користувачів обсяг логів може сягати терабайт на день. Батчинг скорочує кількість запитів у 10–50 разів та знижує навантаження на сервер. Sentry використовує стиснення gzip на транспортному рівні, що додатково зменшує обсяг даних на 60–70%.

// Проста реалізація батчингу на Android
class LogBatcher {
    private val buffer = mutableListOf<LogEvent>()
    private val maxSize = 50
    private val intervalMs = 30_000L

    fun append(event: LogEvent) {
        buffer.add(event)
        if (buffer.size >= maxSize) flush()
    }

    suspend fun flush() {
        val batch = buffer.toList()
        buffer.clear()
        sendToServer(batch)
    }
}

Стиснення та дедуплікація

gzip — стандартний метод стиснення для HTTP-передачі логів. SDK Sentry та Crashlytics автоматично стискають тіло запиту перед відправкою. Дедуплікація — видалення повторюваних повідомлень на стороні клієнта: якщо одна й та сама подія ловиться 100 разів на секунду, SDK відправляє її один раз з полем count = 100.

Типові помилки віддаленого логування

Найпоширеніша помилка — логування чутливих даних. Remote logging SDK передає дані на сервер, і якщо розробник випадково логує пароль, токен або email користувача, ці дані опиняються в хмарній інфраструктурі. Завжди використовуйте фільтрацію PII (Personally Identifiable Information) на рівні SDK: Sentry має вбудований beforeSend-хук для очищення даних перед відправкою.

Друга поширена проблема — надмірне логування. Якщо кожен рух пальця відправляється на сервер, обсяг даних зростає експоненційно, а серверні витрати — теж. Визначте бюджет на логи: не більше 1–5 подій на користувача на хвилину в production. Debug-логи відправляйте лише з прапорцем, який включається для конкретних пристроїв.

Третя помилка — ігнорування офлайн-сценарію. Якщо SDK втрачає логи при відсутності мережі та не відновлює їх при reconnect, remote logging марний для користувачів з нестабільним з'єднанням. Всі SDK (Firebase, Sentry) автоматично кешують логи в локальний файл та відправляють при появі мережі, але це налаштування потрібно перевіряти.