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.
  • 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 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 de la librairie Dropwizard metrics.

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

L’enregistreur de métriques possède un registre interne qui peut stocker différentes métriques : Gauges, Timer, Meter, Counter ou Histograms. Ces métriques seront collectées dans le temps par le/les reporter(s) de métriques.

Les métriques Jersey sont automatiquement générées par 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 fonctionelle des métriques est disponible dans le manuel utilisateur dropwizard metrics.

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 :

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. 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).

Ce cluster est configuré de la manière suivante :

  • Taille du cluster (pour les déploiements VITAM de taille importante, ce nombre pourra être amené à évoluer (Cf. les abaques fournies plus loin)) :
    • Nombre nominal de noeuds : 2 ;
    • Nombre nominal de shards primaires par index : 4 ;
    • Nombre nominal de replica : 1 ;

Note

Ces paramètres ne permettent pas de se parer contre la perte d’un noeud elasticsearch, et correspondent à un compromis en terme d’usage des resources VS résilience du système. Ces paramètres peuvent être changés si un besoin plus fort de résilience était identifié. Dans ce cas, on peut augmenter le nombre de noeuds ainsi que le nombre de replica, en veillant à ce que le nombre de shards primaires ne soit jamais inférieur au nombre de noeuds du cluster, et que le nombre de replica ne soit jamais supérieur au nombre de noeuds du cluster - 1.

Prudence

Une modification du nombre de shards primaires d’un index est une opération coûteuse à réaliser sur un cluster en cours de fonctionnement et qui doit dans la mesure du possible être évitée (indisponibilité du cluster et/ou risque de corruption et de perte de données en cas de problème au cours de l’opération) ; le bon dimensionnement de cette valeur doit être réalisé dès l’installation du cluster.

  • 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-jersey-YYYY.MM.dd pour les métriques de Jersey, avec un champ name automatiquement généré sous la forme :

      uri:http_method:consumed_types:produced_types:metric_type

    • 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.

5.7.3.3.1. Gestion des index

La gestion des index est réalisée par l’application Curator. Par défaut, l’outil est livré avec la configuration suivante :

  • Durée de maintien des index “online” : 7 jours ; cela signifie qu’au bout de 7 jours, les index seront fermés, et n’apparaîtront donc plus dans l’IHM de suivi des logs. Cependant, ils sont conservés, et pourront donc être réouverts en cas de besoin.
  • Durée de conservation des index : 30 jours ; au bout de cette durée, les index seront supprimés.

5.7.3.4. Visualisation des métriques

La visalisation des métriques se fait par le composant Kibana. Il est instancié de manière unique, et persiste sa configuration dans ElasticSearch (dans l’index .kibana).

Aucun mécanisme d’authentification n’est mis en place pour sécuriser l’accès à Kibana.

Indice

La version opensource de Kibana, utilisée dans VITAM, ne supporte pas nativement l’authentification des clients ; d’autres solutions peuvent être mises en place (ex: l’utilisation du composant Security), sous réserve d’une étude de compatibilité de la solution choisie.

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é).
  • Il n’existe à ce jour que 3 types de métriques, Meter, Timer et ExceptionMeter supportés par le plugin Jersey Dropwizard Metrics.