Log Level in der App-Entwicklung: Was es ist, Arten von Stufen und Konfiguration

Was ist Log Level?

Log Level ist ein Attribut jeder Log-Nachricht, das deren Wichtigkeit und Dringlichkeit der Verarbeitung bestimmt. Moderne iOS- und Android-Plattformen unterstützen eine einheitliche Skala von 6–7 Stufen: von der detailliertesten (Verbose/Trace) bis zur kritischen (Error/Assert). Die Wahl der Stufe bestimmt, ob die Nachricht bei der aktuellen Anwendungskonfiguration in das Log geschrieben wird.

Das Konzept des Log Level basiert auf dem Prinzip der Kritikalitätspyramide: Je höher die Stufe, desto weniger Nachrichten werden auf ihr ausgegeben. Laut Semaphore CI, 2024 sieht die Verteilung in einer Produktionsanwendung wie folgt aus: Info — 60% der Nachrichten, Warn — 25%, Error — 10%, Debug — 5%. Verbose-Nachrichten sollten in der Produktion vollständig deaktiviert sein.

Jede Plattform implementiert Log Level über ihre eigene API. Android verwendet android.util.Log mit den Methoden v(), d(), i(), w(), e(). Apple verwendet OSLog mit den Stufen default, info, debug, error, fault. Bibliotheken wie Timber und CocoaLumberjack fügen zusätzliche Funktionalität auf diesen Standard-APIs hinzu.

Laut Google I/O 2023 ist die falsche Wahl des Log Level die Ursache für 40% der Leistungsprobleme in der Produktion. Entwickler hinterlassen Debug-Logs in Release-Builds, was zu übermäßigen Schreibvorgängen auf die Festplatte und beschleunigter Batterieentladung führt.

Arten von Logging-Stufen: Von Verbose bis Assert

Verbose (TRACE) — die detaillierteste Stufe, die ausschließlich für die Entwicklung bestimmt ist. Auf dieser Stufe werden alle Zwischenberechnungen, Schleifeniterationen und Ergebnisse jedes Algorithmusschritts ausgegeben. Auf Android entspricht diese Stufe Log.v(), auf iOS — OSLog vom Typ debug (vor iOS 14 wurde os_trace verwendet).

Debug — Debugging-Nachrichten, die während der Entwicklung und des Testens nützlich sind. Sie enthalten Informationen über den Zustand wichtiger Objekte, Ergebnisse von SQL-Abfragen und Parameter von API-Aufrufen. Im Gegensatz zu Verbose sind Debug-Nachrichten strukturiert und semantisch bedeutsam. Auf iOS entspricht diese Stufe OSLogType.debug.

Info — Informationsmeldungen über normale Anwendungsereignisse: SDK-Initialisierung, erfolgreiche Authentifizierung, Bildschirmöffnung, Datenabruf vom Server. Info-Nachrichten dürfen keine persönlichen Daten der Benutzer enthalten und sollten für die Produktionsanalyse sicher sein. Auf iOS wird OSLogType.info verwendet, auf Android — Log.i().

Warn — Warnungen vor potenziellen Problemen. Die Anwendung arbeitet weiter, aber die Situation erfordert Aufmerksamkeit: Cache-Größe nahe am Limit, veraltete API-Version, langsame Netzwerkantwort, erneuter Verbindungsversuch. Auf Android — Log.w(), auf iOS — OSLogType.default (für Warnungen).

Error — kritische Fehler, bei denen die Anwendung die angeforderte Operation nicht ausführen kann, aber weiterarbeitet: fehlgeschlagene API-Anfrage, Verbindungsverlust, Datenbank-Schreibfehler, fehlende Berechtigungen. Auf iOS wird für Fehler OSLogType.error verwendet, auf Android — Log.e().

Assert (WTF) — die höchste Stufe, die eine Situation kennzeichnet, die „nicht passieren kann.“ Wird zum Protokollieren von Fehlern verwendet, die grundlegende Systeminvarianten verletzen. Auf Android werden Assert-Nachrichten standardmäßig nicht in Release-Builds angezeigt. Auf iOS wird WTF (What a Terrible Failure) über OSLogType.fault behandelt.

Verwendung von Log Level auf Android

Android Log API — der integrierte Logging-Mechanismus aus dem Paket android.util.Log. Er bietet 6 statische Methoden: Log.v(), Log.d(), Log.i(), Log.w(), Log.e() und Log.wtf(). Jede Methode nimmt einen Tag (Quellkennzeichen-String) und msg (Nachrichtentext) entgegen.

class UserRepository {
    companion object {
        private val TAG = "UserRepo"
    }

    suspend fun loadUser(id: String): User {
        Log.d(TAG, "Benutzer mit ID $id wird geladen")

        return try {
            val response = api.fetchUser(id)
            Log.i(TAG, "Benutzer erfolgreich geladen")
            response.toUser()
        } catch (e: Exception) {
            Log.e(TAG, "Fehler beim Laden des Benutzers: ${e.message}")
            throw e
        }
    }
}

Filterung nach Stufen im Android Logcat erfolgt über ADB: adb logcat *:E zeigt nur Error-Nachrichten an. In Produktions-Builds werden alle Log.v()- und Log.d()-Aufrufe von ProGuard/R8 entfernt, wenn die Minifizierung aktiviert ist. Log.i(), Log.w() und Log.e() bleiben erhalten, daher ist es wichtig, keine sensiblen Daten über diese Methoden auszugeben.

Für benutzerdefinierte Filterung zur Laufzeit bietet Android Log.isLoggable(tag, level) — eine Methode, die prüft, ob die angegebene Stufe für den gegebenen Tag aktiviert ist. Dies ermöglicht die dynamische Aktivierung der detaillierten Protokollierung für ein bestimmtes Modul, ohne die Anwendung neu zu erstellen.

Verwendung von Log Level auf iOS und macOS

OSLog — Apples einheitliches Logging-System, das das veraltete NSLog ersetzt hat. OSLog bietet 5 Stufen: debug, info, default (notice), error und fault. Der Hauptvorteil ist strukturiertes Logging mit Unterstützung für formatierte Strings und dynamischer Filterung über die Konsole.

import OSLog

let logger = Logger(
    subsystem: "com.example.app",
    category: "network"
)

func fetchData(from url: URL) {
    logger.debug("Starting request to \(url.absoluteString)")

    do {
        let data = try Data(contentsOf: url)
        logger.info("Received \(data.count) bytes")
    } catch {
        logger.error("Request failed: \(error.localizedDescription)")
    }
}

Das Filtersystem von OSLog arbeitet auf Betriebssystemebene. Debug-Nachrichten werden nur geschrieben, wenn der Debugger angeschlossen ist oder das Argument -com.apple.CoreData.Logging.debug 1 aktiviert ist. Info-Nachrichten werden im Gerätespeicher (bis zu 512 KB) gesammelt und sind über die Console.app zugänglich. Error- und fault-Nachrichten werden kontinuierlich geschrieben und sind zur Sammlung über Crash-Reporting-Systeme verfügbar.

Eine wichtige Funktion von OSLog: formatierte Strings mit Platzhaltern. Anstelle der Swift-String-Interpolation (die immer ausgewertet wird, unabhängig von der Stufe) verwendet OSLog das os_log-Format mit %{public}@ und %{private}@ zur Unterscheidung sensibler Daten. Private Parameter werden in Produktionslogs maskiert.

Production vs Debug: So konfigurieren Sie die Stufenfilterung

Die Hauptregel — ein minimaler Satz von Stufen in der Produktion: Info, Warn, Error, Assert. Debug und Verbose müssen deaktiviert sein. Der Grund liegt weniger in der Sicherheit als in der Leistung: Jeder Log-Aufruf verbraucht CPU-Zeit zum Formatieren des Strings, selbst wenn die Nachricht nicht ausgegeben wird.

Faule String-Formatierung

Kritische Optimierung — Verwenden Sie niemals String-Interpolation in Log-Aufrufen. Wenn der String vor dem log()-Aufruf erstellt wird, wird CPU-Zeit verschwendet, selbst wenn die Stufe deaktiviert ist. Verwenden Sie faule Formatierung über Lambdas oder Guard-Bedingungen.

Unter Android dient die Methode Log.isLoggable() diesem Zweck; unter OSLog werden native formatierte Strings mit Platzhaltern unterstützt. Timber für Android löst das Problem über timber.log.Tree mit Stufenprüfung innerhalb des Baums.

Dynamischer Stufenwechsel im laufenden Betrieb

Remote Log Level — eine Praxis, bei der die Protokollierungsstufe vom Server über Firebase Remote Config oder einen ähnlichen Dienst gesteuert wird. Wenn in der Produktion ein komplexer Fehler auftritt, kann der Entwickler aus der Ferne das Debug-Logging für ein bestimmtes Modul auf Geräten einer ausgewählten Benutzergruppe aktivieren.

Laut Firebase, 2024 reduziert diese Praxis die Zeit für die Diagnose seltener Fehler um 60% und ermöglicht ein vollständiges Bild des Problems ohne Installation eines Debug-Builds. Die Hauptbeschränkung — das Logging wird erst beim nächsten Start der Anwendung nach Erhalt der Konfiguration aktiviert.

Automatische Filterung nach Build-Typ

BuildConfig.DEBUG unter Android und #if DEBUG unter Swift sind standardmäßige bedingte Kompilierungsmechanismen, die Debug-Stufen in Release-Builds deaktivieren. Für eine saubere Architektur wird empfohlen, die Log Level-Auswahl in einen DI-Container oder eine Logger-Factory zu verschieben, um die Geschäftslogik nicht mit bedingten Direktiven zu überladen.

Best Practices bei der Wahl des Logging-Levels

Erste Regel — jeder Log-Aufruf sollte die Frage „wer, was, wann“ beantworten. Wer — die Komponente oder das Modul (Tag unter Android, Category unter iOS). Was — das spezifische Ereignis oder die Zustandsänderung. Wann — der Zeitstempel, der automatisch vom Logging-System hinzugefügt wird.

Zweite Regel — protokollieren Sie keine sensiblen Daten über Info und höher. Passwörter, Tokens, E-Mails, Telefonnummern, genaue geografische Koordinaten sind in jedem Log, das in die Produktion gelangt, strikt verboten. Verwenden Sie bei Bedarf Maskierung: „email: us***@example.com.“

Dritte Regel — Warn-Stufe ist die Verantwortung des Entwicklers, Error — des Teams. Warn bedeutet „hier gibt es ein potenzielles Problem, behalten Sie es im Auge.“ Error bedeutet „hier gibt es ein Problem, beheben Sie es.“ Verwenden Sie Error nicht für Situationen, die erwartet und behandelt werden (z. B. ein 404-API-Fehler).

Vierte Regel — Konsistenz. Das gesamte Projekt sollte einheitliche Namenskonventionen für Tags und Kategorien verwenden. Empfohlen wird ClassName.methodName für Android-Tags und module.subsystem für iOS-Kategorien. Dies ermöglicht ein schnelles Filtern von Logs nach Komponente.

Fünfte Regel — testen Sie Ihre Logs. Überprüfen Sie in Unit-Tests, ob in bestimmten Szenarien die richtige Log-Stufe aufgerufen wird. Zu diesem Zweck gibt es Mock-Logging-Bibliotheken: Mockito für Android, Cuckoo für iOS. Die Überprüfung der Stufen in Tests verhindert das Durchsickern von Debug-Nachrichten in die Produktion.