Monitor MongoDB with Uptime Cloud Monitor

Are you using MongoDB? If so, you can use IDERA Uptime Cloud Monitor (UCM) to monitor your MongoDB for availability and performance.

Prerequisites

Uptime Cloud Monitor from IDERA offers a SAAS based out-of-the-box solution for monitoring a MongoDB instance for availability and performance. If you are not familiar with the concept of custom metrics as used in Uptime Cloud Monitor, please go through Custom Metrics information once before continuing with this document. 

  1. Uptime Cloud Monitor account.  If you don’t already have an account, you can sign up for a 14 day FREE TRIAL of Uptime Cloud Monitor here (no Credit Card required).
  2. MongoDB up and running in your environment.
  3. Root access to server to install the MongoDB agent.

Monitor MongoDB using out-of-the-box custom metrics installer from Uptime Cloud Monitor

There are three steps that you need to do to start monitoring a MongoDB service:

  1. MongoDB Agent Installation
  2. Verify that your MongoDB Dashboard is up and running
  3. Configure alerts to be notified about MongoDB performance issues 

1. MongoDB Agent Installation

 

Figure 1: In your Uptime Cloud Monitor Account, navigate to Custom>Getting Started

Login to your Uptime Cloud Monitor account and navigate to Custom tab -> Getting Started. Click on MongoDB icon.  

Figure 2: The MongoDB agent installation script

Click on  icon to copy the installer script to your clipboard. Paste the command into the terminal window on the server where you want to install the agent.  Script can be run on the server running MongoDB, or it can be a different server, but this server will need to be continually running in order to monitor MongoDB.

As soon as the script is run on a terminal with root access, it starts downloading the required MongoDB monitoring agent on your server. You will need to configure the following items in the agent installation process. Item specified in square brackets ( [ ] ) are the default.

Figure 3: Executing the MongoDB agent installation script with user as copperegg, Group as copperegg and monitoring frequency as 60 seconds

  1. User and Group for running service as default values: [copperegg][copperegg]
  2. Monitoring frequency: 15, [60], 300, 900, 3600 seconds

Figure 4: Executing the MongoDB agent installation script with group name as “MongoDB_admin” and “MongoDB”, group label as “MongoDB-Admin Metrics” and “MongoDB metrics”,  Dashboard  as “MongoDB-Admin” and “MongoDB”

  3. Group label, group name and dashboard name for custom metrics [MongoDB_admin][MongoDB-Admin Metrics][MongoDB-Admin][MongoDB][MongoDB Metrics][MongoDB]

 

Figure 5: Executing the MongoDB agent installation script with unique id , server URL and port. Only one MongoDB server is added for monitoring.

      4.  Unique name for this db server. [<user>-MongoDB]
      5.  Server details : URL and Port for service. [localhost][27017]
      6.  Database name: [test]
      7.  Username and Password are optional
      8.  After configuring one node, you’ll get an option to add more MongoDB databases and servers.

 

Figure 6: Executing the MongoDB agent installation script with an upstart init file and the default value for log file name. The installation completes successfully!

      9.  Configure log file name and upstart job name (defaults present) [/usr/local/copperegg/log/MongoDB_metrics.log][/etc/init/revealmetrics_MongoDB.conf]

2. Verify that your MongoDB Dashboard is up and running

Navigate to Dashboard and you will see a new MongoDB-Admin and MongoDB Dashboards have been added automatically by the installer.

 

Figure 7: A new Dashboard for MongoDB and MongoDB-Admin has been added

As the installed script executes, you will notice data samples appearing on the widgets for this Dashboard.

 

Figure 8: Widget inside MongoDB-Admin Dashboard displaying uptime. The uptime value gradually increases over time as the MongoDB service continues to remain operational.

Figure 9: Widget inside MongoDB-Admin Dashboard displaying count of current connections.

 

Figure 10: Widget inside MongoDB-Admin Dashboard displaying count of Page Faults.

Monitored metrics

Uptime Cloud Monitor currently monitors 52 metrics which cover most of the important metrics for MongoDB-Admin from a performance and stability perspective. You can see these 52 metrics by navigating to the Custom Tab > Custom Objects and selecting Details on the Custom Metrics Group Label [MongoDB-Admin Metrics] that was given as installation input.

The metrics are:

  • asserts_regular : Regular Asserts Raised
  • asserts_warning : Warning Asserts (alert automatically created)
  • asserts_msg : Assert Messages
  • asserts_user : User Asserts
  • asserts_rollover : Asserts Rollover
  • connections_available : Connections Available
  • connections_current : Current Connections (alert automatically created)
  • page_faults : Page Faults (alert automatically created)
  • op_inserts : Insert Operations
  • op_queries : Queries
  • op_updates : Update Operations
  • op_deletes : Delete Operations
  • op_getmores : Getmore Operations
  • op_commands : Commands
  • repl_inserts : Replicated Insert Operations  
  • repl_queries : Replicated Queries  
  • repl_updates : Replicated Update Operations  
  • repl_deletes : Replicated Delete Operations  
  • repl_getmores : Replicated Getmore Operations
  • repl_commands : Replicated Commands  
  • uptime : Uptime  
  • cursors_total_open : Open Cursors  
  • cursors_timedout : Timed Out Cursors
  • document_inserted : Documents Inserted
  • document_deleted : Documents Deleted
  • document_updated : Documents Updated
  • document_returned : Documents Returned
  • op_fastmod : Fastmode Update Operations
  • op_idhack : Id Hack Queries
  • op_scan_and_order : Scan and Order Queries
  • get_last_error_write_timeouts : getLastError Write Timeouts
  • get_last_error_write_concerns : getLastError Write Concerns
  • ttl_deleted_documents : Documents Deleted from Collections with a ttl index per second
  • ttl_passes : ttl Indexes Passes
  • batch_applied_num : Batches Applied Number
  • batch_time_spent : Time Spent on applying operations from Oplog
  • mem_resident : Resident Memory (alert automatically created)
  • mem_virtual : Virtual Memory
  • mem_mapped : Mapped Memory
  • global_lock_total_time : Global Lock Total Time
  • current_queue_lock : Current Lock Queue
  • current_queue_read_lock : Current Read Lock Queue
  • current_queue_write_lock : Current Write Lock Queue
  • index_item_scan_per_query : Index Items Scanned During Query
  • records_moved : Records Moved
  • max_buffer_size : Max Buffer Size
  • oplog_operations : Oplog Operations
  • oplog_buffer_size : Oplog Buffer Size
  • oplog_qry_proc_create_ps : Oplog Queries Processes
  • repl_sync_src_data_read : Replication Sync Source Data Read
  • op_read_from_repl_src : Operations Reads from Replication Source
  • getmores_op : getMore Operations

Uptime Cloud Monitor also monitors 5 metrics which cover most of the important metrics for MongoDB databases from a performance and stability perspective. You can see these 5 metrics by navigating to the Custom Tab > Custom Objects and selecting Details on the Custom Metrics Group Label [MongoDB Metrics] that was given as installation input.

The metrics are:

  • db_objects : DB Objects
  • db_indexes : DB Index
  • db_datasize : DB Data Size
  • db_storage_size : DB Storage Size
  • db_index_size : DB Index Size

For some of these metrics, alerts have been automatically created (see section 3 below). To create new alerts see section: Configuring your own Alerts for MongoDB.

3. Configure Alerts to be notified about MongoDB performance issues

Default Pre-Configured Alerts for MongoDB

As soon as your MongoDB Monitoring Dashboard comes up, you will notice that some alert configurations have been automatically created by our Installation Script (under Alerts > Configure Alerts). These pre-configured alerts for MongoDB include:

Sr. No.

Metric Name

Definition

Alert Definitions

Duration

1

Connections Current

Number of connections to the database server from clients

Alert will be triggered when connections reach 800000.

3 Min

2

Mem Resident

Amount of memory currently used by the database process

  1. Warning Alert will be triggered when size becomes 60% of memory.
  2. Alert will be triggered when size exceeds 70% of memory.

3 Min

3

Page Faults

Number of page faults per second that require disk operations

Alert will be triggered for every page fault.

3 Min

4

Asserts Warnings

Number of warnings raised per second

Warning Alert for each assert warning.

3 Min

 

If the alerting condition is met for these pre-configured alerts, some alert notifications may also be triggered.

Configuring your own Alerts for MongoDB

Figure 11: A new alert being added that will be triggered when MongoDB data size metric exceeds a threshold of 2000 within a time period of 1 min

Alerts can also be configured against any of these 57 monitored metrics for MongoDB.

You can configure new alerts that will be triggered when performance issues with MongoDB arise. You can also configure the notification mechanisms for a triggered alert.

  1. Go to Alerts Tab > Configure alerts and click on “New Alerts” button
  2. Provide values for these fields in the New Alert page:

 

  • Description: A description of the alert that will be easily recognized by you and your team if the alert is triggered

 

  • Alert me when: Select the metric of interest and the condition upon which the alert is triggered. In the Alert me when dropdown, you can prefill “Custom: <your MongoDB Metric Group>” to get only the list of monitored metrics for your specific MongoDB installation. From this list, you can then select the specific metric for which you want to configure an alert. As an illustration, in Figure 11, the chosen metric of interest in ‘Alert me when’ is ‘Custom: MongoDB Metrics: Data Size’ from the MongoDB Metrics group and the condition for triggering the alert is if the average value is more than 2000.
  • For at least: The duration for which the alert condition must be valid for the alert to be triggered
  • Matching tags: By default, (match everything) is chosen. If needed, you can attach tags to a particular metric object and select those tags here, which would cause only alerts on that metric object to be triggered.
  • Excluding tags: By default, (exclude nothing) is chosen. If needed, you can attach tags to a particular metric object and select those tags here, which would cause alerts on that metric object to be skipped.
  • Annotate: When enabled, an annotation is automatically created when the alert is triggered. Annotations will be visible in the custom metrics dashboard where the data stream is displayed.
  • Automatic Clear: When enabled, the alert issue is automatically cleared if the triggering condition is no longer true
  • Notify on clear: When enabled, notifications are also sent when the alert issue is cleared. Please do note that notifications are always sent when the alert issue is triggered.
  • Send Notifications To: Here you can configure the notification mechanisms by which the alert is communicated to you and others in your team.

Notification mechanisms include:

  • Email
  • SMS
  • PagerDuty
  • Twitter
  • HipChat
  • Campfire
  • Slack
  • OpsGenie

Webhooks are also exposed for clients to configure custom notification mechanisms.  More about setting up website probe alerts can be found here.

 

Uptime Cloud Monitor Free Trial! Sign up today!

Sign up for a 14 day FREE TRIAL of Uptime Cloud Monitor (no Credit Card required).

You can find more information about Uptime Cloud Monitor pricing options here.

We charge only $0.08 per month per metric!

Sign up today!