Remote Logging — шта је то, алати за прикупљање и начини даљинске анализе логова

Шта је Remote Logging

Remote Logging је процес прикупљања логова са удаљених уређаја и њиховог слања на централни сервер ради анализе. У контексту мобилног развоја, remote logging укључује не само crash извештаје (crash reporting), већ и прилагођене догађаје, breadcrumbs, метрике перформанси и корисничке сценарије.

Главна разлика између remote logging и crash reporting је проактивност. Crash reporting прикупља само податке о падовима апликације који су се већ догодили. Remote logging прикупља секвенцу догађаја пре краша: које екране је корисник отварао, које захтеве је слао, које податке је уносио. Ово омогућава репродукцију сценарија грешке без контакта са корисником.

Apple пружа уграђени механизам даљинског прикупљања логова преко .logarchive, али се за production апликације готово увек користе спољни сервиси. Android SDK укључује Logcat, који је даљински доступан преко ADB, али не за уређаје крајњих корисника без debug режима.

Архитектура даљинског прикупљања логова

Архитектура remote logging се састоји од три компоненте: клијентског SDK на уређају, који прикупља и баферише логове, транспортног протокола за слање података и сервера за складиштење и визуелизацију.

Клијентски SDK баферише логове у RAM меморији и периодично их шаље на сервер у пакетима (batches). Ако је уређај offline, логови се чувају у локалној датотеци и шаљу при следећем повезивању на мрежу. Величина бафера и интервал слања су подесиви: типичне вредности су 50 догађаја или 30 секунди.

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

HTTPS REST — најраспрострањенији протокол за remote logging. SDK серијализује логове у JSON и шаље POST захтевима на endpoint сервера. gRPC — алтернатива са бинарном серијализацијом (Protocol Buffers), која је 30–40% компактнија од JSON и бржа на мобилним уређајима са нестабилном везом. WebSocket се користи за логирање у реалном времену при debug-овању, али ретко у production-у због потрошње енергије.

Firebase Crashlytics: прикупљање крашева и логова

Firebase Crashlytics — бесплатни Google сервис за прикупљање crash извештаја и прилагођених логова. Уграђен је у Firebase SDK и не захтева посебан сервер. Crashlytics аутоматски прикупља stack trace, стање уређаја, верзију оперативног система и отворене екране у тренутку пада.

Прилагођени логови у Crashlytics се додају преко методе log() — они се не шаљу одмах на сервер, већ се чувају у кружном баферу и прилажу следећем crash извештају. Ово је кључна разлика у односу на Sentry, где је сваки лог засебан догађај. Максимална величина прилагођених логова у Crashlytics је 64 KB по крашу.

// 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 — платформа за надзор грешака која чува не само crash извештаје, већ и све прилагођене догађаје (breadcrumbs) као самосталне записе. За разлику од Crashlytics, Sentry омогућава преглед секвенце догађаја пре грешке у хронолошком редоследу — breadcrumbs су видљиви у интерфејсу без потребе за реконструкцијом из crash лога.

Аутоматски breadcrumbs у Sentry

Sentry SDK аутоматски прикупља breadcrumbs за системске догађаје: промене животног циклуса UIViewController (viewDidLoad, viewWillAppear), touches, кликове на дугмад, HTTP захтеве преко URLSession. Сви ови догађаји се приказују на временској линији грешке заједно са прилагођеним breadcrumbs. За Android се на сличан начин прикупљају lifecycle Activity и Fragment, onClick догађаји и мрежни захтеви преко OkHttp.

Sentry SDK за iOS и Android аутоматски прикупља breadcrumbs UI догађаја: touches, навигација, lifecycle. Програмер може додавати прилагођене breadcrumbs преко addBreadcrumb() са навођењем типа, категорије и нивоа. Sentry подржава distributed tracing: логер повезује breadcrumbs на клијенту са захтевима на backend-у преко 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, али само за уређаје у debug режиму — production апликације на уређајима без USB везе нису доступне.

За даљинско логирање у production-у на Android-у користе се алтернативе: Logcat сам по себи не уме да шаље логове на сервер. Његова улога је локална дијагностика. Али постоје омотачи (Timber, LogcatLive) који прослеђују поруке у Firebase или Sentry, чувајући познати API Log.d / Log.e. Timber омогућава пребацивање између handler-а без промене кода апликације — debug дрво пише у Logcat, release дрво шаље на сервер са batch-овањем и компресијом.

Batching и оптимизација саобраћаја

Batching — груписање више логова у један HTTP захтев ради уштеде саобраћаја и батерије. Уместо 50 одвојених POST захтева, SDK шаље један JSON низ. Типичне стратегије: слање по распореду (сваких 30 секунди), по броју (сваких 50 догађаја) или по догађају (само при критичној грешци).

За апликације са милионима корисника, обим логова може достићи терабајте дневно. Batching смањује број захтева 10–50 пута и смањује оптерећење сервера. Sentry користи gzip компресију на транспортном нивоу, што додатно смањује обим података за 60–70%.

// Једноставна имплементација batch-овања на 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 пренос логова. Sentry и Crashlytics SDK аутоматски компресују тело захтева пре слања. Дедупликација — уклањање понављајућих порука на страни клијента: ако се исти догађај ухвати 100 пута у секунди, SDK га шаље једном са пољем count = 100.

Типичне грешке даљинског логирања

Најчешћа грешка — логирање осетљивих података. Remote logging SDK преноси податке на сервер, и ако програмер случајно логира лозинку, токен или email корисника, ови подаци доспевају у облачну инфраструктуру. Увек користите PII (Lični identifikacioni podaci) филтрацију на нивоу SDK: Sentry има уграђени beforeSend-hook за чишћење података пре слања.

Други чест проблем — прекомерно логирање. Ако се сваки покрет прста шаље на сервер, обим података расте експоненцијално, а трошкови сервера такође. Одредите буџет за логове: не више од 1–5 догађаја по кориснику у минути у production-у. Debug логове шаљите само са флагом која се укључује за одређене уређаје.

Трећа грешка — игнорисање offline сценарија. Ако SDK губи логове при недостатку мреже и не обнавља их при поновном повезивању, remote logging је бескористан за кориснике са нестабилном везом. Сви SDK (Firebase, Sentry) аутоматски кеширају логове у локалну датотеку и шаљу при појави мреже, али ову поставку треба проверити.