Open-source agent plugin designed for MongoDB monitoring, using the tool mongostat to collect performance statistics. For more information visit the following webpage: http://pandorafms.com/index.php?sec=Library&sec2=repository&lng=en&action=view_PUI&id_PUI=319
3. 1 CHANGELOG
Date Author Change Version
22/11/12 Tomas First version v1r1
2 INTRODUCTION
Page 3
4. The main objective of this document is the description of the MongoDB database monitoring
procedures on Linux-based systems. We have chosen a set of “base” modules based on our
experience in system monitoring and on the needs of some of our clients.
To extract the information we use:
• An external configuration file where all the plugin parameterization is defined.
• We use the software already installed in the system (mongo, mongostat, awk, grep, etc), for
the monitoring done by the plugin without having to install libraries or third party tools.
• The system is integrated with the Unix agent and with the capacity of distributing file
collections. That way it is posible to distribute the plugin on the one hand and the file
collections in an individual way-by agent-and/or by policies on the other hand.
3 COMPATIBILITY MATRIX
The compatibility matrix for MongoDB monitoring is:
Page 4
5. Systems where it has been tested • MongoDB v2.2.1
Systems where it should work • MongoDB v2.0.8 or above
4 DOCUMENTATION PROVIDED BY THE REQUESTING AREA
In order to get the MongoDB monitoring done correctly, it is necessary that the technical Area sends some
specific information that will be included in the configuration files. This information is the following:
Page 5
6. • Port where the MongoDB database is listening.
• Credentials needed to connect to the database, if any.
• MongoDB Config Server port.
• Name of the MongoDB database (case sensitive!).
• MongoDB instance listening IP.
5 MODULES PROVIDED BY MONGODB PLUGIN
This plugin returns 16 modules by instance. All of them generate status graphs. You should fix
thresholds manually to determine whether something is in a warning/critical operative.
• MongoDB_Inserts_$CFG_HOST:$CFG_PORT: DB Inserts per second for this
instance.
Page 6
7. • MongoDB_Queries_$CFG_HOST:$CFG_PORT: DB Queries per second for this
instance.
• MongoDB_Updates_$CFG_HOST:$CFG_PORT: DB Updates per second for this
instance.
• MongoDB_Deletes_$CFG_HOST:$CFG_PORT: DB Deletes per second for this
instance.
• MongoDB_Getmores_$CFG_HOST:$CFG_PORT: DB Getmores per second for this
instance.
• MongoDB_Commands_$CFG_HOST:$CFG_PORT: DB Commands per second for
this instance.
• MongoDB_Flushes_$CFG_HOST:$CFG_PORT: DB Fsync flushes per second for
this instance.
• MongoDB_PageFaults_$CFG_HOST:$CFG_PORT: DB Page faults per second for
this instance.
• MongoDB_IdxMiss_$CFG_HOST:$CFG_PORT: DB bttree page missed percentage
for this instance.
• MongoDB_ClientReadQueueLength_$CFG_HOST:$CFG_PORT: DB Client read
queue length for this instance.
• MongoDB_ClientWriteQueueLength_$CFG_HOST:$CFG_PORT: DB Client write
queue length for this instance.
• MongoDB_ActiveClientsReading_$CFG_HOST:$CFG_PORT: DB Active reading
clients for this instance.
• MongoDB_ActiveClientsWriting_$CFG_HOST:$CFG_PORT: DB Active writing
clients for this instance.
• MongoDB_NetworkTrafficInBits_$CFG_HOST:$CFG_PORT: DB Network traffic
in bits for this instance.
• MongoDB_NetworkTrafficOutBits_$CFG_HOST:$CFG_PORT: DB Network
traffic out bits for this instance.
• MongoDB_OpenConns_$CFG_HOST:$CFG_PORT: DB Open connections for this
instance.
6 REQUISITES
The MongoDB monitoring is done basically getting data through MongoDB system command
mongostat and through the execution of commands in the Operative System.
Page 7
8. The requisites to this monitoring could work correctly are the followings:
• To install the Pandora agent (>3.2.1)
• MongoDB instance configuration to accept connections using mongostat.
• Mongo bin folder (where mongostat resides) must be located in the user PATH.
6.1. Configuration of the MongoDB instance
In this section is explained how to deploy and start a MongoDB instance in a Linux-based server. If
you want to deploy multiple instances and monitor sharding controllers, please keep in mind that
this kind of MongoDB instance currently doesn't provide all the information mentioned above, but
a limited set of modules. The steps required to achieve this are simple: are the following: first find
the MongoDB daemon (mongod) and start up as many instances as you need, providing the
listening port, DB path and instance role as parameters:
• Instance startup sample: mongod --rest --dbpath /data/sharddb --shardsvr >&
/var/log/mongoshardsvr.log & (in this case the default port for shard svrs, 27018, is used)
The following document explains how to display and configure the MongoDB instance properly:
http://docs.mongodb.org/manual/administration/configuration/
However, the monitoring system will be able to work right after the instance startup, without
having to wait for additional configuration.
7 FILE CONFIGURATION
The plugin needs to be configured correctly, through an external configuration file in order to
monitor it properly.
NOTE: It is extremely important to consider that the configuration files thought for the plugin in
Page 8
9. UNIX should be edited and stored with carriage returns type “UNIX” and that if we use carriage
returns type “WINDOWS” the plugin will not work properly.
The configuration file has the following syntax, that we show as example:
mongodb_stats mongostat;check_dbstats;;localhost;27019
The configuration file could have one or several lines, so each line defines the following things:
• Primary operation to execute. (only mongodb_stats as of now)
• Tool used to perform that operation. (should be mongostat, since its location should be
added to the system PATH of the user that executes the agent, otherwise, the absolute path
should be needed as well)
• Operation execution mode. (only check_dbstats mode is supported right now)
• Whether the instance is a sharding controller or not (if it's not the case, leave it blank)
• IP where the MongoDB instance is listening.
• Port where the MongoDB instance is listening.
Each parameter is separated with the “;” character, as we have seen in the previous example.
Authentication support will become available in the next version.
8 INSTALLING
Copy the plugin to the agent plugin directory, or distribute it with file collections. Do the same with
the file conf. The call from the agent will be similar to this, but using the paths where the plugin
Page 9
10. and conf are.
module_plugin /var/opt/PandoraFMS/etc/pandora/plugins/Pandora_Plugin_MongoDB_v1r1.pl
/var/opt/PandoraFMS/etc/pandora/collections/fc_23/zbea-mongodb.conf
Note: the path of configuration file and plugin file could be what you want.
9 CONFIGURATION AND DEPLOYMENT
The use of these scripts with policies is easy. It is based on creating a policy that contains the
plugin (Pandora_Plugin_MongoDB_v1r1.pl) and a configuration file for each agent. So the call to
the policy plugin uses the $HOST and $PORT variables in that file in order to monitor the
instances needed for each server.
Page 10
11. If the machine is called ilp0x068.tsm.inet, then we should updload a file with the name:
ilp0x068.tsm.inet-mongodb.conf
And use this hostname as the HOST variable inside the configuration file.
The content of the .conf is specific for each system, but all the .conf are copied to all the systems
associated to the policy. However, even by providing a good credential set, only the user that
executes the pandora agent can read these .conf, so this user should also be able to execute the
system commands needed to monitor Mongo (mongostat in this case).
Page 11