5.7. Métriques applicatives

5.7.1. Besoins

À des fins de monitoring des composants logiciels Java VITAM et de l’utilisation des ressources système par ceux-ci, VITAM intègre un reporting et une gestion de métriques applicatives.

5.7.2. Modèle générique

On peut noter les composants suivants :

• Enregistreur de métriques : il s’agit de la librairie en charge de l’enregistrement d’une métrique.
• Reporters de métriques: il s’agit de librairies en charge de collecter les métriques enregistrées et d’en faire un reporting.
• Endpoint des métriques: Il s’agit d’une API depuis laquelle des outils de monitoring peuvent récupérer des métriques en mode pull au format prometheus
• Stockage des métriques : il s’agit du composant stockant les métriques (de manière plus ou moins requêtable).
• Visualisation des métriques : il s’agit du composant (souvent:term:IHM) qui permet la recherche et la visualisation des métriques.

5.7.3. Choix des implémentations

5.7.3.1. Enregistreur de métriques

Dans le système VITAM, l’enregistrement de métriques s’effectue uniquement dans les composants logiciels Java à l’aide des librairies Dropwizard metrics et Prometheus metrics.

Les plugins suivants sont utilisés pour leur métriques respectives :

• Dropwizard Core integration pour les métriques spécifiques (REST, BUSINESS).
• Dropwizard JVM integration pour les métriques JVM.
• Prometheus simpleclient_common et simpleclient pour développer de nouvelles métriques.
• Prometheus simpleclient_hotspot pour les métriques JVM.
• Prometheus simpleclient_dropwizard pour envelopper les métriques Dropwizard.

L’enregistreur de métriques possède un registre interne qui peut stocker différentes métriques :

• Dropwizard : Gauges, Counter, Timer, Meter ou Histograms. Ces métriques seront collectées dans le temps par le/les reporter(s) de métriques.
• Prometheus : Gauges, Counter, Summary ou Histograms. Ces métriques seront exposée via une API.

A la différence des Counter dans Dropwizard, ceux de prometheus ne se décrémente pas, il faut privilégier une Gauge dans ce das de figure

Les métriques RESTEasy sont automatiquement générées par l’application VITAM. Elles représentent un jeu de 3 métriques, Meter, Timer et ExceptionMeter pour chaque end-point des ressources de l’application.

Les métriques JVM sont aussi uniques par application. Elles représentent plusieurs types de métriques sur la consommation de ressources système.

Note

Une description fonctionnelle des métriques est disponible dans le manuel utilisateur dropwizard metrics. Veuillez vous référer au document d’architecture de chaque composant VITAM qui doit documenter ses propres métriques, si des métriques spécifiques sont ajoutées.

5.7.3.2. Reporters de métriques

Dans le système VITAM, un ou plusieurs reporters de métriques peuvent être utilisés. A ce jour, il existe deux reporters différents :

• Un reporter logback ;
• Un reporter ElasticSearch issue de la librairie metrics elasticsearch reporter.

Les reporters sont utilisés dans les composants logiciels Java. Ils sont en charge de récupérer les valeurs de toutes les métriques enregistrées et de les transmettre sur différents canaux, ici soit un logger logback ou une base de données ElasticSearch.

5.7.3.3. Endpoint des métriques

À partir de la release R14, le système VITAM permet d’exposer des métriques au format prometheus. Ces métriques sont exposées via une API dédiée. Un serveur prometheus, ou une autre solution de monitoring compatible avec le format prometheus, peut récupérer les métriques en mode pull depuis cette API. Un avantage du mode “pull” est de donner l’information sur l’état de la disponibilité du service en question. Ce mode est aussi plus économe en ressource qu’un mode “push” depuis le service lui-même vers l’outil de monitoring.

5.7.3.4. Stockage des métriques

Si un reporter de métriques ElasticSearch est utilisé, celles-ci seront stockées dans le moteur d’indexation ElasticSearch, dans un cluster dédié au stockage des logs/métriques (pour séparer les données de logs/métriques et les données métier d’archives). La description de ce cluster commun logs/métriques, incluant la gestion des index et la visualisation, se trouve dans la section précédente.

• Index : chaque index stockant des données de métriques correspond à 1 jour de métriques (déterminé à partir du timestamp de la métrique). Les index définis sont les suivants :

  • metrics-vitam-rest-YYYY.MM.dd pour les métriques de RESTEasy, avec un champ name automatiquement généré sous la forme :

    uri:http_method:consumed_types:produced_types:metric_type Exemple: _offer_v1__bulk_objects__type_:PUT:application_octet_stream:application_json:meter_total _offer_v1__bulk_objects__type_:PUT:application_octet_stream:application_json:timer

  • metrics-vitam-jvm-YYYY.MM.dd pour les métriques JVM.

  • metrics-vitam-business-YYYY.MM.dd pour les métriques métier.

  • .kibana pour le stockage des paramètres (et notamment des dashboards) Kibana.

À partir de la release R14 de la solution Vitam expose ses métriques au format prometheus. Il est possible de configurer un serveur prometheus pour récupérer ces métriques et un Grafana pour les visualiser. Ces deux outils sont largement utilisés, à ce jour, dans la communauté open source.

Note

Veuillez vous référer à la documentation d’exploitation pour savoir comment fonctionne l’intégration et la configuration du serveur prometheus dans Vitam

5.7.4. Limites

La solution implémentée dans Vitam possède les limites connues suivantes :

• Du fait que la librairie Dropwizard Metrics fait une agrégation des métriques et que le système de visualisation Kibana fonctionne lui aussi à l’aide d’agrégations, les résultats visualisés sont corrects dans la limite d’une certaine précision (certaines données deviennent non-représentatives de la réalité).