How to Read MongoDB Log Error Messages

Introduction

If you do any type of development or database admin you know the feeling of staring at a cryptic error message and having no idea where to start debugging. Just looking at that cryptic error message can be intimidating. Our goal for this article is to take some of that fear away by explaining the format of the MongoDB error messages so we can have better understanding of the problem, how severe it is, and where it happened.

The Format of the MongoDB Log Errors

Let’s take a look at the latest format for MongoDB errors which you can find by looking at your MongoDB log file which is commonly located at /var/log/mongodb/mongodb.log. If the file’s not there, you’ll need to find your mongodb.conf file which specifies where your log file lives. Your mongodb.conf file typically lives at /etc/mongodb.conf. Once you find the mongodb.conf file look for the logpath option which will specify where your log file is.

The format of the logs looks like this:

Timestamp

The timestamp will give you the time that the error occurred. Depending on your specific settings it can show in different formats but should look something like this:

If you had a failure at a certain time you can filter your logs for that time to try and discover if anything out of the ordinary happened.

Severity

The next part of the log message is the severity indicator which has five different levels that are outlined below starting with the most severe:

F Fatal- The database is no longer accessible because of the error. E Error – These errors will stop execution of the database. W Warning – These are potentially harmful behavior of the database. I Informational – These are informational logs like when a connection to the database is made or one is lost. D Debug – The debug messages are messages intended to help the user debug a higher severity problem.

Components

The component portion gives you information about what type of functionality the log deals with. So if you have an error related to indexing your component would read “Index”. The full list of components are below:

Access – The issue deals with access control Command – The issue deals with database commands Control – The issue deals with control activities FTDC – The issue deals with diagnostic data collection activities Geo – The issue deals with parsing geospatial shapes Index – The issue deals with indexing operations Network – The issue deals with network activities Query – The issue deals with queries REPL – The issue deals with replica sets REPL_HB – The issue deals with replica sets heartbeats Rollback – The issue deals with rollback Sharding – The issue deals with sharding Storage – The issue deals with storage activities Journal – The issue deals with journal activities Write – The issue deals with writing to the database

The component is very insightful and will help you narrow down your problem.

Context

The context component is surrounded by brackets and it will populate with the id of the thread or connection. It’s also possible that it has the value of ‘initandlisten’ which happens on new connections.

Message

The message part of the log will give you the most information about the issue and will try to tell you explicitly what happened. Sometimes it’s easier to read then others.

An Example Log

For this example we have the timestamp. The severity of I which means it’s purely informational. We have the initandlisten context which means a new connection is being made and the message which explicitly says that.

Conclusion

We hope you found this breakdown of the MongoDB logs helpful. The logs should appear a lot less daunting and hopefully you can debug your database errors quicker. Thank you for reading and please don’t hesitate to reach out to us at Object Rocket if you need help handling your production data. Thanks for your time.