Log Level i applikationsutveckling: vad det är, typer av nivåer och konfiguration

Vad är Log Level?

Log Level — ett attribut för varje loggmeddelande som bestämmer dess betydelse och brådska. Moderna iOS- och Android-plattformar stöder en enhetlig skala med 6–7 nivåer: från maximalt detaljerad (Verbose/Trace) till kritisk (Error/Assert). Valet av nivå avgör om meddelandet kommer att skrivas till loggen vid applikationens aktuella konfiguration.

Konceptet Log Level bygger på principen om kritikalitetspyramiden: ju högre nivå, desto färre meddelanden visas på den. Enligt data från Semaphore CI, 2024 ser fördelningen i en produktionsapplikation ut så här: Info — 60% meddelanden, Warn — 25%, Error — 10%, Debug — 5%. Verbose-meddelanden måste vara helt inaktiverade i produktion.

Varje plattform implementerar Log Level genom sitt eget API. Android använder android.util.Log med metoderna v(), d(), i(), w(), e(). Apple — OSLog med nivåerna default, info, debug, error, fault. Bibliotek som Timber och CocoaLumberjack bygger ytterligare funktionalitet ovanpå dessa standard-API:er.

Enligt data från Google I/O 2023 är felaktigt val av Log Level orsaken till 40% av prestandaproblemen i produktion. Utvecklare lämnar Debug-loggar i release-bygget, vilket leder till överdriven skrivning på disk och accelererad batteriurladdning.

Typer av loggningsnivåer: från Verbose till Assert

Verbose (TRACE) — den mest detaljerade nivån, avsedd enbart för utveckling. På denna nivå visas alla mellanliggande beräkningar, loopiterationer, resultat av varje steg i algoritmen. På Android motsvaras denna nivå av Log.v(), på iOS — OSLog med typen debug (före iOS 14 användes os_trace).

Debug — felsökningsmeddelanden, användbara under utveckling och testning. Innehåller information om tillståndet för viktiga objekt, resultat av SQL-frågor, parametrar för API-anrop. Till skillnad från Verbose är Debug-meddelanden strukturerade och semantiskt meningsfulla. På iOS motsvaras denna nivå av OSLogType.debug.

Info — informativa meddelanden om normala händelser i applikationen: SDK-initiering, lyckad autentisering, skärmöppning, mottagning av data från servern. Info-meddelanden får inte innehålla personlig användardata och måste vara säkra för produktionsanalys. På iOS används OSLogType.info, på Android — Log.i().

Warn — varningar om potentiella problem. Applikationen fortsätter att fungera, men situationen kräver uppmärksamhet: cache-storlek nära gränsen, föråldrad API-version, långsamt nätverkssvar, förnyat anslutningsförsök. På Android — Log.w(), på iOS — OSLogType.default (för varningar).

Error — kritiska fel där applikationen inte kan utföra den begärda operationen men fortsätter att fungera: misslyckad API-förfrågan, förlorad anslutning, skrivfel i databasen, brist på behörigheter. På iOS används OSLogType.error för fel, på Android — Log.e().

Assert (WTF) — den högsta nivån, som indikerar en situation ”detta kan inte hända”. Används för att logga buggar som bryter mot systemets grundläggande invarianter. På Android visas Assert-meddelanden inte som standard i release-byggen. På iOS bearbetas WTF (What a Terrible Failure) genom OSLogType.fault.

Använda Log Level på Android

Android Log API — den inbyggda loggningsmekanismen från paketet android.util.Log. Tillhandahåller 6 statiska metoder: Log.v(), Log.d(), Log.i(), Log.w(), Log.e() och Log.wtf(). Varje metod tar emot en tag (identifieringssträng för källan) och msg (meddelandetext).

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

    suspend fun loadUser(id: String): User {
        Log.d(TAG, "Laddar användare med id: $id")

        return try {
            val response = api.fetchUser(id)
            Log.i(TAG, "Användaren laddades framgångsrikt")
            response.toUser()
        } catch (e: Exception) {
            Log.e(TAG, "Det gick inte att ladda användaren: ${e.message}")
            throw e
        }
    }
}

Filtrering efter nivå i Android Logcat sker via ADB: adb logcat *:E kommer endast att visa Error-meddelanden. I produktionsbyggen tas alla Log.v() och Log.d() anrop bort av ProGuard/R8 när minifiering är aktiverad. Log.i(), Log.w() och Log.e() finns kvar, så det är viktigt att inte mata ut känslig data genom dessa metoder.

För anpassad filtrering vid körning tillhandahåller Android Log.isLoggable(tag, level) — en metod som kontrollerar om den angivna nivån är aktiverad för en given tag. Detta gör det möjligt att dynamiskt aktivera detaljerad loggning för en specifik modul utan att bygga om applikationen.

Använda Log Level på iOS och macOS

OSLog — Apples enhetliga loggningssystem, som ersatte den föråldrade NSLog. OSLog erbjuder 5 nivåer: debug, info, default (notice), error och fault. Den främsta fördelen är strukturerad loggning med stöd för formaterade strängar och dynamisk filtrering via konsolen.

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)")
    }
}

Filtreringssystemet för OSLog fungerar på operativsystemsnivå. Debug-meddelanden skrivs endast när debugger är ansluten eller när argumentet -com.apple.CoreData.Logging.debug 1 är aktiverat. Info-meddelanden samlas i enhetens minne (upp till 512 KB) och är tillgängliga via Console.app. Error och fault skrivs kontinuerligt och är tillgängliga för insamling via krashrapporteringssystem.

En viktig egenskap hos OSLog: formaterade strängar med placeholder. Istället för Swift-stränginterpolation (som alltid beräknas, oavsett nivå) använder OSLog os_log-format med %{public}@ och %{private}@ för att separera känslig data. Privata parametrar maskeras i produktionsloggar.

Produktion vs Debug: hur man konfigurerar nivåfiltrering

Grundregeln — minsta uppsättning nivåer i produktion: Info, Warn, Error, Assert. Debug och Verbose måste inaktiveras. Anledningen är inte så mycket säkerhet som prestanda: varje logganrop förbrukar processortid för att formatera strängen, även om meddelandet inte visas.

Lat strängformatering

Kritisk optimering — använd aldrig stränginterpolation i logganrop. Om strängen bildas före log()-anropet slösas processortid bort även när nivån är inaktiverad. Använd lat formatering via lambdas eller skyddsvillkor.

På Android tjänar metoden Log.isLoggable() detta syfte, i OSLog — inbyggt stöd för formaterade strängar med placeholder. Timber för Android löser problemet genom timber.log.Tree med nivåkontroll inuti trädet.

Dynamisk nivåändring i farten

Remote Log Level — en praxis där loggningsnivån styrs från servern via Firebase Remote Config eller liknande tjänst. Om ett komplext fel uppstår i produktion kan utvecklaren på distans aktivera Debug-loggning för en specifik modul på enheter i en vald användargrupp.

Enligt data från Firebase, 2024 minskar denna praxis tiden för diagnos av sällsynta buggar med 60% och gör det möjligt att få en fullständig bild av problemet utan att installera ett debug-bygge. Den huvudsakliga begränsningen är att loggar endast aktiveras vid nästa start av applikationen efter att ha mottagit konfigurationen.

Automatisk filtrering efter byggtyp

BuildConfig.DEBUG på Android och #if DEBUG i Swift — standardmekanismer för villkorlig kompilering som inaktiverar felsökningsnivåer i release-byggen. För en ren arkitektur rekommenderas att flytta valet av Log Level till en DI-container eller loggerfabrik, för att inte belasta affärslogiken med villkorliga direktiv.

Bästa praxis vid val av loggningsnivå

Första regeln — varje logganrop bör svara på frågan ”vem, vad, när”. Vem — komponent eller modul (tag på Android, category på iOS). Vad — specifik händelse eller tillståndsändring. När — tidsstämpel, automatiskt inställd av loggningssystemet.

Andra regeln — logga inte känslig data via Info och högre nivåer. Lösenord, tokens, e-postmeddelanden, telefonnummer, exakta geokoordinater — är strängt förbjudna i alla loggar som hamnar i produktion. Använd vid behov maskering: ”email: us***@example.com”.

Tredje regeln — nivån Warn är utvecklarens ansvarsområde, Error — teamets. Warn betyder ”här finns ett potentiellt problem, övervaka”. Error — ”här finns ett problem, åtgärda”. Använd inte Error för situationer som är förväntade och hanterade (till exempel API-fel 404).

Fjärde regeln — konsekvens. Hela projektet bör använda enhetliga namngivningskonventioner för taggar och kategorier. Rekommenderas ClassName.methodName för Android-taggar och module.subsystem för iOS-kategorier. Detta möjliggör snabb filtrering av loggar efter komponent.

Femte regeln — testa loggar. I enhetstester, kontrollera att rätt Log Level anropas i specifika scenarier. För detta ändamål finns mock-loggningsbibliotek: Mockito för Android, Cuckoo för iOS. Kontroll av nivåer i tester förhindrar läckage av felsökningsmeddelanden till produktion.