10.1. Analyse de premier niveau

Cette section a pour but de présenter les premiers outils à utiliser pour réaliser une analyse de premier niveau, en cas de problème avec la solution logicielle VITAM.

10.1.1. Etat par Consul

Se connecter à l’IHM de Consul et recenser les états des composants de la solution logicielle VITAM.

../_images/consul_check.png

A l’heure actuelle, tous les composants doivent avoir un statut de couleur verte. Si ce n’est pas le cas :

  1. seul un composant est KO, alors redémarrer le composant incriminé
  2. si plusieurs services sont KO, suivre la procédure de redémarrage de VITAM
  3. si tous les « check-DNS » (visible dans le détail des checks de chaque service) sont KO, s’assurer que, sur les machines hébergeant VITAM, le fichier /etc/resolv.conf contient, en début de fichier, la ligne : nameserver 127.0.0.1.

10.1.2. Etat par Kibana

Se connecter à Kibana, aller dans « Dashboards ». Cliquer sur le bouton « Load Saved Dashboard » et sélectionner « Composants VITAM ». Eventuellement, changer la résolution (en haut à droite, par défaut, réglé sur les 15 dernières minutes).

Sur « pie-logback-error-level », cliquer sur la section de camembert d’intérêt (ERROR) et regarder, en bas de page, les éventuelles erreurs remontées dans Kibana.

10.2. Playbook ansible pour échanger avec le support

Afin de simplifier et minimiser les échanges, un playbook à fins d’exploitation/support a été développé.

Celui-ci comprend :

  • la récupération des informations machines de la solution logicielle VITAM
  • l’état Consul des composants
  • la récupération des traces applicatives (fichiers log) de moins de 2 jours
  • l’état des clusters Elasticsearch
  • la possibilité, au choix de l’exploitant, de fournir également les clés publiques des certificats

et compacte l’ensemble des données collectées, tout en purgeant le répertoire temporaire de récupération des données. Ce fichier est alors à envoyer par mail au support.

La commande pour générer le fichier est à lancer depuis le répertoire deployment :

ansible-playbook ansible-vitam-exploitation/troubleshoot.yml -i environments/hosts.<environnement> –ask-vault-pass

Certaines questions seront demandées durant l’exécution du playbook. Si vous souhaitez automatiser l’exécution de cette commande, voici les paramètres que vous pouvez passer en extra-vars: --extra-vars "confirmation=YES sync_type=fetch get_crt=NO log_files_age=1"

  • confirmation [YES, default:NO]: Pour confirmer le lancement du playbook.
  • log_files_age [default:2]: Pour définir le nombre de jours de logs à récupérer.
  • sync_type [default:rsync, fetch]: Pour définir la méthode de récupération des fichiers de logs.
  • get_crt [YES, default:NO]: Pour confirmer la récupération des certificats dans le troubleshoot.

10.3. Identification des AU non conformes

Le schéma JSON des AU a été corrigé et rationalisé. Toute donnée issue d’un Ingest d’une release précédente est conforme à cette expression corrigée du schéma. Dans les versions précédentes, le DSL autorisait des modifications non conformes au SEDA. Ce n’est plus possible dans la présente version.

Si des modifications non conformes ont eu lieu, alors des AU non conformes peuvent donc se retrouver en base. Lorsque cela arrive : * L’export DIP de l’AU peut échouer. * La modification d’un champ A rapportera une erreur sur un champs B non-conforme. La correction de ce problème se fera avec une requête DSL qui modifie le champ A et le champs B (en lui donnant une valeur conforme). * Maintenant les champs SEDA sont soit des tableaux, soit des valeurs simples (string ou objet). Certains champs qui pouvaient s’écrire sous forme de valeurs non tabulaires, doivent maintenant être écrits sous forme de tableau, même s’ils n’ont qu’un seul élément. Ex : Coverage.Spatial.

Cette procédure scriptée permet de détecter l’ensemble des AU non conformes. Les retours associés pourront être transmis au support VITAM (assistance@programmevitam.fr).

La commande pour générer le fichier est à lancer depuis le répertoire deployment :

ansible-playbook ansible-vitam-exploitation/check_unit_compatibility.yml -i environments/hosts.<environnement> –ask-vault-pass

A l’issue, si des AU sont considérées en erreur, se rapprocher du métier pour réaliser une première analyse / tentative de correction, par correction des données incorrectes.

Si l’erreur persiste, contacter le support.