Maximize Page
Tech & DevOps HubEspace Tech & DevOps: Explorez le monde du Dev, du Cloud et des outils DevOps à travers nos articles et discussions Explore the world of development, the cloud and DevOps tools

Ajout d'Actuator en 3 étapes

Date de l'article:08-12-2025
CI/CD Spring Boot
Intégration de Spring Boot Actuator avec Spring Security dans les trois branches et exposition contrôlée des endpoints selon l'environnement. J'aborde aussi le contournement de l'alerte CodeQL en CI et l'utilisation d'Actuator pour le diagnostic et le monitoring
INFO PROJET
App Spring Boot : Flashcards - readme CI
Docker Image Hub
Qualité/couverture: sonarCloud projectSonarQube Cloud
En Bref;

Nous allons définir la configuration des accès selon les profils, la gestion de la sécurité en CI en évitant notamment les alertes CodeQL via la configuration de SecurityConfig, nous ferons les vérifications et résultats attendus, ainsi que, en bonus, l'ajout des informations Git dans l'endpoint actuator/info et l'utilisation d'Actuator pour diagnostiquer l'application.

Spring Boot Actuator

Spring Boot Actuator est un sous-projet essentiel qui fournit des fonctionnalités «production-ready» pour surveiller et piloter l'application
Au lieu de développer des interfaces de monitoring sur mesure, Actuator expose automatiquement des endpoints HTTP ou JMX permettant
     d'observer l'état interne de l'application en temps réel

Aperçu des principaux indicateurs
health
Vérifie l'état de l'application et de ses dépendances (base de données, cache, etc.)
info
Fournit des métadonnées : profil actif, version, commit, environnement
metrics
Suit l'utilisation de la CPU, de la mémoire, requêtes HTTP, threads, etc.
mappings
Liste toutes les routes exposées et leurs contrôleurs associés
env
Affiche les propriétés chargées par Spring:
profil, version de l'app, le commit de la release
Logs
Permet d'inspecter et modifier dynamiquement les niveaux de logs
Ajout d'Actuator all branches

Nous allons ajouter les configurations nécessaires pour exploiter les endpoints Actuator

Approche recommandée

Actuator doit être présent dans tous les environnements. En revanche, les endpoints exposés doivent varier selon le profil.

➜ Dépendances communes → présentes dans toutes les branches
➜ Sécurité et exposition → pilotées par les profils (application-*.properties)

Principe d'accès aux endpoints par environnement

Liste des endpoints disponibles : curl -s http://localhost:{port}/actuator

profil dev staging prod
actuator/health Public Public Public
actuator/info Public Public Public
actuator/metrics Accès restreint Accès restreint
actuator/env Accès restreint Accès restreint
actuator/mappings Accès restreint

/actuator/info est utile surtout en dev. En staging/prod: on évites d'exposer des métadonnées

Mise en place
1. Ajoutez la dépendance "Starter" au projet 
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Sans cette dépendance, les endpoints /actuator/ n'existent pas
1.a Ajouter Spring Security (recommandé) 
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>
Permet de sécuriser les endpoints sensibles et d'éviter l'alerte CodeQL
2. Configuration des fichiers src/main/resources/
Le fichier commun: application.properties 
# actuator info
spring.application.name=flashcards

info.app.name=Flashcards
info.app.version=1.0.0
info.app.description=Flashcards API
info.env.spring.profiles.active=${spring.profiles.active}

# endpoint enable
management.info.env.enabled=true
management.info.build.enabled=true
management.endpoint.health.show-details=when-authorized

# admin by default
spring.security.user.name=admin
spring.security.user.roles=ADMIN
Points clés

Ajouter les configurations communes dans ce fichier

Attention à la confusion:

spring.application.name est l'identifiant technique
info.app.name est le nom lisible exposé via Actuator

Prometheus utilise spring.application.name
     Changer cette valeur impacte donc tout l'écosystème de monitoring
when-authorized limite l'exposition des détails sensibles, ce qui répond aux recommandations de sécurité CodeQL

L'utilisateur admin pourra se connecter au endpoints restreints grâce
     à la class SecurityConfig définie plus bas

Le profil dev: application-dev.properties

# actuator endpoints
management.endpoints.web.exposure.include=health,info,metrics,mappings,env

Le profil staging: application-staging.properties

info.app.environment=staging

# endpoint enable
management.endpoints.web.exposure.include=health,info,metrics,env
management.info.java.enabled=false

Le profil prod: application-prod.properties

management.endpoints.web.exposure.include=health,info

# endpoint enable
management.endpoint.health.probes.enabled=true
management.endpoint.health.show-details=never
management.endpoint.env.enabled=false
management.info.env.enabled=false
management.info.build.enabled=true

Les fichiers profils écrasent la configuration commune

Dans tous les fichiers de profil: Incluez explicitement, les endpoints désirés avec management.endpoints.web.exposure.include

Attention au Warning CodeQL ( CI/PR)
Exposed Spring Boot actuators in configuration file
 Open in main 17 hours ago
Speed up the remediation of this alert with Copilot Autofix for CodeQL
Code snippet
pom.xml:75 
</dependency>

<!-- Actuator -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Insecure Spring Boot actuator configuration exposes sensitive endpoints.
Analyses de sécurité CodeQL: projet → security/code-scanning
La cause
Rule	
Tool        CodeQL	
Rule ID     java/spring-boot-exposed-actuators-config
Query	View  source
Description
Spring Boot includes features called actuators that let you monitor and interact with your web application. 
Exposing unprotected actuator endpoints through configuration files can lead to information disclosure or even to remote code execution.
Résolution (recommandé)

Pour résoudre l'alerte CodeQL "java/spring-boot-exposed-actuators-config",
il faut ajouter la dépendance "Spring Security" pour sécuriser automatiquement les endpoints Actuator. Et, configurer les expositions de manière restrictive dans les fichiers de propriétés

Dans un contexte CI/CD, ce message est critique car il bloque le déploiement pour éviter une faille majeure en production
3. Sécurisation avancée: La classe SecurityConfig (extrait)

Objectif: Autoriser /health publiquement et restreindre les autres endpoints au rôle ADMIN

Ajout du fichier dans "/src/main/java/../flashcards/config/" 
@Configuration
@EnableWebSecurity
public class ActuatorSecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.securityMatcher(EndpointRequest.toAnyEndpoint())
            .authorizeHttpRequests(authz -> authz
                .requestMatchers(EndpointRequest.to("health")).permitAll()
                .anyRequest().hasRole("ADMIN")
            )
            .httpBasic(Customizer.withDefaults());
        return http.build();
    }
}

Retrouvez le code complet de ce script, dans le repository Flashcards

Dans la CI: La variable SPRING_SECURITY_PSWD est définie dans les secrets Github

En local: Vous pouvez la redéfinir avec: 
SPRING_SECURITY_PSWD=your-secret 
./mvnw spring-boot:run
Voir le readme pour + d'informations
Vérifications et résultats finaux
Dans la CI/PR

Les checks dans la PR sont au vert
Pas d'alerte dans le projet Github: → security/code-scanning

1. Vérification des endpoints (cUrls/navigateur)
endpoints develop :8080 staging :8081 main :8080

PUBLIC


health		 
http://localhost:8080/actuator/health
http://localhost:8081/actuator/health
Résultat:
{ "status": "UP" } 
http://localhost:8080/actuator/health
Résultat:
{ status: "UP", groups: [ "liveness", "readiness" ] }

PUBLIC


info
dev/prod: 
http://localhost:8080/actuator/info
staging: 
http://localhost:8081/actuator/info
Prod:
{ app: { environment: "prod", name: "Flashcards", version: "1.0.0", description: "Flashcards API" }, env: { spring: { profiles: { active: "prod" } } } }
Tous, partagent ces informations:
name: "Flashcards", version: "1.0.0", description: "Flashcards API"
Les informations changent suivant l'environement et le profil
app: { environment: "staging", //... env: { spring: { profiles: { active: "staging" }
2. Endpoints avec access restreint (dev/staging)

RESTRICTED ACESS Nécessite d'utiliser l'utilisateur «admin»

metrics 
curl -u admin:your-password http://localhost:8080/actuator/metrics

Plus facile à lire dans le navigateur, il renvoie la liste des métriques disponibles
env 
curl -u admin:your-password http://localhost:8080/actuator/env

Affiche toutes les sources de configuration et leurs valeurs effectives

mappings (dev only) 
curl -u admin:your-password http://localhost:8080/actuator/mappings

Donne le contexte, le mapping de tous les endpoints disponibles par environement
En dev, j'ai ajouté les indicateurs loggers pour avoir la possibilité de changer le niveau des logs facilement. INFO est défini par défaut
Bonus: Ajouter les infos Git dans actuator/info
Étapes:
  1. Ajouter le plugin dans le projet: git-commit-id-maven-plugin
  2. Ajoutez dans application.properties : 
    management.info.git.enabled=true
Exposer les métadonnées Git via /actuator/info est stratégique
Le commit SHA est une preuve technique incontestable pour savoir:
→ quel commit est en production,
→ sur quelle branche il a été buildé
→ quand il a été généré
Résultat
http://localhost:8080/actuator/info 
{
  git: {
    branch: "feature/add-actuator",
    commit: {
      id: "e7fa488",
      time: "2026-02-12T19:03:28Z"
    }
  }
}
Exemple d'utilisation des informations Git
Diagnostic rapide en incident (Incident Management)
Scénario réel :
Un bug apparaît > on récupères le commit via /actuator/info
On ouvres le commit dans GitHub, on compares avec le précédent;
Grâce à ca, on identifies immédiatement la PR responsable
Sans ça :
  • Il faut fouiller les logs
  • Vérifier les tags Docker
  • Chercher dans la CI
Avec Git Actuator: c'est vu en 10 secondes
Alignement avec Docker & Kubernetes
Dans un environnement Kubernetes :
L'image Docker est taguée (ex: flashcards:1.0.3), mais le tag peut être ambigu.

La solution est l'utilisation du SHA Git qui est unique et immuable

Beaucoup d'entreprises affichent la version de Maven, le build timestamp, le git commit et la git branch , ca permet de vérifier que les pods ont le même commit:
Pod A → e7fa488
Pod B → e7fa488
Audit & conformité (gouvernance IT)
Dans les grandes entreprises, on doit pouvoir prouver:
  • Quelle version exacte tournait à une date donnée
  • Quel code a été exécuté
  • Qui l'a validé (via la PR liée au commit)
Monitoring avancé
Avec Prometheus/Grafana, injecter: git.branch et git.commit dans les métriques permet de :
  • Corréler les erreurs avec une release
  • Visualiser les incidents par version
Bonus: Diagnostiquer avec Actuator

Actuator permet d'inspecter une application en production, sans redémarrage

Métriques utiles et leus détections
JVM mémoire
/metrics/jvm.memory.used
/metrics/jvm.memory.max
Détecte les fuites mémoire
DB pool (Hikari)
/metrics/hikaricp.connections.active
/metrics/hikaricp.connections.idle
Connexions saturées ou bloquées
HTTP
/metrics/http.server.requests

Latence, volume de trafic, status codes
Requêtes lentes
/metrics/http.server.requests?tag=uri:/api/flashcards
Filtre par endpoint avec ?tag=uri:
Threads
metrics/jvm.threads.live
Détecte les thread leaks et les blocages (via Micrometer)
Scénarios classiques de debug
Logs insuffisants
Une erreur survient, mais les logs sont au niveau "INFO"
Passez dynamiquement le package au niveau "DEBUG": 
curl -X POST -H "Content-Type: application/json" \
-d '{"configuredLevel": "DEBUG"}' \
http://your-app/actuator/loggers/com.yourprojet.service
Erreur de configuration
Vérifiez les valeurs réellement chargées par Spring, incluant les variables d'environnement et les secrets 
/actuator/env
/actuator/configprops
/actuator/conditions
Fuite mémoire
GET /actuator/heapdump
Analyser le fichier .hprof en examinant l'état du tas (heap) Java
Utilisez MAT (VisualVM), idéal pour une analyse rapide et visuelle
Application bloquée / CPU élevé
GET /actuator/threaddump
Identifier les threads en état BLOCKED ou WAITING
Lien avec le CI/CD et le Monitoring

Actuator est utilisé par les outils de CI/CD et les systèmes de supervision (Prometheus, Grafana, K8s) pour vérifier si une application est prête à être déployée,
     si elle est en bonne santé (healthcheck), ou pour afficher des tableaux de bord de performance.
     En résumé; Actuator est dans l'application, mais il est conçu pour le monitoring et les pipelines CI/CD (DevOps)

Dans l'article suivant, nous verrons comment tirer profit d'Actuator dans une étape Github Actions (smoke test) et nous finaliserons le pipeline de production
Les rulesets ou Règles de protection des branches Mise en place d'un pipeline CI/CD (4/4) - La branche main (final)
Laissez-moi un commentaire

En postant un commentaire anonyme, vous adhérez automatiquement aux conditions d'utilisation du site.