Monitoring MongoDB is very similar to monitoring a normal relational database. If it’s on its own machine then you need to care about things like how much CPU it’s taking up, how much RAM, how fast are the disks etc. If Mongo starts grinding on any of your core compute resources then guess what, you’ve got a problem!
A good Database Administrator, which hopefully we all aspire to be, needs to monitor more then just the basics. A good Database Administrator needs to monitor the actual database. Not to mention in many cases especially with Mongo you will need to monitor a cluster of databases, not just one instance. You’re in luck with Mongo, because fortunately the folks at 10gen, the makers of MongoDB, have written some excellent documentation for how to properly administer and performance tune MongoDB.
Before we get into how we can monitor Mongo, let’s take a brief moment to talk about how Mongo works. Mongo is a structured NoSql database. Basically, you store your data as records in collections (think rows and tables if you’re still in the relational world). Now, the Mongo records are actually any valid JSON object. You can even nest objects which leads to some interesting ways that you can structure your data.
Mongo was built to scale. The current standard installation of Mongo supports Master/Slave Replication, Replica Sets, and Auto-Sharding right out of the box. You can easily get into complex monitoring situations when you need to monitor not just one database but an entire cluster.
When you use Mongo, you need to understand that it is extremely fast in its default configuration. The reason? The default configuration is not very concerned if you lose data or if replication fails or if your mongo instance crashes and loses an hour or so worth of data. This might sound horrifying if you are storing your users data and they expect their comments, financial reports or medical records to be in your system. However, that default configuration may be great if you are throwing in thousands of rows a second of server log data, and it’s OK if you lose a few records here or there for some reason.
Keep in mind though that you can control how safe or how fast Mongo is, so make sure you understand your data, and what types of failures you can live with and which failures will cost you your job.
Mongo comes with a pretty nice HTTP Console that usually runs on port 28017. Even better Mongo supports REST calls to this HTTP Console, so you can grab Mongo stats from anywhere using simple HTTP requests. You get back, you guessed it, JSON, so you can just grab and start collecting. With the HTTP Console, you can get information like db version, master slave info, information about the replica set, the number of databases, uptime, outstanding cursors, etc.
Now, you should have a pretty good idea about the basics of Mongo and monitoring. In our next article, we will look into some cool monitoring services that work great with Mongo.