Ajoutez Spring Boot Actuator au Microservice-produits.
Ajoutez cette dépendance au pom.xml :
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Actualisez Maven.
Rendez-vous dans bootstrap.properties et ajoutez ceci :
management.endpoints.web.exposure.include=*
Actuator fonctionne en exposant des endpoints, c'est-à-dire des URL qui vous fournissent des données sur des aspects de votre microservice, une API, en somme.
Regardons la liste de ces endpoints.
Lancez Microservice-produit, puis rendez-vous à http://localhost:9001/actuator.
Vous avez cette liste d'endpoints ouverts qui s'affiche :
{
"_links":
{
"self":
{
"href": "http://localhost:9001/actuator",
"templated": false
},
"archaius":
{
"href": "http://localhost:9001/actuator/archaius",
"templated": false
},
"auditevents":
{
"href": "http://localhost:9001/actuator/auditevents",
"templated": false
},
"beans":
{
"href": "http://localhost:9001/actuator/beans",
"templated": false
},
"health":
{
"href": "http://localhost:9001/actuator/health",
"templated": false
},
"conditions":
{
"href": "http://localhost:9001/actuator/conditions",
"templated": false
},
"configprops":
{
"href": "http://localhost:9001/actuator/configprops",
"templated": false
},
"env":
{
"href": "http://localhost:9001/actuator/env",
"templated": false
},
"env-toMatch":
{
"href": "http://localhost:9001/actuator/env/{toMatch}",
"templated": true
},
"info":
{
"href": "http://localhost:9001/actuator/info",
"templated": false
},
"loggers-name":
{
"href": "http://localhost:9001/actuator/loggers/{name}",
"templated": true
},
"loggers":
{
"href": "http://localhost:9001/actuator/loggers",
"templated": false
},
"heapdump":
{
"href": "http://localhost:9001/actuator/heapdump",
"templated": false
},
"threaddump":
{
"href": "http://localhost:9001/actuator/threaddump",
"templated": false
},
"metrics-requiredMetricName":
{
"href": "http://localhost:9001/actuator/metrics/{requiredMetricName}",
"templated": true
},
"metrics":
{
"href": "http://localhost:9001/actuator/metrics",
"templated": false
},
"scheduledtasks":
{
"href": "http://localhost:9001/actuator/scheduledtasks",
"templated": false
},
"httptrace":
{
"href": "http://localhost:9001/actuator/httptrace",
"templated": false
},
"mappings":
{
"href": "http://localhost:9001/actuator/mappings",
"templated": false
},
"refresh":
{
"href": "http://localhost:9001/actuator/refresh",
"templated": false
},
"features":
{
"href": "http://localhost:9001/actuator/features",
"templated": false
},
"service-registry":
{
"href": "http://localhost:9001/actuator/service-registry",
"templated": false
}
}
}
Deux endpoints sont publics par défaut : /health et /info.
/health
Cet endpoint affiche un simple message comme celui-ci :
{
"status": "UP"
}
Il permet de tester si le microservice est en fonction ou pas. Il est très utilisé dans la surveillance des instances en cours d'exécution des microservices. En faisant un check régulier de cet endpoint, vous suivez en direct l'état de vos microservices.
Cet endpoint fonctionne en analysant le retour de toutes les classes qui héritent de HealthIndicator. Chacune de ces classes doit effectuer ses tests, et dire si le service est UP ou DOWN.
Vous pouvez créer votre propre indicateur afin de tester si votre microservice fonctionne correctement en fonction de vos propres critères.
Imaginez que, dans Microservice-produits, vous estimiez que le microservice est DOWN s'il n'y a pas de produits dans la base de données à servir. En effet, dans ce cas, ni le microservice ni l'application n'ont plus d'utilité.
Ce point est donc critique et mériterait de renvoyer un indicateur DOWN.
Pour ce faire, rendez-vous dans ProductController.java, héritez de HealthIndicator, puis implémentez la méthode obligatoire :
@RestController
public class ProductController implements HealthIndicator
{
@Autowired
ProductDao productDao;
Logger log = LoggerFactory.getLogger(this.getClass());
@Autowired
ApplicationPropertiesConfiguration appProperties;
@Override
public Health health()
{
List<Product> products = productDao.findAll();
if(products.isEmpty())
{
return Health.down().build();
}
return Health.up().build();
} //suite du code ... }
La méthodehealth()
est à surcharger, elle doit faire les tests nécessaires afin de donner son avis sur l'état du microservice. Dans notre cas, nous récupérons la liste de tous les produits. Si cette liste est vide, on considère que le microservice est DOWN.
On retourne alorsHealth.down().build()
qui construira le message à retourner au format adéquat.
Relancez le microservice et rendez-vous à l'URL http://localhost:9001/actuator/health pour vérifier l'état de celui-ci. Vous avez alors :
{
"status": "UP"
}
Rendez-vous maintenant à la console de la base de données http://localhost:9001/h2-console, puis videz-la.
De retour dans notre endpoint, vous obtenez :
{
"status": "DOWN"
}
Bingo ! Votre test a fonctionné.
/Info
Pour l'utiliser, il suffit d'ajouter dans votre fichier .properties des lignes sous ce format :
info.app.NOM_DE_VOTRE_VALEUR= quelque chose ici
Testez en ajoutant par exemple ceci à bootstrap.properties :
info.app.version=1.0-Beta
Relancez le microservice et rendez-vous à l'endpoint /info. Vous obtenez alors votre valeur :
{
"app":
{
"version": "1.0-Beta"
}
}
Choisissez les autres endpoints à afficher
Les autres endpoints sont protégés et considérés comme sensibles.
Afin de les afficher, nous avons utilisé :
management.endpoints.web.exposure.include=*
Ce n'est pas une bonne idée quand votre microservice est en production. Au lieu de cela, il faut choisir les endpoints à afficher.
Plusieurs méthodes sont possibles, mais la plus simple est d'inclure uniquement ceux qui nous intéressent :
management.endpoints.web.exposure.include=health,info,metrics
Voici quelques autres endpoints.
/metrics
Cet endpoint donne des informations sur les paramètres de l'application : mémoires utilisées, données liées à JVM, données sur Tomcat, URI appelés et leurs statistiques, etc. Si vous vous rendez à http://localhost:9001/actuator/metrics/, vous obtenez la liste de tous les "sous-endpoints" qui vous donnent chacun accès à une série d'informations spécifiques :
{
"names":
[
"jvm.buffer.memory.used",
"jvm.memory.used",
"jvm.gc.memory.allocated",
"jvm.memory.committed",
"tomcat.global.error",
"jdbc.connections.min",
"tomcat.sessions.created",
"tomcat.sessions.expired",
"hikaricp.connections.usage",
"tomcat.global.sent",
"jvm.gc.max.data.size",
"logback.events",
"system.cpu.count",
"jvm.memory.max",
...
...
...
]
}
Si vous accédez par exemple à http.server.requests via http://localhost:9001/actuator/metrics/http.server.requests, vous tombez sur ceci :
{
"names": [
"jvm.buffer.memory.used",
"jvm.memory.used",
"jvm.gc.memory.allocated",
"jvm.memory.committed",
"tomcat.global.error",
"jdbc.connections.min",
"tomcat.sessions.created",
"tomcat.sessions.expired",
"hikaricp.connections.usage",
"tomcat.global.sent",
"jvm.gc.max.data.size",
"logback.events",
"system.cpu.count",
"jvm.memory.max",
...
...
...
]
}
"statistic": "MAX",
"value": 0.17822937
}
],
"availableTags": [
{
"tag": "exception",
"values": [
"None"
]
},
{
"tag": "method",
"values": [
"GET"
]
},
{
"tag": "uri",
"values": [
"/actuator/metrics/{requiredMetricName}",
"NOT_FOUND",
"/actuator/metrics",
"/Produits"
]
},
{
"tag": "status",
"values": [
"404",
"200"
]
}
]
}
Vous avez le nombre de requêtes traitées par le serveur (très utile pour surveiller l'activité), et également la liste des URL que l'on a tenté d'appeler dans ce cas :
"/actuator/metrics/{requiredMetricName}",
"NOT_FOUND",
"/actuator/metrics",
"/Produits"
/beans
Cet endpoint est accessible via http://localhost:9001/actuator/beans, et vous donne accès à la liste des beans créés par la BeanFactory.
Dans notre cas, par exemple, nous retrouverons notre bean de configuration ApplicationPropertiesConfiguration :
"applicationPropertiesConfiguration":
{
"aliases": [],
"scope": "singleton",
"type": "com.mproduits.configurations.ApplicationPropertiesConfiguration",
"resource": "file [/Users/amar/IdeaProjects/Mcommerce/microservice-produits/target/classes/com/mproduits/configurations/ApplicationPropertiesConfiguration.class]",
"dependencies": []
},
C'est pratique quand un bean ne fonctionne pas et que vous souhaitez savoir s'il a été correctement créé.
/env
http://localhost:9001/actuator/env affiche toutes les variables d'environnement, ce qui est très utile pour savoir quels paramètres ont été pris en compte en cas de conflit.
En résumé
Spring Actuator permet d’exposer l’état de notre application.
Il permet aussi de suivre les metrics de notre application.
C'est la fin de ce cours, merci de l'avoir suivi ! Voici un dernier quiz pour évaluer vos connaissances, c'est parti !