Journalisation dans les applications Kotlin : meilleures pratiques et outils

Journalisation dans les applications Kotlin : bonnes pratiques

La journalisation n'est pas seulement un enregistrement d'événements, mais un outil clé pour le débogage, la surveillance et l'analyse du fonctionnement d'une application. Dans l'écosystème Kotlin, grâce à une compatibilité totale avec Java, toutes les bibliothèques populaires comme SLF4J et Logback sont disponibles. Cependant, Kotlin propose ses propres approches idiomatiques qui rendent le code plus propre et plus sûr. Dans cet article, nous allons passer en revue les bonnes pratiques de journalisation en Kotlin : du choix de la bibliothèque à la configuration des logs structurés pour la production.

1. Choix d'une bibliothèque de journalisation en Kotlin

La stack la plus populaire pour les applications Kotlin est SLF4J (façade) + Logback (implémentation). Cependant, pour Kotlin, il est recommandé d'utiliser l'enveloppe kotlin-logging, qui ajoute des fonctions inline et évite les frais généraux inutiles.

// build.gradle.ktsdependencies {    implementation("io.github.microutils:kotlin-logging:3.0.5")    implementation("ch.qos.logback:logback-classic:1.4.14")}

Avantages de kotlin-logging :

• Initialisation paresseuse du logger — le logger n'est créé qu'à la première utilisation.
• Fonctions inline — la vérification du niveau de journalisation se fait à la compilation, ce qui réduit la surcharge.
• Support des fonctions suspend — fonctionnement correct dans les coroutines.

Exemple de déclaration d'un logger :

import mu.KotlinLogging

private val logger = KotlinLogging.logger {}

2. Niveaux de journalisation appropriés

L'utilisation du niveau correct est la base de logs lisibles. En Kotlin, comme en Java, 5 niveaux sont disponibles : TRACE, DEBUG, INFO, WARN, ERROR.

Recommandations :

• TRACE — uniquement pour un débogage détaillé (par exemple, entrée/sortie d'une méthode).
• DEBUG — informations pour le développeur (valeurs des variables, état des objets).
• INFO — événements métier (requête traitée, utilisateur authentifié).
• WARN — situations anormales qui ne cassent pas l'application (nouvelle tentative de connexion).
• ERROR — exceptions et échecs nécessitant une attention.

Exemple avec différents niveaux :

logger.debug { "Traitement de la requête : $requestId" }logger.info { "Utilisateur ${user.name} inscrit avec succès" }logger.warn { "Le pool de connexions est rempli à 90%, taille actuelle : $poolSize" }logger.error(ex) { "Erreur lors de la sauvegarde de la commande ${orderId}" }

Important : En Kotlin, pour transmettre une exception, utilisez logger.error(throwable) { "message" }, et non logger.error("message", throwable) — c'est plus idiomatique.

3. Journalisation structurée (JSON)

Dans les architectures de microservices modernes, les logs textuels sont peu pratiques pour l'analyse. Il est préférable d'utiliser des logs structurés au format JSON. Cela permet de filtrer facilement les logs dans ELK, Grafana ou Splunk.

Configuration de Logback pour les logs JSON :

// logback.xml<configuration>    <appender name="JSON" class="ch.qos.logback.core.ConsoleAppender">        <encoder class="net.logstash.logback.encoder.LogstashEncoder"/>    </appender>

    <root level="INFO">        <appender-ref ref="JSON"/>    </root></configuration>

Pour ajouter des champs personnalisés, utilisez MDC (Mapped Diagnostic Context) :

import org.slf4j.MDC

fun processOrder(orderId: String) {    MDC.put("orderId", orderId)    MDC.put("userId", currentUserId())    logger.info { "Début du traitement de la commande" }    // ... logique    MDC.clear()}