Remote Logging — vad är det, insamlingsverktyg och metoder för fjärranalys av loggar

Vad är Remote Logging

Remote Logging är processen att samla in loggar från fjärrenheter och skicka dem till en central server för analys. I sammanhanget mobil utveckling omfattar remote logging inte bara crash-rapporter (crash reporting), utan även anpassade händelser, breadcrumbs, prestandamått och användarscenarier.

Den huvudsakliga skillnaden mellan remote logging och crash reporting är proaktivitet. Crash reporting samlar endast in data om appkrascher som redan har inträffat. Remote logging samlar in händelseförloppet före kraschen: vilka skärmar användaren öppnade, vilka förfrågningar de gjorde, vilken data de matade in. Detta gör det möjligt att återskapa felscenariot utan att kommunicera med användaren.

Apple tillhandahåller en inbyggd mekanism för fjärrinsamling av loggar via .logarchive, men för produktionsappar används nästan alltid tredjepartstjänster. Android SDK innehåller Logcat, som är tillgängligt på distans via ADB, men inte för slutanvändares enheter utan felsökningsläge.

Arkitektur för fjärrinsamling av loggar

Arkitekturen för remote logging består av tre komponenter: klient-SDK:n på enheten som samlar in och buffrar loggar, transportprotokollet för att skicka data och servern för lagring och visualisering.

Klient-SDK:n buffrar loggar i RAM-minnet och skickar dem periodiskt till servern i batcher. Om enheten är offline sparas loggarna i en lokal fil och skickas vid nästa nätverksanslutning. Bufferstorleken och sändningsintervallet är konfigurerbara: typiska värden är 50 händelser eller 30 sekunder.

Transportprotokoll

HTTPS REST — det vanligaste protokollet för remote logging. SDK:n serialiserar loggar till JSON och skickar dem via POST-förfrågningar till serverns endpoint. gRPC — ett alternativ med binär serialisering (Protocol Buffers), som är 30–40% mer kompakt än JSON och snabbare på mobila enheter med instabil anslutning. WebSocket används för realtidsloggning vid felsökning men sällan i produktion på grund av energiförbrukning.

Firebase Crashlytics: insamling av krascher och loggar

Firebase Crashlytics — Googles gratis tjänst för insamling av crash-rapporter och anpassade loggar. Den är inbyggd i Firebase SDK och kräver ingen separat server. Crashlytics samlar automatiskt in stacktrace, enhetsstatus, operativsystemversion och öppna skärmar vid kraschens ögonblick.

Anpassade loggar i Crashlytics läggs till via metoden log() — de skickas inte omedelbart till servern utan lagras i en ringbuffert och bifogas till nästa crash-rapport. Detta är den viktigaste skillnaden från Sentry, där varje logg är en separat händelse. Den maximala volymen anpassade loggar i Crashlytics är 64 KB per krasch.

// Firebase Crashlytics — anpassade loggar på 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 stöder setUserIdentifier för att koppla krascher till specifika användare. Detta hjälper till att avgöra om felet är massivt eller bara påverkar en användare. setCustomKey lägger till godtyckliga nycklar till varje rapport — A/B-testversion, region, taxaplan.

Sentry: breadcrumbs och användarkontext

Sentry — en plattform för felövervakning som inte bara lagrar crash-rapporter utan även alla anpassade händelser (breadcrumbs) som oberoende poster. Till skillnad från Crashlytics gör Sentry det möjligt att visa händelseförloppet före ett fel i kronologisk ordning — breadcrumbs syns i gränssnittet utan att behöva rekonstrueras från crash-logg.

Automatiska breadcrumbs i Sentry

Sentry SDK samlar automatiskt in breadcrumbs för systemhändelser: ändringar i UIViewControllers livscykel (viewDidLoad, viewWillAppear), beröringar, knapptryckningar, HTTP-förfrågningar via URLSession. Alla dessa händelser visas på felns tidslinje tillsammans med anpassade breadcrumbs. För Android samlas på liknande sätt Activity och Fragment-livscykler, onClick-händelser och nätverksförfrågningar via OkHttp.

Sentry SDK för iOS och Android samlar automatiskt in breadcrumbs för UI-händelser: beröringar, navigering, livscykel. Utvecklaren kan lägga till anpassade breadcrumbs via addBreadcrumb() med angivelse av typ, kategori och nivå. Sentry stöder distributed tracing: loggaren kopplar breadcrumbs på klienten till backend-förfrågningar via 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 och fjärråtkomst via ADB

Logcat — standard Android-loggning system, tillgängligt via Android Debug Bridge (ADB). Logcat samlar in alla system- och applikationsmeddelanden, indelade efter nivå (V, D, I, W, E, F) och taggar. Fjärråtkomst till Logcat fungerar via ADB via USB eller Wi-Fi, men endast för enheter i felsökningsläge — produktionsappar på enheter utan USB-anslutning är inte tillgängliga.

För fjärrloggning i produktion på Android används alternativ: Logcat kan inte själv skicka loggar till en server. Dess roll är lokal diagnostik. Men det finns wrappers (Timber, LogcatLive) som vidarebefordrar meddelanden till Firebase eller Sentry, samtidigt som de bevarar det välbekanta Log.d / Log.e API:et. Timber gör det möjligt att växla hanterare utan att ändra applikationskoden — debug-trädet skriver till Logcat, release-trädet skickar till servern med batching och komprimering.

Batching och trafikoptimering

Batching — gruppering av flera loggar i en HTTP-förfrågan för att spara trafik och batteri. Istället för 50 separata POST-förfrågningar skickar SDK:n en JSON-array. Typiska strategier: sändning enligt schema (var 30:e sekund), efter antal (var 50:e händelse) eller efter händelse (endast vid kritiskt fel).

För appar med miljontals användare kan loggvolymen nå terabyte per dag. Batching minskar antalet förfrågningar 10–50 gånger och minskar serverbelastningen. Sentry använder gzip-komprimering på transportnivå, vilket ytterligare minskar datavolymen med 60–70%.

// Enkel implementation av batching på 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)
    }
}

Komprimering och deduplicering

gzip — standardmetoden för komprimering vid HTTP-överföring av loggar. Sentry och Crashlytics SDK:er komprimerar automatiskt förfrågans kropp före sändning. Deduplicering — borttagning av dubbletter av meddelanden på klientsidan: om samma händelse fångas 100 gånger per sekund skickar SDK:n den en gång med fältet count = 100.

Typiska misstag vid fjärrloggning

Det vanligaste misstaget — loggning av känslig data. Remote logging SDK överför data till servern, och om en utvecklare av misstag loggar användarens lösenord, token eller e-post, hamnar dessa data i molninfrastrukturen. Använd alltid PII-filtering (Personligt Identifierbar Information) på SDK-nivå: Sentry har en inbyggd beforeSend-hook för att rensa data före sändning.

Det andra vanliga problemet — överdriven loggning. Om varje fingerrörelse skickas till servern växer datavolymen exponentiellt och serverkostnaderna också. Sätt en budget för loggar: inte mer än 1–5 händelser per användare per minut i produktion. Skicka debug-loggar endast med en flagga som aktiveras för specifika enheter.

Det tredje misstaget — ignorering av offline-scenariot. Om SDK:n förlorar loggar vid nätverksbrist och inte återställer dem vid återanslutning är remote logging värdelöst för användare med instabil anslutning. Alla SDK:er (Firebase, Sentry) cachar automatiskt loggar i en lokal fil och skickar dem när nätverket är tillgängligt, men denna inställning måste kontrolleras.