Métriques applicatives ###################### Besoins ======= À des fins de monitoring des composants logiciels Java :term:`VITAM` et de l'utilisation des ressources système par ceux-ci, :term:`VITAM` intègre un reporting et une gestion de métriques applicatives. 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. Choix des implémentations ========================= Enregistreur de métriques ------------------------- Dans le système :term:`VITAM`, l'enregistrement de métriques s'effectue uniquement dans les composants logiciels Java à l'aide du librairie `Prometheus metrics `_. Les plugins suivants sont utilisés pour leur métriques respectives : * `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 : - 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 :term:`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 :term:`VITAM` qui doit documenter ses propres métriques, si des métriques spécifiques sont ajoutées. Reporters de métriques ---------------------- Dans le système :term:`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. Endpoint des métriques ---------------------- À partir de la release R14, le système :term:`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. 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 :doc:`dans la section précédente<05-logs-architecture>`. * 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 :term:`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 :term:`Vitam` Limites ======= La solution implémentée dans :term:`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é).