6.3. Troubleshooting

Cette section a pour but de recenser les problèmes déjà rencontrés et apporter une solution associée.

6.3.1. 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 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. 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.2. 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.3. 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.4. 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.5. 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>, puis db.<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.