Remote Logging — cos'è, strumenti di raccolta e metodi di analisi remota dei log

Cos'è Remote Logging

Remote Logging è il processo di raccolta di log da dispositivi remoti e la loro trasmissione a un server centrale per l'analisi. Nel contesto dello sviluppo mobile, remote logging include non solo crash report, ma anche eventi personalizzati, breadcrumbs, metriche di performance e scenari utente.

La differenza principale tra remote logging e crash reporting è la proattività. Crash reporting raccoglie solo i dati sui crash dell'applicazione già avvenuti. Remote logging raccoglie la sequenza di eventi prima del crash: quali schermate l'utente ha aperto, quali richieste ha fatto, quali dati ha inserito. Ciò consente di riprodurre lo scenario di errore senza comunicare con l'utente.

Apple fornisce un meccanismo integrato di raccolta remota dei log tramite .logarchive, ma per le applicazioni di produzione vengono quasi sempre utilizzati servizi di terze parti. L'SDK Android include Logcat, accessibile da remoto tramite ADB, ma non per i dispositivi degli utenti finali senza modalità di debug.

Architettura della raccolta remota dei log

L'architettura di remote logging è composta da tre componenti: l'SDK client sul dispositivo che raccoglie e bufferizza i log, il protocollo di trasporto per l'invio dei dati e il server per l'archiviazione e la visualizzazione.

L'SDK client bufferizza i log nella RAM e li invia periodicamente al server in batch. Se il dispositivo è offline, i log vengono salvati in un file locale e inviati alla successiva connessione di rete. La dimensione del buffer e l'intervallo di invio sono configurabili: i valori tipici sono 50 eventi o 30 secondi.

Protocolli di trasporto

HTTPS REST è il protocollo più comune per remote logging. L'SDK serializza i log in JSON e li invia tramite richieste POST all'endpoint del server. gRPC è un'alternativa con serializzazione binaria (Protocol Buffers), che è 30–40% più compatta di JSON e più veloce sui dispositivi mobili con connessioni instabili. WebSocket viene utilizzato per la registrazione in tempo reale durante il debug, ma raramente in produzione a causa del consumo energetico.

Firebase Crashlytics: raccolta di crash e log

Firebase Crashlytics è un servizio gratuito di Google per la raccolta di crash report e log personalizzati. È integrato nell'SDK Firebase e non richiede un server separato. Crashlytics raccoglie automaticamente stack trace, stato del dispositivo, versione del OS e schermate aperte al momento del crash.

I log personalizzati in Crashlytics vengono aggiunti tramite il metodo log() — non vengono inviati immediatamente al server ma vengono memorizzati in un buffer circolare e allegati al successivo crash report. Questa è una differenza fondamentale rispetto a Sentry, dove ogni log è un evento separato. Il volume massimo dei log personalizzati in Crashlytics è di 64 KB per crash.

// Firebase Crashlytics — log personalizzati su 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 supporta setUserIdentifier per collegare i crash a utenti specifici. Questo aiuta a determinare se un bug è massivo o colpisce solo un utente. setCustomKey aggiunge chiavi arbitrarie a ogni report — versione del test A/B, regione, piano tariffario.

Sentry: breadcrumbs e contesto utente

Sentry è una piattaforma di monitoraggio errori che memorizza non solo crash report, ma anche tutti gli eventi personalizzati (breadcrumbs) come record indipendenti. A differenza di Crashlytics, Sentry consente di visualizzare la sequenza di eventi prima dell'errore in ordine cronologico — i breadcrumbs sono visibili nell'interfaccia senza doverli ricostruire dal log del crash.

Breadcrumbs automatici in Sentry

L'SDK Sentry raccoglie automaticamente breadcrumbs per eventi di sistema: cambiamenti del ciclo di vita di UIViewController (viewDidLoad, viewWillAppear), tocchi, pressioni di pulsanti, richieste HTTP tramite URLSession. Tutti questi eventi appaiono nella timeline dell'errore insieme ai breadcrumbs personalizzati. Per Android, il ciclo di vita di Activity e Fragment, eventi onClick e richieste di rete tramite OkHttp vengono raccolti in modo simile.

L'SDK Sentry per iOS e Android raccoglie automaticamente breadcrumbs degli eventi UI: tocchi, navigazione, ciclo di vita. Gli sviluppatori possono aggiungere breadcrumbs personalizzati tramite addBreadcrumb() specificando tipo, categoria e livello. Sentry supporta distributed tracing: il logger collega i breadcrumbs lato client con le richieste backend tramite un ID di trace.

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 e accesso remoto tramite ADB

Logcat è il sistema di registrazione standard di Android, accessibile tramite Android Debug Bridge (ADB). Logcat raccoglie tutti i messaggi di sistema e delle applicazioni, organizzati per livelli (V, D, I, W, E, F) e tag. L'accesso remoto a Logcat funziona tramite ADB via USB o Wi-Fi, ma solo per dispositivi in modalità debug — le applicazioni di produzione su dispositivi senza connessione USB non sono accessibili.

Per la registrazione remota in produzione su Android, vengono utilizzate alternative: Logcat di per sé non può inviare log a un server. Il suo ruolo è la diagnostica locale. Tuttavia, esistono wrapper (Timber, LogcatLive) che inoltrano i messaggi a Firebase o Sentry mantenendo l'API familiare Log.d / Log.e. Timber consente di cambiare gestore senza modificare il codice dell'applicazione — un albero di debug scrive in Logcat, un albero di release invia al server con batching e compressione.

Batching e ottimizzazione del traffico

Batching è il raggruppamento di più log in un'unica richiesta HTTP per risparmiare traffico e batteria. Invece di 50 richieste POST individuali, l'SDK invia un singolo array JSON. Le strategie tipiche sono: invio programmato (ogni 30 secondi), per quantità (ogni 50 eventi) o per evento (solo in caso di errore critico).

Per applicazioni con milioni di utenti, il volume di log può raggiungere terabyte al giorno. Il batching riduce il numero di richieste di 10–50 volte e diminuisce il carico del server. Sentry utilizza la compressione gzip a livello di trasporto, riducendo ulteriormente il volume dei dati del 60–70%.

// Implementazione semplice del batching su 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)
    }
}

Compressione e deduplicazione

gzip è il metodo di compressione standard per la trasmissione HTTP dei log. Gli SDK Sentry e Crashlytics comprimono automaticamente il corpo della richiesta prima dell'invio. Deduplicazione — rimozione dei messaggi duplicati lato client: se lo stesso evento si verifica 100 volte al secondo, l'SDK lo invia una volta con il campo count = 100.

Errori tipici della registrazione remota

L'errore più comune è la registrazione di dati sensibili. Gli SDK di remote logging trasmettono dati al server e se uno sviluppatore registra accidentalmente una password, un token o un'email dell'utente, questi dati finiscono nell'infrastruttura cloud. Utilizzare sempre il filtraggio PII (Informazioni Personalmente Identificabili) a livello SDK: Sentry dispone di un hook beforeSend integrato per pulire i dati prima dell'invio.

Il secondo problema comune è la registrazione eccessiva. Se ogni movimento del dito viene inviato al server, il volume di dati cresce esponenzialmente, così come i costi del server. Definisci un budget di registrazione: non più di 1–5 eventi per utente al minuto in produzione. Invia i log di debug solo con un flag attivato per dispositivi specifici.

Il terzo errore è ignorare lo scenario offline. Se l'SDK perde i log in assenza di rete e non li ripristina alla riconnessione, remote logging è inutile per gli utenti con connessioni instabili. Tutti gli SDK (Firebase, Sentry) memorizzano automaticamente nella cache i log in un file locale e li inviano quando la rete è disponibile, ma questa impostazione deve essere verificata.