MongoDB Monitoring

By default MongoDB listens on port 27017 and does not have authentication configured.  If this is your setup, then MongoDB monitoring will be automatically discovered and monitoring will begin immediately on your database once the device is added to LogicMonitor.  If your device does not display any MongoDB* datasources, manually run Active Discovery on your device.  

Note: Make sure that the IP address of your Collector is included in the IP addresses specified in the etc/mongod.conf file bind entry. 

If authentication is in use you will need to supply the username and password by setting two properties on the device itself. The properties are:

• mongodb.user
• mongodb.pass

 If you want to connect to your Mongo instances over SSL, set the property Mongodb.SSL to the value true.

Additionally, in order to initiate monitoring, LogicMonitor users must be stored in the “admin” DB. They must also be assigned a “clusterMonitor” role.

If running on a port other than the default 27017, or if you have multiple MongoDB instances running on the same device, you will need to set the property mongodb.ports.  The property value should be a comma separated list of ports. After setting this property, refresh your screen after about 10 seconds and your MongoDB instances should be discovered.

With the MongoDB collector, LogicMonitor provides for the ability to query, alert on and graph arbitrary data returned by MongoDB queries, using standard JSON expressions.  The best way to get a handle on how to do this is to view the MongoDB- datasource and see how we are parsing db.serverStatus().  A quick example for getting ‘uptime’ and ‘globalLock currentQueue readers’ from the below results:

uptime: output.uptime

readers: output.GlobalLock.currentQueue.readers

> db.serverStatus() { "host" : "jb-vm-centos.sb.logicmonitor.net", "version" : "1.8.1", "process" : "mongod", "uptime" : 3319, "uptimeEstimate" : 3285, "localTime" : ISODate("2011-07-28T21:58:08.918Z"), "globalLock" : { "totalTime" : 3319046531, "lockTime" : 11182085, "ratio" : 0.003369065451646722, "currentQueue" : { "total" : 0, "readers" : 0, "writers" : 0 }, "activeClients" : { "total" : 0, "readers" : 0,    

The ability to use groovy scripts to call Mongo is very powerful. This is how the MongoDB Replication datasource works, and automatically adjusts to whether password authentication, or SSL, is required to establish a connection.  However, it does have some risks. You must be sure to close any MongoClient object your script uses – otherwise, the behaviour of Mongo is to create a connection pool with each script that creates a MongoClient object. If you do not close the objects, this will cause a file descriptor leak in the collector, which can cause the collector process to run out of file descriptors, and break a variety of monitoring.

Be aware that in groovy, objects created within a try block may be scoped to be only accessible within that block – so that closing a MongoClient in a catch block will not close an object that was created in the try block.