Compte tenu de l'architecture mise en place et du nombre plus élevé de démons qui entrent en compte dans le fonctionnement d'un cluster Mongodb que dans une installation classique, la maintenance et la résolution des problèmes peut être plus complexes.
Cette page recense et détaille les opérations de maintenance et des recherches/résolutions de problèmes courants
Vérification de l'état d'un cluster Mongodb
La vérification de l'état d'un cluster Mongo peut se faire de plusieurs manières:
- En vérifiant l'état des services Linux et les logs
- Directement via la console Mongodb
- Par les checks Mongodb livrés avec Shinken Entreprise
Services Linux
=> Parler des logs de Mongo sur tous les noeuds et de la récupération de statuts avec service ou systemctl
Console Mongodb
La console Mongodb permet de récupérer des informations détaillées sur l'état de chaque démon ainsi que leur statut au sein du cluster (primaire, secondaire, en récupération, injoignable etc...).
Pour accéder à la console Mongodb, il se connecter depuis n'importe quel noeud du cluster sur le démon "mongod" avec la commande suivante:
| Code Block | ||||
|---|---|---|---|---|
| ||||
mongo --port 27018 |
Une fois la console Mongo lancée, on se retrouve avec un invite de commande différent, qui nous permet de vérifier directement l'état du cluster:
| Code Block | ||
|---|---|---|
| ||
rs.status() |
On obtient le résultat suivant:
| Code Block |
|---|
rs-shinken:SECONDARY> rs.status();
{
"set" : "rs-shinken",
"date" : ISODate("2018-05-04T07:29:15Z"),
"myState" : 2,
"syncingTo" : "node2:27018",
"members" : [
{
"_id" : 0,
"name" : "node1:27018",
"health" : 0,
"state" : 8,
"stateStr" : "(not reachable/healthy)",
"uptime" : 0,
"optime" : Timestamp(0, 0),
"optimeDate" : ISODate("1970-01-01T00:00:00Z"),
"lastHeartbeat" : ISODate("2018-05-04T07:29:13Z"),
"lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
"pingMs" : 0
},
{
"_id" : 1,
"name" : "node2:27018",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 81988,
"optime" : Timestamp(1525250222, 106),
"optimeDate" : ISODate("2018-05-02T08:37:02Z"),
"lastHeartbeat" : ISODate("2018-05-04T07:29:14Z"),
"lastHeartbeatRecv" : ISODate("2018-05-04T07:29:14Z"),
"pingMs" : 1,
"electionTime" : Timestamp(1525336975, 1),
"electionDate" : ISODate("2018-05-03T08:42:55Z")
},
{
"_id" : 2,
"name" : "node3:27018",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 81988,
"optime" : Timestamp(1525250222, 106),
"optimeDate" : ISODate("2018-05-02T08:37:02Z"),
"self" : true
}
],
"ok" : 1
} |
Avec l'affichage ci-dessus, on tire par exemple les informations suivantes sur notre cluster:
- Le cluster comporte 3 nœuds (node1, node2, node3)
- Le nœud node2 est le nœud primaire, et le nœuds node3 est un nœud secondaire
- Le noeud node1 n'est pas joignable
- Le noeud node2 a été élu comme noeud primaire le à 07h29 (GMT)
Checks Shinken
Un cluster Mongo peut être supervisé avec Shinken. Shinken Entreprise met à votre disposition un Pack MongoDB
Le modèle d'hôte "mongodb" prend également en compte les aspects de réplication de la base avec les checks "Mongodb-replicaset" et "Mongodb-replication-lag".
En pratique, pour superviser un cluster Mongo avec Shinken Entreprise, on associe un hôte Shinken à un nœud du cluster. Chaque hôte aura le modèle "mongodb" accroché, ce qui permet de superviser ces 3 nœuds de manière indépendante. On effectue également la supervision sur le port 27018 au lieu du port 27017 utilisé par défaut.
Voici un aperçu du résultat des checks concernant la réplication de Mongo, pour un nœud primaire et pour un nœud secondaire:
| Panel |
|---|
|
| Panel |
|---|
|
Le modèle mongodb permet d'utiliser un tunnel SSH pour la connexion aux serveurs et l'exécution des checks. L'utilisation du tunnel SSH se fait en modifiant la donnée MONGO_CONNECTION_METHOD. Précisez la valeur "ssh" au lieu de "direct".
L'utilisateur et la clé SSH utilisés pour créer ce tunnel peuvent se configurer en modifiant les données MONGO_SSH_USER et MONGO_SSH_KEY sur l'hôte.
Le modèle mongodb se connecte aux démons mongod pour effectuer les vérifications sur le cluster Mongo. Dans une installation classique, ce démon utilise le port 27017.
Dans le cas du cluster, on a modifié le port que ce démon utilise pour utiliser le port 27018. Il faut donc également modifier le port utilisé dans Shinken en modifiant la donnée MONGO_PORT en 27018 sur l'hôte.
La configuration et le fonctionnement du pack MongoDB sont décrits en détail sur la page de documentation du pack Mongodb: Pack Mongodb.