Décodage des journaux d'erreurs MongoDB

Parfois, le décodage des journaux d'erreurs MongoDB peut être délicat et peut consommer une grande partie de votre temps précieux. Dans cet article, nous allons apprendre à examiner les journaux d'erreurs MongoDB en disséquant chaque partie des messages de journal.

Format commun pour les lignes de journal MongoDB

Voici le modèle de ligne de journal pour la version 3.0 et supérieure...

<timestamp> <severity> <component> [<context>] <message>

Modèle de ligne de journal pour les versions précédentes de MongoDB uniquement inclus :

<timestamp> [<context>] <message>

Examinons chaque balise.

Horodatages

Le champ Horodatage du message de journal stocke l'heure exacte à laquelle un message de journal a été inséré dans le fichier journal. Il existe 4 types d'horodatages pris en charge par MongoDB. Le format par défaut est :iso8601-local. Vous pouvez le modifier à l'aide du paramètre --timeStampFormat.

Gravité

Le tableau suivant décrit la signification de tous les niveaux de gravité possibles.

Composant

Après la version 3.0, les messages de journal incluent désormais un "composant" pour fournir une catégorisation fonctionnelle des messages. Cela vous permet d'affiner facilement votre recherche en examinant les composants spécifiques.

Contexte

La partie contextuelle du message d'erreur contient généralement le thread ou l'ID de connexion. D'autres valeurs peuvent être init et listen. Cette partie est entourée de crochets. Les messages de journal de toute nouvelle connexion à MongoDB auront une valeur de contexte comme initandlisten, pour tous les autres messages de journal, il s'agira soit de l'identifiant du thread, soit de l'identifiant de la connexion. Par exemple

2018-05-29T19:06:29.731+0000 [initandlisten] connection accepted from 127.0.0.1:27017 #1000 (13 connections now open)
2018-05-29T19:06:35.770+0000 [conn1000] end connection 127.0.0.1:27017 (12 connections now open)

Message

Contient le message de journal réel.

Emplacement du fichier journal

L'emplacement par défaut sur le serveur est :/var/log/mongodb/mongodb.log

Si le fichier journal n'est pas présent à cet emplacement, vous pouvez archiver le fichier de configuration MongoDB. Vous pouvez trouver le fichier de configuration MongoDB à l'un de ces deux emplacements.

/etc/mongod.conf or /yourMongoDBpath/mongod.conf

Une fois que vous avez ouvert le fichier de configuration, recherchez l'option logpath dedans. L'option logpath indique à MongoDB où enregistrer tous les messages.

Analyser un message de journal simple

Voici un exemple de message d'erreur typique de MongoDB...

2014-11-03T18:28:32.450-0500 I NETWORK [initandlisten] waiting for connections on port 27017

Horodatage :2014-11-03T18:28:32.450-0500
Gravité : I
Composant :NETWORK
Contexte :[initandlisten]
Message :en attente de connexions sur le port 27017

La partie la plus importante de cette erreur est la partie message. Dans la plupart des cas, vous pouvez déterminer l'erreur en consultant ce champ. Parfois, si le message n'est pas clair pour vous, vous pouvez opter pour la partie composant. Pour ce message, la valeur du composant est Réseau, ce qui signifie que le message de journal est lié à un problème de réseau.

Si vous ne parvenez pas à résoudre votre erreur, vous pouvez vérifier la gravité du message de journal qui indique que ce message est à titre informatif. En outre, vous pouvez également consulter d'autres parties du message de journal, telles que l'horodatage ou le contexte, pour trouver la cause première complète.

Décodage des messages courants du journal des erreurs

1. Message :

   2018-05-10T21:19:46.942 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.

   Résolution : Créer un utilisateur administrateur dans la base de données d'authentification

2. Message :

   2018-05-10T21:19:46.942 E COMMAND  [initandlisten] ** ERROR: getMore command failed. Cursor not found

   Résolution : Supprimez le délai d'attente du curseur ou augmentez la taille du lot du curseur.

3. Message :

   2018-05-10T21:19:46.942 E INDEX  [initandlisten] ** ERROR:E11000 duplicate key error index: test.collection.$a.b_1 dup key: { : null }

   Résolution : Violation de la contrainte de clé unique. Essayez d'insérer un document avec une clé différente.

4. Message :

   2018-05-10T21:19:46.942 E NETWORK  [initandlisten] ** ERROR:Timed out connecting to localhost:27017.

   Résolution : La latence entre le pilote et le serveur est trop importante, le pilote peut abandonner. Vous pouvez modifier le paramètre en ajoutant l'option connectionTimeout dans la chaîne de connexion.

5. Message :

   2018-05-10T21:19:46.942 E WRITE  [initandlisten] ** ERROR: A write operation resulted in an error. E11000 duplicate key error index: test.people.$_id_ dup key: { : 0 }

   Résolution : Supprimer la duplication de la valeur du champ _id des documents en conflit.

6. Message :

   2018-05-10T21:19:46.942 E NETWORK  [initandlisten] ** ERROR: No connection could be made because the target machine actively refused it 127.0.0.1:27017 at System.Net.Sockets.Socket.EndConnect

   Résolution : Soit le serveur ne fonctionne pas sur le port 27017, soit essayez de redémarrer le serveur avec l'hôte et le port corrects.

Outils de gestion des journaux

MongoDB 3.0 a mis à jour ses fonctionnalités de journalisation pour fournir de meilleures informations sur toutes les activités de la base de données. Il existe de nombreux outils de gestion des journaux disponibles sur le marché, tels que MongoDB Ops Manager, les entrées de journal, les mtools, etc.

Conclusion

La journalisation est aussi importante que la réplication ou le partage pour une bonne gestion de la base de données. Pour une meilleure gestion de la base de données, il faut pouvoir décoder facilement les logs pour rectifier rapidement les exceptions/erreurs. J'espère qu'après avoir lu ce tutoriel, vous vous sentirez plus à l'aise lors de l'analyse de journaux MongoDB complexes.