5.1.6. Suivi de l’état du système¶

5.1.6.1. API de supervision¶

Chaque composant VITAM doit exposer en interne de la plate-forme, sur un port dédié, les API REST suivantes :

/admin/v1/status : statut simple, renvoyant un statut de fonctionnement incluant des informations techniques sur l’état actuel du composant. Un exemple d’utilisation typique est l’intégration à un outil de supervision ou à un élément actif tiers (ex: load-balancer, ...) . L’appel doit être peu coûteux.
/admin/v1/autotest : autotest du composant, lançant un test de présence des différentes resources requises par le composant et renvoyant un statut d’état de ces resources.
/admin/v1/version : statut renvoyant les informations relatives à la version.

Voir aussi

D’autres interfaces de status dédiées aux applications métier sont disponibles sur les composants externes (zone accès) ; elles sont décrites dans la documentation d’API de VITAM.

Ces API sont exposées sur un réseau d’administration qui peut être différent du réseau de service.

Voir aussi

D’autres API d’administration sont disponibles selon les composants ; se reporter au paragraphe idoine dans la liste des services

5.1.6.2. Métriques¶

Chaque composant VITAM doit permettre l’envoi d’un certain nombre de métriques soit dans les logs de l’application, soit dans une base de données Elasticsearch ; ces métriques sont de 3 types différents :

Les métriques relatives aux statistiques d’accès des interfaces REST :
- Fréquence d’appel sur les dernière 1, 5 et 15 minutes ;
- Nombre de résultats selon le code HTTP renvoyé ;
- Avec un sampling des temps de réponses biaisé sur les 5 dernières minutes :
  Le minimum
  
  Le maximum
  
  La moyenne
  
  L’écart type
  
  Le 95 ^ème percentile
Les métriques relatives à l’usage de la JVM :
- Consommation mémoire des différentes zones mémoire interne de la JVM
- Etat des threads utilisés
- Statistiques d’appels du/des ramasse-miette(s)
Les métriques métier, relatives à des cas d’utilisation métier (archivistes) du système

Note

VITAM propose un sous-système dédié à la collecte et exploitation des métriques qui s’appuie sur les composants également utilisés pour la gestion centralisée des logs ; il est décrit plus en détails dans la section dédiée.

5.1.6.3. Logs¶

5.1.6.3.1. Protocoles : syslog¶

Les protocoles d’emission de logs (entre un émetteur de logs et l’agent syslog local) possibles sont :

Le format syslog unix (écriture dans /dev/log), privilégié pour les messages émis par les scripts shell (protocole par défaut de la commande logger) .

Le format syslog udp (sans garantie d’acheminement, vers l’adresse localhost), privilégié pour les messages émis par les applications.

Dans les deux cas, et en se basant sur la RFC 5424, les paramètres imposés sur les messages syslog sont les suivants :

Facility : local0 (id 21) ; Vitam n’utilise pas les facilités “système” mais seulement les facilités local0 à local3.
Message Severity : dans le cas des applications Java, le mapping de sévérité suit le mapping imposé par l’appender logback SyslogAppender (DEBUG 7, INFO 6, WARN 4 et ERROR 3).
Le positionnement du champ APP-NAME correspondant à l’application ; pour les applications VITAM, ce champ doit être égal à l’id du composant vitam (devant respecter le pattern vitam-.*). Pour les scripts, il doit être égal au nom du script (comportement par défaut pour un logger unix).

Note

A noter que l’instance de l’application n’est pas mise dans le champ APP-NAME car du fait des principes de packaging, il ne peut y avoir qu’une seule instance d’application par hôte et le tuple (HOSTNAME, APPNAME) identifie bien l’application.

5.1.6.3.2. Types de log¶

Les logs se divisent en plusieurs catégories :

5.1.6.3.2.1. Logs applicatifs¶

Les logs applicatifs couvrent les logs produits par le code des applications ; ils permettent de suivre un certain nombre d’évènements techniques et métiers remontés par les applications.

Leur format est imposé par VITAM (se reporter au DEX pour le format exact des logs).

Par défaut, ces logs sont déposés de deux manières différentes :

des fichiers de logs (dans le répertoire de log dédié pour chaque composant (Cf. la section dédiée)). Ils sont configurés pour rouler quotidiennement, avec une taille globale maximale ; le pattern des fichiers est <service_id>.%d.log (%d étant remplacé par yyyy-MM-dd).
le service syslog local, en utilisant le protocole syslog UDP (port 514 ; format défini dans la RFC3164).

Note

VITAM propose un sous-système dédié à la collecte et exploitation des logs qui s’appuie sur ce service syslog local pour l’acquisition des logs ; il est décrit plus en détails dans la section dédiée.

La corrélation des logs afférents à la même requête métier mais distribuée au sein des différents composants du système est réalisée grâce au positionnement d’un identifiant de requête au niveau des briques externes. Cet identifiant se retrouve dans tous les logs applcatifs, et est propagé entre les composants via l’usage du header HTTP X-REQUEST-ID.

Enfin, ces logs applicatifs transportent également les alertes émises par les composants VITAM, et notamment les alertes de sécurité.

5.1.6.3.2.2. Logs du garbage collector Java¶

Ces logs permettent de faire une analyse fine du fonctionnement interne de la JVM à travers les informations d’exécution des différents garbage collectors.

Leur format est imposé par l’implémentation de la JVM.

Ils sont déposés dans des fichiers (dans le répertoire de log dédié pour chaque composant (Cf. la section dédiée)) : gc/gc.log pour le fichier courant, gc.log.<n> pour les fichiers roulés (avec <n> le numéro du fichier, sur base 0). Le roulement est basé sur une limite de taille unitaire des fichiers, avec un nombre maximal de fichiers.

5.1.6.3.2.3. Logs d’accès¶

Les logs d’accès sont placés sur tous les services métiers VITAM ; ils permettent de tracer de manière fine (avec une granularité à la requête) les appels de ces services.

Leur format est imposé par VITAM (se reporter au DEX pour le format exact des logs).

Ces logs sont déposés dans des fichiers (dans le répertoire de log dédié pour chaque composant (Cf. la section dédiée)). Ils sont configurés pour rouler quotidiennement, avec une taille globale maximale ; le pattern des fichiers est accesslog-<service_id>.%d.log (%d étant remplacé par yyyy-MM-dd).

5.1.6.4. Suivi de l’état de déploiement¶

Le suivi de l’état de déploiement se fait au travers de l’outil de déploiement utilisé.

5.1.6.5. Intégration à un système de monitoring tiers¶

L’intégration à un système de monitoring tiers est possible via les points d’extension suivants :

Les API REST de monitoring des composants Java
L’utilisation des composants standards de monitoring des COTS utilisés