Remote Logging — ano ito, mga tool sa pagtitipon at paraan ng malayuang pagsusuri ng log

Ano ang Remote Logging

Remote Logging ay proseso ng pagtitipon ng log mula sa malalayong device at pagpapadala ng mga ito sa sentral na server para sa pagsusuri. Sa konteksto ng mobile development, ang remote logging ay hindi lamang sumasaklaw sa crash reporting, kundi pati na rin sa custom na mga event, breadcrumbs, metrics ng pagganap, at mga scenario ng user.

Ang pangunahing pagkakaiba ng remote logging at crash reporting ay ang pagiging proactive. Ang crash reporting ay nangongolekta lamang ng data tungkol sa mga pag-crash ng app na naganap na. Ang remote logging ay nangongolekta ng pagkakasunod-sunod ng mga event bago ang crash: anong mga screen ang binuksan ng user, anong mga kahilingan ang ginawa, anong data ang inilagay. Ito ay nagbibigay-daan upang kopyahin ang scenario ng error nang hindi nakikipag-ugnayan sa user.

Apple ay nagbibigay ng built-in na mekanismo para sa malayuang pagtitipon ng log sa pamamagitan ng .logarchive, ngunit para sa production app ay halos palaging gumagamit ng third-party na serbisyo. Ang Android SDK ay may kasamang Logcat, na accessible nang malayuan sa pamamagitan ng ADB, ngunit hindi para sa end-user device na walang debugging mode.

Arkitektura ng malayuang pagtitipon ng log

Ang arkitektura ng remote logging ay binubuo ng tatlong bahagi: ang client SDK sa device na nangongolekta at nagba-buffer ng log, ang protocol ng transport para sa pagpapadala ng data, at ang server para sa pag-iimbak at visualization.

Ang client SDK ay nagba-buffer ng log sa RAM at pana-panahong nagpapadala ng mga ito sa server nang maramihan (batches). Kung offline ang device, ang mga log ay ini-save sa lokal na file at ipinapadala sa susunod na koneksyon sa network. Ang laki ng buffer at interval ng pagpapadala ay nako-configure: tipikal na halaga ay 50 event o 30 segundo.

Mga Protocol ng Transport

HTTPS REST — pinakakaraniwang protocol para sa remote logging. Sine-serialize ng SDK ang log sa JSON at ipinapadala ito sa pamamagitan ng POST request sa endpoint ng server. gRPC — alternatibo na may binary serialization (Protocol Buffers), na 30–40% mas compact kaysa JSON at mas mabilis sa mobile device na may hindi stable na koneksyon. WebSocket ay ginagamit para sa real-time logging sa debugging, ngunit bihira sa production dahil sa konsumo ng kuryente.

Firebase Crashlytics: pagtitipon ng crash at log

Firebase Crashlytics — libreng serbisyo ng Google para sa pagtitipon ng crash report at custom log. Ito ay naka-embed sa Firebase SDK at hindi nangangailangan ng hiwalay na server. Awtomatikong nangongolekta ang Crashlytics ng stack trace, estado ng device, bersyon ng OS, at mga bukas na screen sa oras ng crash.

Ang custom log sa Crashlytics ay idinaragdag sa pamamagitan ng log() method — hindi ito agad ipinapadala sa server, kundi iniimbak sa ring buffer at ikinakabit sa susunod na crash report. Ito ang pangunahing pagkakaiba sa Sentry, kung saan ang bawat log ay hiwalay na event. Ang maximum volume ng custom log sa Crashlytics ay 64 KB bawat crash.

// Firebase Crashlytics — custom log sa 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 ay sumusuporta sa setUserIdentifier para iugnay ang crash sa partikular na user. Ito ay tumutulong upang matukoy kung ang bug ay malawakan o nakakaapekto lamang sa isang user. Ang setCustomKey ay nagdaragdag ng arbitrary na key sa bawat report — bersyon ng A/B test, rehiyon, plano ng taripa.

Sentry: breadcrumbs at konteksto ng user

Sentry — platform ng pagsubaybay ng error na hindi lamang nag-iimbak ng crash report, kundi pati na rin ng lahat ng custom na event (breadcrumbs) bilang independiyenteng tala. Hindi tulad ng Crashlytics, pinapayagan ng Sentry na tingnan ang pagkakasunod-sunod ng mga event bago ang error sa kronolohikal na pagkakasunod — ang breadcrumbs ay nakikita sa interface nang hindi kinakailangan na buuin muli ang mga ito mula sa crash log.

Awtomatikong breadcrumbs sa Sentry

Awtomatikong nangongolekta ang Sentry SDK ng breadcrumbs para sa system event: mga pagbabago sa lifecycle ng UIViewController (viewDidLoad, viewWillAppear), touches, pag-click sa button, HTTP request sa pamamagitan ng URLSession. Lahat ng event na ito ay ipinapakita sa timeline ng error kasama ng custom breadcrumbs. Para sa Android, katulad na kinokolekta ang lifecycle ng Activity at Fragment, onClick event, at network request sa pamamagitan ng OkHttp.

Awtomatikong nangongolekta ang Sentry SDK para sa iOS at Android ng breadcrumbs ng UI event: touches, navigation, lifecycle. Maaaring magdagdag ang developer ng custom breadcrumbs sa pamamagitan ng addBreadcrumb() na may specifikasyon ng type, category, at level. Sinusuportahan ng Sentry ang distributed tracing: ang logger ay nag-uugnay ng breadcrumbs sa client sa backend request sa pamamagitan ng 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 at malayuang pag-access sa pamamagitan ng ADB

Logcat — karaniwang Android logging system, accessible sa pamamagitan ng Android Debug Bridge (ADB). Nangongolekta ang Logcat ng lahat ng system at application na mensahe, nahahati ayon sa level (V, D, I, W, E, F) at tag. Ang malayuang pag-access sa Logcat ay gumagana sa pamamagitan ng ADB sa USB o Wi-Fi, ngunit para lamang sa device na nasa debugging mode — ang production app sa device na walang USB connection ay hindi accessible.

Para sa malayuang logging sa production sa Android, ginagamit ang mga alternatibo: ang Logcat mismo ay hindi kayang magpadala ng log sa server. Ang papel nito ay lokal na diagnostiko. Ngunit may mga wrapper (Timber, LogcatLive) na nagfo-forward ng mensahe sa Firebase o Sentry, pinapanatili ang pamilyar na API ng Log.d / Log.e. Pinapayagan ng Timber na magpalit ng handler nang hindi binabago ang code ng app — ang debug tree ay sumusulat sa Logcat, ang release tree ay nagpapadala sa server na may batching at compression.

Batching at optimisasyon ng trapiko

Batching — pagpapangkat ng maraming log sa iisang HTTP request para makatipid sa trapiko at baterya. Sa halip na 50 hiwalay na POST request, nagpapadala ang SDK ng isang JSON array. Mga tipikal na estratehiya: pagpapadala ayon sa iskedyul (bawat 30 segundo), ayon sa bilang (bawat 50 event), o ayon sa event (sa kritikal na error lang).

Para sa app na may milyun-milyong user, ang volume ng log ay maaaring umabot sa terabyte bawat araw. Binabawasan ng batching ang bilang ng request ng 10–50 beses at binababa ang load ng server. Gumagamit ang Sentry ng gzip compression sa transport level, na dagdag na nagbabawas ng volume ng data ng 60–70%.

// Simpleng implementasyon ng batching sa 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)
    }
}

Compression at deduplikasyon

gzip — karaniwang paraan ng compression para sa HTTP transmission ng log. Ang Sentry at Crashlytics SDK ay awtomatikong nag-co-compress ng body ng request bago ipadala. Deduplikasyon — pagtanggal ng mga paulit-ulit na mensahe sa side ng client: kung ang parehong event ay nahuhuli ng 100 beses bawat segundo, ipinapadala ito ng SDK nang isang beses na may field na count = 100.

Mga karaniwang pagkakamali sa malayuang logging

Ang pinakakaraniwang pagkakamali — pagla-log ng sensitibong data. Ang remote logging SDK ay nagpapadala ng data sa server, at kung ang developer ay hindi sinasadyang na-log ang password, token o email ng user, ang data na ito ay napupunta sa cloud infrastructure. Palaging gumamit ng PII (Personally Identifiable Information) filtration sa SDK level: ang Sentry ay may built-in na beforeSend-hook para sa paglilinis ng data bago ipadala.

Ang ikalawang karaniwang problema — labis na logging. Kung ang bawat galaw ng daliri ay ipinapadala sa server, ang volume ng data ay lumalaki nang exponential, at ang gastos ng server ay tumataas din. Magtakda ng budget para sa log: hindi hihigit sa 1–5 event bawat user bawat minuto sa production. Ipadala ang debug log lamang na may flag na naka-on para sa partikular na device.

Ang ikatlong pagkakamali — pagwawalang-bahala sa offline scenario. Kung nawawala ang log ng SDK kapag walang network at hindi nire-restore ang mga ito sa reconnect, ang remote logging ay walang silbi para sa user na may hindi stable na koneksyon. Lahat ng SDK (Firebase, Sentry) ay awtomatikong nagca-cache ng log sa lokal na file at nagpapadala kapag may network, ngunit ang setting na ito ay kailangang i-verify.