Introduction : pourquoi la surveillance des applications Java est essentielle
\nUne application Java moderne est un système distribué complexe. Sans surveillance, vous travaillez à l'aveugle : une baisse de vitesse de réponse, une fuite mémoire ou un OutOfMemoryError soudain peuvent passer inaperçus jusqu'à ce qu'un utilisateur se plaigne. Une surveillance correctement configurée des métriques et des alertes permet non seulement de réagir rapidement aux incidents, mais aussi de prédire les goulots d'étranglement avant qu'ils ne deviennent critiques.
\nDans cet article, nous aborderons le cycle complet : de la collecte des métriques JVM de base à la configuration des alertes dans Prometheus et à la visualisation dans Grafana. Tous les exemples de code sont écrits en Java en utilisant la bibliothèque populaire Micrometer.
\n\n1. Métriques clés d'une application Java
\nLa surveillance commence par le choix des bonnes métriques. Elles peuvent être divisées en trois groupes : les métriques JVM, les métriques métier et les métriques d'infrastructure.
\n\n1.1. Métriques JVM
\nCes métriques montrent l'état de la machine virtuelle Java. Les plus importantes sont :
\n- \n
- Heap memory usage — utilisation du tas (mémoire utilisée / maximale). Une augmentation soudaine peut indiquer une fuite. \n
- GC pauses — fréquence et durée des collectes de déchets. Des pauses longues (plus d'une seconde) sont un signe de problèmes. \n
- Thread states — nombre de threads dans les états RUNNABLE, BLOCKED, WAITING. Beaucoup de BLOCKED — un blocage est possible. \n
- CPU usage — charge du processeur par le processus JVM. \n
1.2. Métriques métier
\nElles reflètent la logique de votre application. Exemples :
\n- \n
- Nombre de commandes traitées par minute. \n
- Temps de réponse d'une API externe. \n
- Nombre d'erreurs de validation. \n
1.3. Métriques d'infrastructure
\n- \n
- Utilisation du disque, du réseau, de la mémoire de l'hôte. \n
- État des connexions à la base de données (pool de connexions). \n
- Latences des files d'attente de messages (Kafka, RabbitMQ). \n
2. Outils de collecte de métriques : Micrometer + Prometheus
\nPour les applications Java, la bibliothèque de facto standard est Micrometer. Elle fournit une façade pour différents systèmes de surveillance (Prometheus, Datadog, Graphite). En combinaison avec Prometheus (stockage de métriques) et Grafana (visualisation), vous obtenez un écosystème puissant et gratuit.
\n\n2.1. Intégration de Micrometer dans Spring Boot
\nSi vous utilisez Spring Boot 2.x ou 3.x, ajoutez la dépendance dans pom.xml :
<dependency>\n <groupId>io.micrometer</groupId>\n <artifactId>micrometer-registry-prometheus</artifactId>\n</dependency>\nEnsuite, Spring Boot Actuator activera automatiquement le point de terminaison /actuator/prometheus, qui fournira les métriques au format Prometheus.
2.2. Création d'une métrique personnalisée
\nSupposons que vous souhaitiez compter le nombre d'appels réussis et échoués d'une méthode. Créez un compteur :
\nimport io.micrometer.core.instrument.MeterRegistry;\nimport io.micrometer.core.instrument.Counter;\nimport org.springframework.stereotype.Service;\n\n@Service\npublic class OrderService {\n\n private final Counter successCounter;\n private final Counter errorCounter;\n\n public OrderService(MeterRegistry registry) {\n this.successCounter = Counter.builder("orders.success")\n .description("Number of successful orders")\n .register(registry);\n this.errorCounter = Counter.builder("orders.error")\n .description("Number of failed orders")\n .register(registry);\n }\n\n public void processOrder(String orderId) {\n try {\n // logique de traitement de la commande\n successCounter.increment();\n } catch (Exception e) {\n errorCounter.increment();\n throw e;\n }\n }\n}\nDans Prometheus, la métrique apparaîtra sous la forme orders_succ