Administration Overview

If you have administrative privileges for the Ops Manager deployment, click the Admin link in the top right corner of Ops Manager to access the system administration tool. This page describes the system administration interface. For configuration settings, see Ops Manager Configuration Settings.

General Tab

The General tab gives access to system topology, users, messages, and other information.

Overview Page

This page displays the Ops Manager network topology and provides reports on system use and activity.

Ops Manager Config Page

The General tab’s Ops Manager Config page lets you update your Ops Manager settings. For information on each field, see Ops Manager Configuration Settings.

Users Page

This page displays a list of user information for all people with permission to use the Ops Manager application as well as provides an interface to manage users. Use the search box on the upper right corner to find a user record. The Last Access column displays the date and time of the last access event.

To edit a user record:


Click the pencil icon at the far right of the user record.


Change any desired parameters in the Edit User interface.

Section Possible Values
Two Factor Authentication Change how the user can enable two factor authentication. You can either add or change their Mobile Number. You can also indicate if the user’s Google Authenticator has been configured.
Profile Info Change the user’s email address.
Projects and Roles Add or remove the user from one of the roles for each group in the Ops Manager Application.
Actions Disable a user’s ability to use Ops Manager. Lock Account prevents the user from logging into Ops Manager. Clear Two Factor Auth disables two factor authentication for the user.
Global Roles Add or remove the user from one of the roles that apply across all groups in the Ops Manager Application.

To save these changes, click Save.

To delete a user record:


Click the trash can icon at the far right of the user record.


Click Delete.

Projects Page

This page in the Admin interface lists groups, their creation dates, and their last pings from agents.

Task Procedure
To view a group’s details: Click the group name.
To delete a group: Click the group’s trash icon.
To edit a group’s tags:

Click the pencil icon in the Tags column.

A project can have up to 10 tags. Tags follow these rules:

  • Are case-sensitive
  • Can contain these characters:
    • A through Z
    • 0 through 9
    • . (period)
    • _ (underscore)
    • - (dash)
  • Are limited to 32 characters
To edit a group’s metric data retention policy:
  1. Click the group’s More link.
  2. On the line for Monitoring Data Retention, click Customize.
  3. Change the retention levels as desired. Increasing the retention period for a granularity level requires more storage on the Ops Manager Application Database. To learn more about monitoring data retention, see the default monitoring data retention values per day, hour, and minute.

Logs Page

This page lists backup logs by job and class with messages grouped and counted by last hour, 6 hours, and last 2 days. Click a count number to see all messages in the group.

Version Manifest Page

This page lists all released MongoDB versions. Ops Manager requires this list to run in local mode. See the Configure Deployment to Have Limited Internet Access tutorial for more information.

Messages Page

This page displays messages you have added to the Ops Manager interface. You can add a message to any page of the Ops Manager interface to notify users of information and events, such as impending maintenance windows. To add messages, see Add a Message to the Interface

Audits Page

This page displays all events tracked by Ops Manager. This includes the group events as well as internal and system events, which are not tracked at a group level.

MongoDB Usage Page

Enable MongoDB Usage UI and MongoDB Usage Data Collection

If MongoDB Usage UI is set to true, this page displays information about the MongoDB Usage collected via daily snapshots.

If this page contains no data, you can populate it with data with one of two methods:

Sections of the Page

This page has two parts: a usage summary and a table of MongoDB deployments.

Usage Summary

This card contains a section for each server type that your Ops Manager deployment between the dates selected.

Each server type section contains three headings:

Heading Description
RAM Used Greatest amount of RAM used on the date with the greatest use.
Total Nodes Count of nodes used on the date with the greatest use.
Date When this server type had its greatest use.

The date of greatest use depends on the server type:

Server Type Date of Greatest Use Measured
RAM Pool When the greatest amount of RAM was used for all hosts running that server type.
All other server types When the greatest number of all hosts of that server type were running.
Deployments Table

This table contains each server and describes the server type associated, as well as important information about the server’s processes and their deployments.


From this page, you can:

Determine Server Type Usage over Time

To review which server types were in use for your MongoDB Enterprise installations during a given time period:

  1. Select a start date from the From box.
  2. Select an end date from the To box.

The Usage Summary updates automatically with the applicable values. This usage summary covers all hosts, organizations, and projects.

Apply New Server Type to Multiple Hosts

To change the server type of multiple hosts at once:

  1. Check the box at the left the columns containing the hosts to which you wish to apply the new server type.
  2. Select the desired server type from the Apply a Server Type dropdown.

This action updates these hosts to have that server type for all existing and future usage snapshots. The new server type does not apply to the timeframe you specified using the date selectors.

Apply New Server Type to Specific Host

To change the server type of one host, use the dropdown in its row under the Server Type column.

This action updates this host to have that server type for all existing and future usage snapshots. The new server type does not apply to the timeframe you specified using the date selectors.

Download a Usage Report

To report on your MongoDB Enterprise usage:

  1. Click Download Report to generate a copy of this data.
  2. Attach this report to the MongoDB email displayed on the MongoDB Usage page.

Backup Tab

The Admin interface’s Backup tab provides information on Backup resources, including jobs, daemons, and blockstores. For an overview of Backup and Backup resources, see Backup Process.

Jobs Page

This page lets you manage Backup jobs and Backup resources for each group. The top part of the page displays Active Jobs and the bottom part displays Stopped Jobs. The following fields on the page have a yellow background if delayed:

  • Last Agent Conf, if older than 1 hour.
  • Last Oplog, if older than 1 hour before the Last Agent Conf.
  • Head Time, if older than 1 hour before Last Oplog.
  • Last Snapshot, if older than the snapshot interval multiplied by 1.5.

Manage Backup Jobs

From the Jobs page, you can do the following:

Task Procedure
Assign a group to particular set of Backup Daemons or blockstores. Click the group, select the daemons or blockstores, and select Save Changes.
View a job’s log. Click the name of the job and then click the Logs link. Contact MongoDB Support if you need help interpreting the error message.
View information about a job. Click the job. From the job’s page you can access logs, conf calls, and other information, and you can download diagnostics.
Move a job to a new Backup Daemon. Click the job. On the job’s page, click the Move head link, select the new head, and click the Move Head button.
Filter the page to display the jobs assigned to a particular daemon or blockstore. Click the name of the daemon or blockstore.
Toggle whether a job journals its head database.

Select or clear Journal Head to turn on or off journaling for your head database.


Changing this setting at the job level overrides the deployment-wide setting.

See mms.backup.journal.heads for how to enable or disable journaling for all head databases in your group.

Manage Backup Resources

From the Jobs page, you can assign backup resources to a particular group.

You can make these changes for existing backups, but only new backup jobs will follow the new rules. Making these changes does not affect existing deployments. For additional procedural information, see Move Jobs from a Lost Backup Daemon to another Backup Daemon.

Task Procedure
Assign a group to particular daemons, blockstores or oplog stores. Click the group to open the group’s assignment page; make the assignments; select Save Changes.
Assign a group to a labelled set of daemons, blockstores, and oplog stores.

First assign the label on the Admin page for each resource. See Daemons Page, Snapshot Storage Page, and Oplog Stores Page.

Then, on the Jobs page:

  1. Click the group name to open the group’s assignment page.

  2. In the Assignment Labels list box, click Select Labels.

  3. Select the label. Each selected label must exist on at least one daemon, one blockstore, and one oplog store. If you select multiple labels, the resource must meet all selected labels.

    Keep in mind that the resource must also meet any other selected criteria on this page. For example, for a daemon to match, it must also meet any selections you have made in the Backup Daemon field.

  4. Click Save Changes.

Job Timeline Page

This page displays a graphical representation of information found on other Admin pages, in particular the Jobs page. The Job Timeline page displays critical timestamps (head, last snapshot, next snapshot) and offers a way to assign a daemon to a given job.

Click the Auto refresh checkbox to update the list automatically every 10 seconds. Click the Refresh button to refresh data manually.

To view the backup job JSON, click the Show JSON link under the Project heading for any backup job. When the JSON displays, click the View raw runtime data link under the code to view the raw data. To hide the daemon JSON, click the Hide JSON link.

To move the job to a new Backup Daemon, click the Move head link under the Machine heading for a backup job. Select the location and click the Move head button to move the job to a new Backup Daemon. Ops Manager does not automatically move jobs between daemons.

Logs Page

This page lists backup logs by job and class with messages grouped and counted by last 2 hours, last day, and last 3 days. Click a count number to see all messages in the group.

Restores Page

This page displays the last 300 requested restores and their progress. To show all restores ever requested, click Show All.

Resource Usage Page

This page provides key size and throughput statistics on a per-job basis for all groups for which Backup is enabled. The page displays the size of the data set, how active it is, and how much space is being used on the snapshot store.

To export the information, click Export as CSV.

Grooms Page

This page lists active and recent groom jobs. Groom jobs remove unused blocks on blockstores and S3 Snapshot Stores to reclaim storage space. If no existing snapshots reference a given block, it is considered unused. Ops Manager grooms blockstores at least once a year and S3 snapshot stores at least every two weeks.

A groom job forces the backup process to:

  1. Write all new data to a new location,
  2. Copy all existing, needed data from the old location to the new one,
  3. Update references to maintain data relationships, and
  4. Drop the old database.

File Size Changes during Grooming

During grooming operations, you may notice that the file sizes of blockstores and S3 snapshot stores fluctuate, sometimes dramatically. This is normal during these operations.

You can manually direct Ops Manager to move blocks between blockstores through the Groom Priority Page.

You can also Configure Block Size in a Blockstore.

Groom Priority Page

This page displays a list of the status of all of the backup jobs and their blockstores. There are three types of jobs that run to maintain a blockstore:

Tracking jobs
Scheduled to run every three days unless a previously scheduled blockstore job has not finished in that time. Tracking jobs also are scheduled to run immediately after a groom job. Tracking jobs determine the current ratio of living to dead blocks in blockstores.
Groom jobs
Scheduled to run when the ratio of living to dead bytes drops below 0.45. To learn more about grooming, see Groom page
Integrity Check Jobs
Scheduled to run every seven days unless a previously scheduled blockstore job has not finished in that time. These checks make sure that the blockstore has no data integrity issues.

Each blockstore can run only one blockstore job (groom, track, or integrity check) at a time unless you change its Load Factor. The Load Factor sets how many jobs that a blockstore can run at the same time. It is set to 1 by default.

To learn how to change the Load Factor, see Edit a Blockstore.

Each row in this table lists a backup job. Its background color indicates if the state of its associated blockstore is accurate and current.

Color Blockstore Storage Usage Status
Blue Amount of blockstore storage usage is changing. Blockstore groom job is in progress.
Green Amount of blockstore storage usage is accurate. Blockstore has run a tracking job since last groom job ran.
Red Amount of blockstore storage usage is stale. Blockstore has run a groom job since its last tracking job ran.

Manual Blockstore Maintenance

From this page, you can also perform three kinds of blockstore maintenance manually:

Move Blocks to a Different Blockstore
To move a backup’s chunks to a different blockstore, select the destination blockstore in the backup’s Blockstore List column. You might want to do this if you add a new blockstore and would like to balance data.
Groom a Blockstore
To initiate a groom job, click Schedule in the Groom Action column for the blockstore replica set you want to groom. You should not need to manually schedule groom jobs. Ops Manager runs the jobs automatically.
Check Blockstore Integrity
To initiate an integrity check, click IntegCheck in the Integrity Action column for the blockstore replica set you want to check. The Integrity Schedule Result modal appears and displays the status of the blockstore.

Daemons Page

This page lists all active Backup Daemons and provides configuration options. Ops Manager automatically detects Backup Daemons and displays them here. You can reconfigure daemons from this page. Changes can take up to 5 minutes to take effect.

Click Pre-Configure New Daemon at the bottom of the page if you want to add a daemon but do not want it to take new jobs. Type the <machine>:<roothead path> in the text field above Pre-Configure New Daemon. Click the button to configure the new Backup Daemon.

For each daemon, the page lists the server name, configuration, head space used, head space free, the number of replica sets backed up, the percentage of time the Backup Daemon Service was busy, and job runtime counts by 1 minute, 10 minutes, 60 minutes, less than or equal to 180 minutes, and greater than 180 minutes.

The page includes the following fields and links to manage and configure daemons:

Field Description
Show Detailed JSON Displays the Backup Daemon JSON. When the JSON displays, the View raw runtime data link appears under the code, allowing you to view the raw data.
Move all heads

Moves all the Backup Daemon jobs that live on this daemon to a new daemon location.

  1. Click the link.
  2. Click the location.
  3. Click Move all heads.
Delete Daemon Deletes a Backup Daemon.
Assignment Allows the daemon to process more jobs. If the daemon’s disk fills, clear this so the host is not overloaded.
Backup Jobs Allows the daemon to process more backup jobs. Clear this when performing maintenance on a daemon’s host.
Resource Usage

Collects information on blockstore use (i.e., which snapshots still reference how many blocks). Ops Manager uses this information to generate the Resource Usage Page page and to prioritize garbage collection.


If this Ops Manager instance is running as a dedicated restore daemon host, you may want to clear this checkbox to ensure the fastest possible restore time.

Garbage Collection

Allows the daemon to schedule groom jobs to remove unused blocks and expired snapshots.


If this Ops Manager instance is running as a dedicated restore daemon host, you may want to clear this checkbox to ensure the fastest possible restore time.

Head Disk Type

Indicates whether the disk type is SSD or HDD. If you change a daemon to SSD, then only jobs with an oplog greater than 1GB/hour will go to this daemon unless no HDD daemon is available. Jobs with an oplog less than 1GB/hour can go to this daemon only if no HDD daemon is available.


If you run Ops Manager 2.0.3 or earlier, jobs with an oplog less than 1GB/hour cannot be bound to an to SSD-backed daemon.

Assignment Labels Creates one or more labels that can be used to assign the daemon to a specific group.
Number of Workers

Number of concurrent backup tasks processed at a time.

To query a snapshot of a sharded cluster, the Backup Daemon requires at least one worker for the config server, one worker for each shard, and one worker for each mongos instance.

To query a snapshot of a replica set, the Backup Daemon requires at least one worker for the replica set.


If you restore a queryable backup from a 3-shard cluster with 1 shard router (mongos), you would need this value to be at least 5:

  • 1 per shard (3) +
  • 1 for the config server (1) +
  • 1 for the mongos

When the queryable backup begins, the Backup Daemon spins up 5 or more workers to manage these components.

Snapshot Storage Page

MongoDB database backups called snapshots and they are stored in containers called snapshot stores. This page lists existing snapshot stores and allows you to create or modify snapshot stores.

Ops Manager supports the following snapshot stores:

  • On a File System,
  • In a MongoDB database (blockstore), or
  • In an S3 Bucket (S3 blockstore)
Storage Method Name Description
File System File System Store Snapshots are stored in a directory on a file system. Each snapshot is found in its own sub-directory. The snapshot files can be compressed individually based upon its setting:: File System Store Gzip Compression Level. To create or edit a file system store, see Manage File System Snapshot Storage.
Database Storage Blockstore Snapshots are stored in a managed MongoDB database in a compressed, de-duplicated format. Depending on data usage patterns the deduplication can provide significant storage savings without the need for any specialized hardware or other software. To create or edit a blockstore, see Manage Blockstore Snapshot Storage
AWS S3 Bucket S3 Blockstore Snapshot data is stored as blocks in an AWS S3 bucket. Snapshot metadata is stored in a managed MongoDB database. The metadata database tracks which blocks comprise each snapshot. The blocks are compressed and de-duplicated. To create or edit an S3 blockstore, see Manage S3 Blockstore Snapshot Storage

You can add, edit or delete any snapshot store listed.

Additional Information

For additional information on managing snapshots, see:

Oplog Stores Page

This page configures the backing replica sets that store oplog slices. Oplog slices are compressed batches of the entries in the tailed oplogs of your backed-up deployments.


Do not modify the oplog store’s connection string to point to a different replica set. Existing data will not be copied and a resync will be required.

From this page you can:

  • Add a member to a replica set by adding the host to the replica set connection string in the <hostname>:<port> field. Do not modify the connection string to point to a different replica set.
  • Change the authentication credentials or connection options for a oplog store by modifying the appropriate fields.
  • Add an additional oplog store by clicking the Add New Oplog Store button at the bottom of the page.
  • Enable and disable new assignments to oplog stores using the checkboxes in the Assignment Enabled column.
  • Assign labels that can be used to assign the oplog store to a specific group. Enter labels in Assignment Labels. Separate multiple labels with commas.

After saving changes to the oplog store’s values, you must restart all the Ops Manager instances, including those running activated Backup Daemons, for the changes to take effect.

Alerts Tab

The Admin interface’s Alerts tab sets and displays global and system alerts. Global alerts apply a group-level alert condition to multiple groups. System alerts monitor the health of Ops Manager.

Control Panel Tab

Message History Page

This page displays alert messages sent and the recipients. To filter the list, click Filter by Recipient.

Send Test Message

Use this page to send messages to users to test validity of their addresses.

Server Pool

This page allows for the administration of the server pool.

Server Pools deprecated as of Ops Manager 4.0

As of Ops Manager 4.0, server pools are deprecated and disabled by default.


The Servers tab allows Administators to view information regarding servers in the pool, such as availability, as well as cancel pending requests and recycle servers that have been terminated but not returned to the pool. The Servers tab provides three views:

View Description
Server List

Lists servers in the pool and their availability (i.e. whether they are bound to a specific Ops Manager group or unbound). From this list, Administrators can terminate unbound servers.

For servers bound to a group, owners of the group can terminate the servers from their Deployment view.

Pending Requests Lists the pending requests. Administrator can cancel pending requests from this view.
Recycle Bin

Lists terminated servers that have not been returned to the pool. From this view, Administrator can recycle terminated servers to return them to the pool.

If the list of terminated servers exceed the list displayed on the current page, Recycle All recycles all terminated servers in the recycle bin, not just the servers displayed on the current page.

Servers Request Options

The Servers Request Options tab allows Administrators to control which server options are displayed to the users when users make a server request. These options are the properties and values specified in the serverPoolPropertiesFile file.

Agent Configuration

The Agent Configuration tab displays the serverPoolKey needed to configure the Automation for a server to be added to the server pool.