6.3. Logs

La solution logicielle VITAM propose une solution ouverte, au choix de l’exploitant. Ce dernier peut, à l’installation, comme à la mise à jour de la solution logicielle VITAM, choisir d’utiliser sa propre solution de « regroupement » des logs ou la solution embarquée dans la solution logicielle VITAM.

Dans le cas de la solution embarquée, celle-ci se décompose en :

  • rsyslog ou syslog-ng (choix à l’installation, se référer au DIN) déployé sur les machines « applicatives » VITAM et les envois applicatifs syslog vers un serveur de centralisation de logs (via facility local0)

  • un serveur de centralisation de logs, comprenant :

    • un mono-noeud (au minimum, ou multi-noeuds) Elasticsearch
    • un moteur logstash, parsant les messages VITAM
    • un afficheur de rendu/aggrégation de données Kibana dédié

Voir aussi

Les principes et implémentations du système de gestion de logs inclus dans VITAM sont décrits plus en détail dans le DAT.

6.3.1. Paramétrage des règles de log

Il est conseillé de modifier le paramétrage du rolling des fichiers de log afin d’éviter une saturation des volumes disque. En fonction de la topologie de déploiement des composants vitam, il faut s’assurer que les quantités maximales de fichiers de log (en nombre et taille) ne dépassent pas la taille du disque, en décomptant la volumétrie évaluée aux données ainsi qu’aux fichiers temporaires.

Avertissement

Dans le cas de la colocalisation des composants Vitam, il faut prendre en compte les quantités maximales par composant, afin de paramétrer des quantités cohérentes pour ne pas dépasser la taille du disque.

Pour cela, il faut éditer au niveau des fichiers deployment/environments/group_vars/all/main/main.yml et deployment/environments/group_vars/all/advanced/vitam_vars.yml les paramètres suivants :

  • logback_rolling_policy: { true | false } active le rolling des fichiers de logs (applicatif et accès), avec la politique logback TimeBasedRollingPolicy (voir doc <http://logback.qos.ch/manual/appenders.html#RollingFileAppender>) dont les paramètres sont définis ci-après. Si ce paramètre est désactivé, les logs ne tournent pas et leur taille augmente à l’infini (cas ou l’implémentation de rolling est géré avec un composant externe à Vitam). La valeur par défaut est true.

  • Pour les logs applicatif :

    • logback_max_file_size: { \d*[KB|MB|GB] } spécifie le seuil pour lequel une fois atteint, le fichier tourne. Le nom du fichier de log est suffixé par un index. La valeur par défaut est « 10MB ».

    • logback_total_size_cap: {struct yml}:

      <type>: { file | security | offer_tape | offer_tape_backup | offersync }: spécifie le type de fichier de log (correspond à un appender logback). Tous les composants Vitam dispose au moins des types file et security. Les 3 autres types sont disponibles pour le composant offer.

      Pour chacun des types spécifiés dans la structure yml, les paramètres suivants sont éditables :

      • history_days: { \d* } spécifie le nombre total de fichiers conservés. Ce nombre total est équivalent en nombre de jour conservé lorsque le fichier ne tourne pas dans une journée (lorsqu’il n’a pas atteint la limite logback_max_file_size). Cette équivalence est induite par le mécanisme interne au framework logback qui utilise le pattern date spécifié dans le nom du fichier (cf. documentation officielle pour plus de détail). Lorsqu’un fichier tourne et que le nombre de fichier présent est atteint, le premier fichier qui a été tourné est supprimé. La valeur par défaut est 10.
      • totalsize: { \d*[KB|MB|GB] } spécifie la taille totale des fichiers de logs. Lorsque la taille totale des fichiers présents dépasse la taille paramétrée, le premier fichier qui a été tourné est supprimé. La valeur par défaut est 5GB.

    L’ensemble de ces paramètres sont utilisés lors de la génération du fichier /vitam/conf/<composant>/logback.xml qui ne doit pas être édité manuellement, au risque de perdre les modifications au prochain déploiement.

  • Pour les logs d’accès http :

    • access_retention_days: { \d* } spécifie le nombre total de fichiers conservés. Ce nombre total est équivalent en nombre de jour conservé lorsque le fichier ne tourne pas dans une journée (lorsqu’il n’a pas atteint la limite logback_max_file_size). La valeur par défaut est 30.
    • access_total_size_cap: { \d*[KB|MB|GB] } spécifie la taille totale des fichiers de logs. Lorsque la taille totale des fichiers présents dépasse la taille paramétrée, le premier fichier qui a été tourné est supprimé. La valeur par défaut est 10GB.

    L’ensemble de ces paramètres sont utilisés lors de la génération du fichier /vitam/conf/<service_id>/logback-access.xml qui ne doit pas être édité manuellement, au risque de perdre les modifications au prochain déploiement.

Prudence

La configuration de la durée de rétention des logs d’accès et/ou leur externalisation devra être ajustée pour respecter les contraintes légales en vigueur pour le système déployé.

D’autres paramètres sont disponibles :

  • Pour les logs de la jvm :

    • jvm_log: { true | false } : active les logs jvm en spécifiant les paramètres -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile={vitam_folder_log}/jvm.log à la commande java. La valeur par défaut est false.

    Ce paramètre est utilisé lors de la génération du fichier /vitam/conf/<service_id>/java_opts qui ne doit pas être édité manuellement, au risque de perdre les modifications au prochain déploiement.

    L’activation de ces logs peut être nécessaire pour analyser un problème en rapport avec la jvm. Si besoin, d’autres paramètres sont disponibles, mais ne sont pas prévus dans les paramètres du fichier de déploiement. Il est possible toutefois de les ajouter temporairement au fichier généré. Par exemple, les paramètres des logs du GC sont:

    • Niveau de détail : activation des détails et des timestamps (paramètres JVM -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime)

    • Roulement : le roulement des fichiers dépend de la taille des fichiers, avec un nombre de fichiers maximal ; il est défini comme suit :

      • Activation du roulement : paramètre JVM -XX:+UseGCLogFileRotation
      • Nombre total de fichiers conservés : paramètre JVM -XX:NumberOfGCLogFiles=10
      • Taille unitaire maximale d’un fichier de logs : paramètre JVM -XX:GCLogFileSize=10M
      • Pattern des fichiers : dans le répertoire de logs de l’application (paramètre -Xloggc:$LOG_FOLDER/gc.log) pour le fichier courant ; après roulement, les fichiers sont nommés gc.log.<n> (avec <n> le numéro du fichier, sur base 0).

  • Pour les logs applicatif :

    • performance_logger: { true | false } : active les traces qui consignent le temps d’exécution passé dans un composant ou traitement vitam. Ces métriques sont utilisées dans le dashboard Kibana Metrics workflow vitam. La valeur par défaut est false.

6.3.2. Rétention des index sous elasticsearch-log

Curator est l’outil défini dans VITAM pour nettoyer les index du cluster elasticsearch de log. Curator a été paramétré avec les informations contenues, durant l’installation, dans le fichier main.yml pour les paramètres principaux et cots_vars.yml pour les paramètres avancés.

Pour les différents index dans le cluster Elasticsearch de log, deux paramètres sont définis pour Curator :

  • close: { \d* } nombre de jours avant clôture de l’index. La valeur par défaut est 7 (5 pour metricbeat/packetbeat).
  • delete: { \d* } nombre de jours avant suppression de l’index. La valeur par défaut est 30 (10 pour metricbeat/packetbeat).

Note

concernant les index « logstash-* », il est recommandé de laisser une durée de rétention de 1 an dans un contexte de production.

Il est possible de modifier le comportement de curator. Pour ce faire, il faut :

  1. modifier le fichier environments/group_vars/all/main/main.yml
  2. rejouer le playbook de déploiement, en ajoutant en fin de commande --tags curator_logs.