Remote Logging — ce que c'est, outils de collecte et méthodes d'analyse à distance des logs

Qu'est-ce que Remote Logging

Remote Logging est le processus de collecte de logs à partir d'appareils distants et de leur transmission à un serveur central pour analyse. Dans le contexte du développement mobile, le remote logging inclut non seulement les rapports de crash, mais aussi les événements personnalisés, les breadcrumbs, les métriques de performance et les scénarios utilisateur.

La principale différence entre le remote logging et le crash reporting est la proactivité. Le crash reporting collecte uniquement les données sur les crashs d'application déjà survenus. Le remote logging collecte la séquence d'événements avant le crash : quels écrans l'utilisateur a ouverts, quelles requêtes il a effectuées, quelles données il a saisies. Cela permet de reproduire le scénario d'erreur sans communiquer avec l'utilisateur.

Apple fournit un mécanisme intégré de collecte à distance des logs via .logarchive, mais pour les applications de production, des services tiers sont presque toujours utilisés. Le SDK Android inclut Logcat, accessible à distance via ADB, mais pas pour les appareils des utilisateurs finaux sans mode de débogage.

Architecture de la collecte à distance des logs

L'architecture du remote logging se compose de trois composants : le SDK client sur l'appareil qui collecte et met en mémoire tampon les logs, le protocole de transport pour envoyer les données, et le serveur pour le stockage et la visualisation.

Le SDK client met en mémoire tampon les logs dans la RAM et les envoie périodiquement au serveur par lots. Si l'appareil est hors ligne, les logs sont sauvegardés dans un fichier local et envoyés lors de la prochaine connexion réseau. La taille du tampon et l'intervalle d'envoi sont configurables : les valeurs typiques sont de 50 événements ou 30 secondes.

Protocoles de transport

HTTPS REST est le protocole le plus courant pour le remote logging. Le SDK sérialise les logs en JSON et les envoie via des requêtes POST au point de terminaison du serveur. gRPC est une alternative avec sérialisation binaire (Protocol Buffers), qui est 30 à 40% plus compacte que JSON et plus rapide sur les appareils mobiles avec des connexions instables. WebSocket est utilisé pour la journalisation en temps réel lors du débogage, mais rarement en production en raison de la consommation d'énergie.

Firebase Crashlytics : collecte des crashs et des logs

Firebase Crashlytics est un service gratuit de Google pour collecter les rapports de crash et les logs personnalisés. Il est intégré au SDK Firebase et ne nécessite pas de serveur séparé. Crashlytics collecte automatiquement les stack traces, l'état de l'appareil, la version de l'OS et les écrans ouverts au moment du crash.

Les logs personnalisés dans Crashlytics sont ajoutés via la méthode log() — ils ne sont pas envoyés immédiatement au serveur mais stockés dans un tampon circulaire et attachés au prochain rapport de crash. C'est une différence clé avec Sentry, où chaque log est un événement séparé. Le volume maximum des logs personnalisés dans Crashlytics est de 64 Ko par crash.

// Firebase Crashlytics — logs personnalisés sur 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 supporte setUserIdentifier pour lier les crashs à des utilisateurs spécifiques. Cela permet de déterminer si un bug est massif ou n'affecte qu'un seul utilisateur. setCustomKey ajoute des clés arbitraires à chaque rapport — version de test A/B, région, plan tarifaire.

Sentry : breadcrumbs et contexte utilisateur

Sentry est une plateforme de surveillance des erreurs qui stocke non seulement les rapports de crash, mais aussi tous les événements personnalisés (breadcrumbs) comme enregistrements indépendants. Contrairement à Crashlytics, Sentry permet de visualiser la séquence d'événements avant l'erreur dans l'ordre chronologique — les breadcrumbs sont visibles dans l'interface sans avoir à les reconstruire à partir du log de crash.

Breadcrumbs automatiques dans Sentry

Le SDK Sentry collecte automatiquement les breadcrumbs pour les événements système : changements de cycle de vie UIViewController (viewDidLoad, viewWillAppear), touches, pressions de boutons, requêtes HTTP via URLSession. Tous ces événements apparaissent dans la chronologie de l'erreur avec les breadcrumbs personnalisés. Pour Android, le cycle de vie des Activity et Fragment, les événements onClick et les requêtes réseau via OkHttp sont collectés de manière similaire.

Le SDK Sentry pour iOS et Android collecte automatiquement les breadcrumbs des événements UI : touches, navigation, cycle de vie. Les développeurs peuvent ajouter des breadcrumbs personnalisés via addBreadcrumb() en spécifiant le type, la catégorie et le niveau. Sentry supporte le distributed tracing : le logger lie les breadcrumbs côté client aux requêtes backend via un ID de 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 et accès à distance via ADB

Logcat est le système de journalisation standard d'Android, accessible via Android Debug Bridge (ADB). Logcat collecte tous les messages système et d'application, organisés par niveaux (V, D, I, W, E, F) et tags. L'accès à distance à Logcat fonctionne via ADB par USB ou Wi-Fi, mais uniquement pour les appareils en mode débogage — les applications de production sur les appareils sans connexion USB ne sont pas accessibles.

Pour la journalisation à distance en production sur Android, des alternatives sont utilisées : Logcat lui-même ne peut pas envoyer de logs à un serveur. Son rôle est le diagnostic local. Cependant, il existe des wrappers (Timber, LogcatLive) qui transfèrent les messages vers Firebase ou Sentry tout en conservant l'API familière Log.d / Log.e. Timber permet de changer de gestionnaire sans modifier le code de l'application — un arbre de débogage écrit dans Logcat, un arbre de release envoie au serveur avec batching et compression.

Batching et optimisation du trafic

Batching est le regroupement de plusieurs logs en une seule requête HTTP pour économiser le trafic et la batterie. Au lieu de 50 requêtes POST individuelles, le SDK envoie un seul tableau JSON. Les stratégies typiques sont : envoi programmé (toutes les 30 secondes), par quantité (tous les 50 événements) ou par événement (uniquement en cas d'erreur critique).

Pour les applications avec des millions d'utilisateurs, le volume de logs peut atteindre des téraoctets par jour. Le batching réduit le nombre de requêtes de 10 à 50 fois et diminue la charge du serveur. Sentry utilise la compression gzip au niveau du transport, ce qui réduit encore le volume de données de 60 à 70%.

// Implémentation simple du batching sur 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 et déduplication

gzip est la méthode de compression standard pour la transmission HTTP des logs. Les SDK Sentry et Crashlytics compressent automatiquement le corps de la requête avant l'envoi. Déduplication — suppression des messages en double côté client : si le même événement se produit 100 fois par seconde, le SDK l'envoie une fois avec le champ count = 100.

Erreurs typiques de la journalisation à distance

L'erreur la plus courante est la journalisation de données sensibles. Les SDK de remote logging transmettent des données au serveur, et si un développeur journalise accidentellement un mot de passe, un jeton ou un e-mail utilisateur, ces données se retrouvent dans l'infrastructure cloud. Utilisez toujours un filtrage PII (Informations d'Identification Personnelle) au niveau du SDK : Sentry dispose d'un hook beforeSend intégré pour nettoyer les données avant l'envoi.

Le deuxième problème courant est la journalisation excessive. Si chaque mouvement de doigt est envoyé au serveur, le volume de données croît de manière exponentielle, tout comme les coûts serveur. Définissez un budget de journalisation : pas plus de 1 à 5 événements par utilisateur par minute en production. Envoyez les logs de débogage uniquement avec un flag activé pour des appareils spécifiques.

La troisième erreur est l'ignorance du scénario hors ligne. Si le SDK perd les logs en l'absence de réseau et ne les restaure pas lors de la reconnexion, le remote logging est inutile pour les utilisateurs ayant des connexions instables. Tous les SDK (Firebase, Sentry) mettent automatiquement en cache les logs dans un fichier local et les envoient lorsque le réseau est disponible, mais ce paramètre doit être vérifié.