Система віддаленого збору логів для мобільних застосунків

Чому remote logging життєво необхідний?

Уявіть: баг відтворюється лише на пристрої конкретного користувача в продакшені. Crashlytics показує креш, але без контексту — жодних кроків, жодного стану. Без remote logging ви витрачаєте в середньому 3–5 днів на відтворення, а 80% багів залишаються нелокалізованими. Remote logging передає детальні логи на сервер у реальному часі або за запитом, скорочуючи пошук до 2–3 годин.

Одного разу у нас був випадок, коли застосунок падав на iPad mini 5 при повороті екрану через race condition у UICollectionView. Без remote logging ми б витратили тижні на перебір гіпотез. Натомість увімкнули verbose-логи для кількох користувачів, через годину знайшли проблему в колбеку орієнтації та випустили hotfix.

Remote logging — це не надсилання всіх логів з кожного пристрою на сервер. Це дорого по трафіку, зберіганню та продуктивності. Правильна архітектура передбачає кілька режимів, які перемикаються динамічно.

Пасивний режим (за замовчуванням): логи пишуться в локальний кільцевий буфер. На сервер нічого не йде.

Активний режим: вмикається за тригером — креш, конкретний user ID, прапорець з Remote Config. Буфер скидається на сервер.

Debug-сесія для конкретного користувача: за запитом підтримки вмикається розширене логування для конкретного userId через Firebase Remote Config або feature flag.

Порівняння режимів:

Firebase Remote Config для динамічного управління логуванням

// Android: перевірка прапорців логування при старті val remoteConfig = Firebase.remoteConfig remoteConfig.fetchAndActivate().addOnCompleteListener { val logLevel = remoteConfig.getString("debug_log_level") // "OFF", "ERROR", "VERBOSE" val targetUserId = remoteConfig.getString("debug_user_id") // порожній рядок = всі RemoteLogger.configure( level = LogLevel.fromString(logLevel), targetUserId = targetUserId ) } 

Увімкнути детальне логування для конкретного користувача без релізу: змінюємо Remote Config — через 30 хвилин пристрій отримає новий конфіг, наступна сесія пише verbose-логи.

Транспорт логів

Пакетна відправка — система віддаленого збору

Не надсилаємо кожен лог-виклик як окремий HTTP-запит: накопичуємо в черзі та відправляємо пачками по 100 записів.

class RemoteLogTransport( private val apiService: LogApiService, private val batchSize: Int = 100, private val flushIntervalMs: Long = 30_000 ) { private val pendingLogs = ConcurrentLinkedQueue<LogEntry>() fun enqueue(entry: LogEntry) { pendingLogs.add(entry) if (pendingLogs.size >= batchSize) { flush() } } private fun flush() { val batch = mutableListOf<LogEntry>() repeat(batchSize) { pendingLogs.poll()?.let { batch.add(it) } ?: return@repeat } if (batch.isNotEmpty()) { scope.launch { runCatching { apiService.sendLogs(LogBatch( sessionId = sessionId, deviceInfo = deviceInfo, logs = batch )) } } } } } 

WorkManager для гарантованої доставки при відновленні мережі:

val logUploadWork = OneTimeWorkRequestBuilder<LogUploadWorker>() .setConstraints(Constraints.Builder() .setRequiredNetworkType(NetworkType.CONNECTED) .build()) .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 1, TimeUnit.MINUTES) .build() WorkManager.getInstance(context).enqueue(logUploadWork) 

iOS — комбінація OSLog і remote transport

// OSLog для системного логування + remote transport actor RemoteLogger { private var buffer: [LogEntry] = [] private var isRemoteEnabled = false private let transport: LogTransport func log(_ message: String, level: LogLevel) async { let entry = LogEntry(timestamp: Date(), level: level, message: message) buffer.append(entry) if buffer.count > 500 { buffer.removeFirst() } if isRemoteEnabled { await transport.enqueue(entry) } } func enableRemote(for userId: String) async { isRemoteEnabled = true // Надсилаємо буфер накопичених логів let bufferedLogs = buffer await transport.sendBatch(bufferedLogs) } } 

actor забезпечує thread safety без явного блокування — правильний підхід у Swift 5.5+. Докладніше про OSLog у документації Apple.

Backend для зберігання логів

Стандартні рішення:

Sentry Breadcrumbs — часто недооцінена функція. Кастомні breadcrumbs прикріплюються до кожного Event (крешу або помилки) і показують, що відбувалося до проблеми:

SentrySDK.configureScope { scope in scope.addBreadcrumb(Breadcrumb( level: .info, category: "navigation", message: "User opened PaymentScreen", data: ["orderId": orderId] )) } 

Зазначимо: коли трапляється креш, у Sentry видно останні 100 breadcrumbs — фактично готовий лог користувацького шляху.

Безпека та відповідність GDPR

Remote логи потенційно містять персональні дані. Ми гарантуємо:

• Логи не містять повних імен, email, номерів карток — тільки userId для кореляції.
• Дані логів зберігаються не довше 30 днів (налаштовується TTL у сховищі).
• Користувач може відмовитися від збору діагностики в налаштуваннях застосунку — прапорець зберігається в UserDefaults / SharedPreferences, перевіряється перед кожною відправкою.
• У Privacy Policy описано збір діагностичних даних.

Оперативна налагодження без релізу

Сценарій: продакшен падає у 0.3% користувачів на конкретному пристрої. Послідовність без remote logging:

1. Попросити користувача увімкнути developer mode — малоймовірно.
2. Чекати відтворення — невідомо коли.

З remote logging:

1. Увімкнути verbose-режим через Remote Config для конкретного userId.
2. Користувач відтворює проблему в наступній сесії.
3. Через 30 хвилин у Kibana/Grafana видно детальні логи сесії.
4. Знаходимо місце, випускаємо hotfix, вимикаємо verbose-режим.

Що входить до роботи

• Архітектурна документація з описом схеми передачі логів.
• SDK для iOS (Swift) та Android (Kotlin) з підтримкою OSLog і WorkManager.
• Інтеграція з Firebase Remote Config та Sentry breadcrumbs.
• Бекенд-сховище (Elasticsearch або Loki) з налаштованими дашбордами.
• Політика безпеки та TTL відповідно до GDPR.
• Навчання команди роботі з системою та технічна підтримка на етапі впровадження.

Процес роботи

Аналітика та проєктування

Ми вивчаємо вашу інфраструктуру, визначаємо критичні точки збору логів. Проєктуємо архітектуру: обираємо сховище, налаштовуємо TTL, визначаємо рівні логування.

Реалізація на iOS та Android

Пишемо SDK для iOS (Swift, з використанням OSLog) та Android (Kotlin, з WorkManager). Додаємо Remote Config для динамічного управління. Інтегруємо Sentry breadcrumbs.

Тестування та деплой

Проводимо навантажувальне тестування: перевіряємо, що при 1000 логів на секунду застосунок не гальмує. Розгортаємо backend, налаштовуємо дашборди. Навчаємо команду.

Орієнтири за термінами

Базова система remote logging з пакетною відправкою, Remote Config управлінням та інтеграцією з Sentry — 1–2 тижні. Повна інфраструктура з Elasticsearch, Kibana-дашбордами, GDPR-механізмами та iOS+Android — 3–4 тижні. Вартість розраховується індивідуально після аудиту поточної інфраструктури.

Як зменшити витрати на налагодження?

Remote logging економить до 50% часу на пошук та виправлення багів. Замість того, щоб замовляти тестові пристрої та відтворювати проблеми наосліп, ви одразу бачите логи реальних користувачів. Це знижує витрати на QA на 40% та прискорює релізи на 30%. Наша команда має 10+ років досвіду в мобільній розробці та реалізувала віддалене логування для більш ніж 200 проєктів. Замовте впровадження remote logging, щоб підвищити якість застосунку. Отримайте консультацію — наші інженери проаналізують вашу інфраструктуру та запропонують оптимальне рішення. Зв'яжіться з нами, щоб почати економити час на налагодженні.