6.3. Troubleshooting¶
Cette section a pour but de recenser les problèmes déjà rencontrés et y apporter une solution associée.
6.3.1. Erreur au chargement des index template kibana¶
Cette erreur ne se produit qu’en cas de filesystem plein sur les partitions hébergeant un cluster elasticsearch. Par sécurité, kibana passe alors ses index en READ ONLY.
Pour fixer cela, il est d’abord nécessaire de déterminer la cause du filesystem plein,puis libérer ou agrandir l’espace disque.
Ensuite, comme indiqué sur ce fil de discussion, vous devez désactiver le mode READ ONLY dans les settings de l’index .kibana du cluster elasticsearch.
Exemple:
PUT .kibana/_settings
{
"index": {
"blocks": {
"read_only_allow_delete": "false"
}
}
}
Indication
Il est également possible de lancer cet appel via l”IHM du kibana associé, dans l’onglet Dev Tools.
A l’issue, vous pouvez relancer l’installation de la solution logicielle VITAM.
6.3.2. Erreur au chargement des tableaux de bord Kibana¶
Dans le cas de machines petitement taillées, il peut arriver que, durant le déploiement, la tâche Wait for the kibana port to be opened prenne plus de temps que le timeout défini (vitam_defaults.services.start_timeout).
Pour fixer cela, il suffit de relancer le déploiement.
6.4. Retour d’expérience / cas rencontrés¶
6.4.1. Crash rsyslog, code killed, signal: BUS¶
Il a été remarqué chez un partenaire du projet Vitam, que rsyslog se faisait killer peu après son démarrage par le signal SIGBUS. Il s’agit très probablement d’un bug rsyslog <= 8.24 https://github.com/rsyslog/rsyslog/issues/1404
Pour fixer ce problème, il est possible d’upgrader rsyslog sur une version plus à jour en suivant cette documentation:
6.4.2. Mongo-express ne se connecte pas à la base de données associée¶
Si mongoDB a été redémarré, il faut également redémarrer mongo-express.
6.4.3. Elasticsearch possède des shard non alloués (état « UNASSIGNED »)¶
Lors de la perte d’un noeud d’un cluster elasticseach, puis du retour de ce noeud, certains shards d’elasticseach peuvent rester dans l’état UNASSIGNED ; dans ce cas, cerebro affiche les shards correspondant en gris (au-dessus des noeuds) dans la vue « cluster », et l’état du cluster passe en « yellow ».
Il est possible d’avoir plus d’informations sur la cause du problème via une requête POST sur l’API elasticsearch _cluster/reroute?explain. Si la cause de l’échec de l’assignation automatique a été résolue, il est possible de relancer les assignations automatiques en échec via une requête POST sur l’API _cluster/reroute?retry_failed.
Dans le cas où l’assignation automatique ne fonctionne pas, il est nécessaire de faire l’assignation à la main pour chaque shard incriminé (requête POST sur _cluster/reroute) :
{
"commands": [
{
"allocate": {
"index": "topbeat-2016.11.22",
"shard": 3,
"node": "vitam-iaas-dblog-01.int"
}
}
]
}
Cependant, un shard primaire ne peut être réalloué de cette manière (il y a risque de perte de données). Si le défaut d’allocation provient effectivement de la perte puis de la récupération d’un noeud, et que TOUS les noeuds du cluster sont de nouveaux opérationnels et dans le cluster, alors il est possible de forcer la réallocation sans perte.
{
"commands": [
{
"allocate": {
"index": "topbeat-2016.11.22",
"shard": 3,
"node": "vitam-iaas-dblog-01.int",
"allow_primary": "true"
}
}
]
}
Sur tous ces sujets, Cf. la documentation officielle.
6.4.4. Elasticsearch possède des shards non initialisés (état « INITIALIZING »)¶
Tout d’abord, il peut être difficile d’identifier les shards en questions dans cerebro ; une requête HTTP GET sur l’API _cat/shards permet d’avoir une liste plus compréhensible.
Un shard non initialisé correspond à un shard en cours de démarrage (Cf. une ancienne page de documentation. Si les shards non initialisés sont présents sur un seul noeud, il peut être utile de redémarrer le noeud en cause. Sinon, une investigation plus poussée doit être menée.
6.4.5. Elasticsearch est dans l’état « read-only »¶
Lorsque Elasticsearch répond par une erreur 403 et que le message suivant est observé dans les logs ClusterBlockException[blocked by: [FORBIDDEN/xx/index read-only / allow delete (api)];, cela est probablement consécutif à un remplissage à 100% de l’espace de stockage associé aux index Elasticsearch. Elasticsearch passe alors en lecture seule s’il ne peut plus indexer de documents et garantit ainsi la disponibilité des requêtes en lecture seule uniquement.
Afin de rétablir Elasticsearch dans un état de fonctionnement nominal, il vous faudra alors exécuter la requête suivante :
curl -XPUT -H "Content-Type: application/json" http://<es-host>:<es-port>/_all/_settings -d '{"index.blocks.read_only_allow_delete": null}'
6.4.6. MongoDB semble lent¶
Pour analyser la performance d’un cluster MongoDB, ce dernier fournit quelques outils permettant de faire une première analyse du comportement : mongostat et mongotop .
Dans le cas de VITAM, le cluster MongoDB comporte plusieurs shards. Dans ce cas, l’usage de ces deux commandes peut se faire :
soit sur le cluster au global (en pointant sur les noeuds mongos) : cela permet d’analyser le comportement global du cluster au niveau de ses points d’entrées ;
mongostat --host <ip_service> --port 27017 --username vitamdb-admin --password <password ; défaut : azerty> --authenticationDatabase admin mongotop --host <ip_service> --port 27017 --username vitamdb-admin --password <password ; défaut : azerty> --authenticationDatabase admin
soit directement sur les noeuds de stockage (mongod) : cela donne des résultats plus fins, et permet notamment de séparer l’analyse sur les noeuds primaires & secondaires d’un même replicaset.
mongotop --host <ip_service> --port 27019 --username vitamdb-localadmin --password <password ; défaut : qwerty> --authenticationDatabase admin mongostat --host <ip_service> --port 27019 --username vitamdb-localadmin --password <password ; défaut : qwerty> --authenticationDatabase admin
D’autres outils sont disponibles directement dans le client mongo, notamment pour troubleshooter les problèmes dûs à la réplication :
mongo --host <ip_service> --port 27019 --username vitamdb-localadmin --password <password ; défaut : qwerty> --authenticationDatabase admin
> rs.printSlaveReplicationInfo()
> rs.printReplicationInfo()
> db.runCommand( { serverStatus: 1 } )
D’autres commandes plus complètes existent et permettent d’avoir plus d’informations, mais leur analyse est plus complexe :
# returns a variety of storage statistics for a given collection
> use metadata
> db.stats()
> db.runCommand( { collStats: "Unit" } )
Enfin, un outil est disponible en standard afin de mesurer des performances des lecture/écritures avec des patterns proches de ceux utilisés par la base de données (mongoperf ):
echo "{nThreads:16,fileSizeMB:10000,r:true,w:true}" | mongoperf
6.4.7. Les shards de MongoDB semblent mal équilibrés¶
Normalement, un processus interne à MongoDB (le balancer) s’occupe de déplacer les données entre les shards (par chunk) pour équilibrer la taille de ces derniers. Les commandes suivantes (à exécuter dans un shell mongo sur une instance mongos - attention, ces commandes ne fonctionnent pas directement sur les instances mongod) permettent de s’assurer du bon fonctionnement de ce processus :
sh.status(): donne le status du sharding pour le cluster complet ; c’est un bon premier point d’entrée pour connaître l’état du balancer.use <dbname>, puisdb.<collection>.getShardDistribution(), en indiquant le bon nom de base de données (ex:metadata) et de collection (ex:Unit) : donne les informations de répartition des chunks dans les différents shards pour cette collection.
6.4.8. L’importation initiale (profil de sécurité, certificats) retourne une erreur¶
Les playbooks d’initialisation importent des éléments d’administration du système (profils de sécurité, certificats) à travers des APIs de la solution VITAM. Cette importation peut être en échec, par exemple à l’étape TASK [init_contexts_and_security_profiles : Import admin security profile to functionnal-admin], avec une erreur de type 400. Ce type d’erreur peut avoir plusieurs causes, et survient notamment lors de redéploiements après une première tentative non réussie de déploiement ; même si la cause de l’échec initial est résolue, le système peut se trouver dans un état instable. Dans ce cas, un déploiement complet sur environnement vide est nécessaire pour revenir à un état propre.
Une autre cause possible ici est une incohérence entre l’inventaire, qui décrit notamment les offres de stockage liées aux composants offer, et le paramétrage vitam_strategy porté par le fichier offers_opts.yml. Si une offre indiquée dans la stratégie n’existe nulle part dans l’inventaire, le déploiement sera en erreur. Dans ce cas, il faut remettre en cohérence ces paramètres et refaire un déploiement complet sur environnement vide.
6.4.9. Problème d’ingest et/ou d’access¶
Si vous repérez un message de ce type dans les log VITAM :
fr.gouv.vitam.common.security.filter.RequestAuthorizationValidator.checkTimestamp(AuthorizationWrapper.java:102) : [vitam-env-int8-app-04.vitam-env:storage:239079175] Timestamp check failed. 16s
fr.gouv.vitam.common.security.filter.RequestAuthorizationValidator.checkTimestamp(AuthorizationWrapper.java:107) : [vitam-env-int8-app-04.vitam-env:storage:239079175] Critical timestamp check failure. 61s
Il faut vérifier / corriger l’heure des machines hébergeant la solution logicielle VITAM.
Prudence
Si un delta de temps important (10s par défaut) a été détecté entre les machines, des erreurs sont tracées dans les logs et une alerte est remontée dans le dashboard Kibana des Alertes de sécurité.
Au delà d’un seuil critique (60s par défaut) d’écart de temps entre les machines, les requêtes sont systématiquement rejetées, ce qui peut causer des dysfonctionnements majeurs de la solution.