Surveillance des applications Kotlin : métriques et alertes de A à Z

Introduction : Pourquoi la surveillance est vitale pour les applications Kotlin

Les applications Kotlin modernes, fonctionnant sur la JVM (Java Virtual Machine), deviennent souvent des nœuds critiques de l'infrastructure. Sans une surveillance adéquate, vous risquez de faire face à des pannes soudaines, des fuites mémoire ou une dégradation des performances qui resteront inaperçues jusqu'à l'incident. Dans cet article, nous allons voir comment construire un système de surveillance complet pour les applications Kotlin « de A à Z » : de la collecte de métriques de base (CPU, mémoire, GC) à la configuration d'alertes dans Grafana et Prometheus.

Nous aborderons trois outils clés : Micrometer (façade pour les métriques), Prometheus (stockage et collecteur) et Grafana (visualisation et alertes). Tous les exemples de code sont écrits en Kotlin.

1. Bases de la collecte de métriques : Micrometer et Prometheus

Micrometer est la façade standard de facto pour la surveillance dans l'écosystème Spring et Kotlin. Il fournit une API unifiée pour envoyer des métriques vers différents systèmes (Prometheus, Datadog, New Relic, etc.).

1.1. Ajout des dépendances (Gradle)

dependencies {\n    implementation("io.micrometer:micrometer-registry-prometheus:1.12.0")\n    implementation("org.springframework.boot:spring-boot-starter-actuator")\n}

Pour Ktor ou du Kotlin pur sans Spring, vous pouvez ajouter uniquement micrometer-core et micrometer-registry-prometheus.

1.2. Configuration de base de Micrometer dans Spring Boot

Dans application.yml, il suffit d'activer Actuator et le point de terminaison Prometheus :

management:\n  endpoints:\n    web:\n      exposure:\n        include: health,info,prometheus\n  metrics:\n    export:\n      prometheus:\n        enabled: true

Après le démarrage de l'application, les métriques seront disponibles à l'adresse /actuator/prometheus.

1.3. Création de métriques personnalisées (exemple en Kotlin)

Supposons que vous souhaitiez compter le nombre de commandes traitées et leur temps de traitement :

import io.micrometer.core.instrument.MeterRegistry\nimport io.micrometer.core.instrument.Timer\nimport org.springframework.stereotype.Service\nimport java.util.concurrent.atomic.AtomicLong\n\n@Service\nclass OrderService(private val registry: MeterRegistry) {\n\n    private val processedOrders: AtomicLong = registry.gauge(\n        "orders.processed.count",\n        AtomicLong(0)\n    )\n    private val orderProcessingTime: Timer = registry.timer("orders.processing.time")\n\n    fun processOrder(orderId: String) {\n        val sample = Timer.start()\n        try {\n            // Logique de traitement de la commande\n            Thread.sleep((50..200).random().toLong())\n            processedOrders.incrementAndGet()\n        } finally {\n            sample.stop(orderProcessingTime)\n        }\n    }\n}

Désormais, les métriques orders_processed_count et orders_processing_time_seconds apparaîtront dans Prometheus.

2. Configuration de Prometheus pour la collecte de métriques

Prometheus est un serveur qui « scrape » (interroge) les métriques de vos applications selon un planning.

2.1. Configuration de prometheus.yml

Ajoutez votre service Kotlin en tant que cible (target) :

scrape_configs:\n  - job_name: 'kotlin-app'\n    metrics_path: '/actuator/prometheus'\n    static_configs:\n      - targets: ['localhost:8080']

Si l'application fonctionne dans Docker/Kubernetes, utilisez la découverte de services.

2.2. Métriques JVM importantes par défaut

Micrometer exporte automatiquement de nombreuses métriques JVM :

\n
• jvm_memory_used_bytes — mémoire utilisée (heap/non-heap)
\n
• jvm_gc_pause_seconds — durée des pauses GC
\n
• jvm_threads_live_threads — nombre de threads actifs
\n
• process_cpu_usage — utilisation CPU par le processus
\n

Ces données sont déjà disponibles dans Prome