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.

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 les échanges avec le support VITAM, un playbook d’exploitation a été développé pour collecter automatiquement les informations suivantes:

• 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)
• l’état des clusters Elasticsearch
• la possibilité, au choix de l’exploitant, de fournir également les clés publiques des certificats

À l’issue de l’exécution de ce playbook, les données collectées sont compactées et accessibles à l’emplacement suivant selon la règle de nommage: environments/troubleshoot_<date>-<log_files_age>_<vitam_site_name>.zip

Ce fichier pourra ainsi être communiqué à VITAM dans le cadre d’une demande de 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 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 (doit être >0).

Paramètres optionnels:

--extra-vars "sync_type=rsync get_crt=YES excludes=gc*"

• sync_type [default:fetch, rsync]: Pour définir la méthode de récupération des fichiers de logs. La méthode rsync va installer le package rsync sur les machines et nécessitera l’ouverture des ports réseaux associés au niveau des Firewall pour fonctionner.
• get_crt [YES, default:NO]: Pour confirmer la récupération des certificats dans le troubleshoot.
• excludes [xxx*,yyy*, default:””]: Pour exclure certains fichiers à récupérer 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.