MongoDB Ops Manager

MongoDB Ops Manager is a service for managing, monitoring and backing up a MongoDB infrastructure. In addition, Ops Manager allows Administrators to maintain a server pool to facilitate the deployment of MongoDB. Ops Manager provides the services described below.mongoOpsManager
Ops Manager Monitoring provides real-time reporting, visualization, and alerting on key database and hardware indicators. How it Works: A lightweight Monitoring Agent runs within your infrastructure and collects statistics from the nodes in your MongoDB deployment. The agent transmits database statistics back to Ops Manager to provide real-time reporting. You can set alerts on indicators you choose.
Ops Manager Automation provides an interface for configuring MongoDB nodes and clusters and for upgrading your MongoDB deployment.
Ops Manager Backup provides scheduled snapshots and point-in-time recovery of your MongoDB replica sets and sharded clusters.

Automation Agents on each MongoDB host maintain your deployments. You can install the Automation Agent so it can provision hosts and deploy clusters in your MongoDB infrastructure.

The Automation Agent also maintains the Monitoring and Backup Agents and starts, restarts, and upgrades the agents as needed.

Automation allows only one Monitoring or Backup Agent per host. It removes additional agents.

Ops Manager Architecture



Open Ops Manager’s default ports and health-check endpoints refer the link below

Ops Manager Application

The Ops Manager Application provides the user interface and the HTTP services the Agents use to transmit data to and from Ops Manager. These are all stateless and start automatically when the Ops Manager Application starts. Multiple instances of the Ops Manager Application can run if each instance uses the same configuration and application database. Users and agents can interact with any instance.
By default, the Ops Manager Application runs on port 8080 and contains the web interface for managing Ops Manager users, monitoring of MongoDB hosts, and managing host backups.

Backup Daemon Service

We can configure any Ops Manager instance to run the Backup Daemon service to back up MongoDB databases. The Backup Daemon service manages the local copies of the backed-up databases and snapshots for each database. The daemon does scheduled work based on data coming into the Ops Manager from its Backup Agents. No client applications can talk directly to the daemon. Its state and job queues come from the Ops Manager Application Database. The local backup copy of a deployment is called the head database. The Backup Daemon stores all its head databases in its head directory path. To create each head database, the daemon’s host acts as an “invisible” secondary for each replica set designated for backup.

The daemon takes scheduled snapshots and stores these snapshots in a snapshot store. The daemon retrieves data from the snapshot store when it receives a restore request. It then delivers the snapshot to the requested destination.

Ops Manager uses a dedicated MongoDB database to store the Ops Manager’s operational data. The application database runs as a replica set to ensure redundancy and high availability. This replica set hosts only Ops Manager data. Before installing Ops Manager, you must provision the application database. This database contains Ops Manager Application metadata:

  • Monitoring data collected from Monitoring Agents.
  • Metadata for Ops Manager users, projects, hosts, monitoring data, and backup state.

Deployment Architecture

For best performance on any of these installs, configure each backup host with two disk partitions: one for the snapshot store or File System Store and one for the head databases.

This deployment provides redundancy for the Ops Manager Application Database and Snapshot Storage in the event of host failure. The deployment runs the database in a MongoDB replica set with three data-bearing members with copies of the data.


Hardware Requirements

If we want to serve both the Ops Manager application and a Backup Daemon on one host. This Ops Manager configuration will manage and monitor 300 MongoDB hosts and back up 200 hosts. The total disk capacity of all databases being backed up is 4 TB. The total requirements would be:

  • Ops Manager application needs 15 GB of RAM.
  • The Backup Daemon also needs:
    15 GB of RAM and
    2.5 times the 4 TB of backed up databases in disk capacity.
    This example host would require a minimum of 30 GB of RAM and 10 TB of disk capacity.


Software Requirements

Ulimits Requirements for Ops Manager Application

RHEL and CentOS 6 limit the maximum number of user processes to 1024. This overrides the general user process limit (ulimit -u) setting.

For the userid that runs Ops Manager (mongodb-mms by default), add soft and hard nproc (number of processes) entries to the /etc/security/limits.d/99-mongodb-nproc.conf user process configuration file. Use values that are larger than the RHEL 1024 user process limit.

mongodb-mms soft nproc 200000
mongodb-mms hard nproc 500000

Provision an Ops Manager host

System Memory  : 15 GB
Disk Capacity  : 50 GB in /
Host OS Permissions  : root

Install the Ops Manager Application Database and Backup Database

These databases run on dedicated MongoDB replica sets. If you use multiple backup databases, you must configure one replica set for each backup database. The replica set for each database must be dedicated to that database only and must store no other data.

The backing databases must run on independent replica sets on independent storage volumes. Running regular backups, a backup database could fill a volume. If the application database cannot write to a volume, Ops Manager stops. Proper storage setup reduces the risk of Ops Manager failures.

To configure the replicaset instance click here 

Replica Set Security

  • Secure the Connection to the Backing Databases
  • Configure these databases to accept connections from Ops Manager that only use SSL.
  • Configure an Authentication Mechanism for the Backing Databases
  • Configure the Ops Manager User that Accesses the Backing Databases with Only needed roles

Configure yum to install MongoDB

OS used in this example is Amazon Linux AMI

Create a  /etc/yum.repos.d/mongodb-org-4.0.repo file

name=MongoDB Repository

Install MongoDB packages

sudo yum install -y mongodb-org

Create the Ops Manager Application Database directory

sudo mkdir -p /data/appdb
sudo chown -R mongod:mongod /data

Create the Ops Manager backup data directory

sudo mkdir -p /data/backup
sudo chown mongod:mongod /data/backup

Start the Ops Manager Application Database mongod instance.

sudo -u mongod mongod --port 27017 --dbpath /data/appdb \
  --logpath /data/appdb/mongodb.log \
  --wiredTigerCacheSizeGB 1 --fork

Note : For high availability configure replicaset for application and backup database instance.

Download the Ops Manager package.

  • Download the Ops Manager rpm package from MongoDB Download Center 
  • From the Platforms drop-down menu, click Red Hat + CentOS 6, 7 / SUSE 12 / Amazon Linux.
  • From the Packages drop-down menu, click RPM and click Download


Download the latest stable release from link below

Install Ops Manager

Install the .rpm package by issuing the following command

sudo rpm -ivh mongodb-mms-

The install creates the following:

  • The base directory for the Ops Manager software, which is:


  • A new system user, mongodb-mms, under which the host runs.

  • The /opt/mongodb/mms/conf/ file, which contains the connection string to access the Application Database. The default is locahost, port 27017, so no changes are necessary.

Configure the Ops Manager connection to the Ops Manager Application Database.

On a server that is to run the Ops Manager, open /opt/mongodb/mms/conf/ with root privileges and configure the settings described here, as appropriate.

Configure the following setting to provide the connection string Ops Manager uses to connect to the database:

  • mongo.mongoUri

If you will configure Ops Manager to use the Ops Manager Application Database over SSL, configure the following SSL settings.

  • mongo.ssl
  • mongodb.ssl.CAFile
  • mongodb.ssl.PEMKeyFile
  • mongodb.ssl.PEMKeyFilePassword

Ops Manager also uses these settings for SSL connections to Backup Databases

If you will configure Ops Manager to use Kerberos to manage access to the Ops Manager Application Database, configure the following Kerberos settings:

  • mms.kerberos.principal
  • mms.kerberos.keyTab

Start Ops Manager

sudo service mongodb-mms start

Open the Ops Manager home page and register the first user

Enter the following URL in a browser, where <host> is the fully qualified domain name of the server:


If you are using an EC2 instance, the hostname is the Public DNS listed on the EC2 instance’s Description tab.

Click the Register link and follow the prompts to register the first user and create the first project. The first user is automatically assigned the Global Owner role.

Copy the gen.key file from the current server to the other servers

Ops Manager requires an identical gen.key file be stored on both servers running Ops Manager and uses the file to encrypt data at rest in the Ops Manager Application Database and Backup Database.

You must copy the gen.key file from the current server, on which you just installed Ops Manager, to every server that will run Ops Manager. You must copy the gen.key to the other servers before starting Ops Manager on them.

Use scp to copy the gen.key file from the /etc/mongodb-mms/ directory on the current server to the same directory on the other servers.


Access to the OPS Manager application


Register the first user


Once your account have been created, configure the OPS Manager access URL.


Then configure your email settings.


Click on Continue and configure the User Authentication, Backup Snapshots, Proxy.

Finish by the OPS Manager versions configuration.


Please find the ops manager application configuration settings in link below


Ops Manager Deployment


  • At least 10 GB of free disk space plus whatever space is necessary to hold your MongoDB data.
  • At least 4 GB of RAM.
  • If you use Amazon Web Services (AWS) EC2 instances, we recommend at least an m3.medium instance.
  • The Automation Agent must be installed only on 64-bit architectures.

Install the following binaries

yum install cyrus-sasl cyrus-sasl-gssapi cyrus-sasl-plain krb5-libs \
  libcurl libpcap lm_sensors-libs net-snmp net-snmp-agent-libs \
  openldap openssl rpm-libs tcp_wrappers-libs

Ops Manager can automate operations for the MongoDB processes running on your servers. Ops Manager can both discover existing processes and deploy new ones.

Ops Manager Automation relies on an Automation Agent, which must be installed on every server that runs a monitored MongoDB deployment. The Automation Agents periodically poll Ops Manager to determine the goal configuration, deploy changes as needed, and report deployment status back to Ops Manager.

  • In Ops Manager, click Deployment, then the Agents tab, then Downloads & Settings.
  • Under Automation, click your operating system and follow the instructions to install and run the agent.

Add Existing MongoDB Processes to Ops Manager

Add MongoDB Processes

Click Deployment.

Click Add New and select Existing MongoDB Deployment.

Follow the prompts to add the deployment.



To change a replicaset version we need to click on maintenance icon


select the new version and click apply





Performance and Monitoring



Ops Manager sends an alert notification when a specified alert condition occurs, such as an unresponsive host or an outdated agent. To view all alert notifications, click Alerts in Ops Manager.

When a condition triggers an alert, you receive the alert at regular intervals until the alert resolves or Ops Manager cancels it. You can acknowledge an alert for a period of time, but if the alert condition persists, you will again receive notifications once the acknowledgment period ends.


Manage alert configuration


Configure the backup capabilities

On each Ops Manager server that you activate as a Backup Daemon, create the directory in which to store the head databases. The directory must be:

  • Dedicated for this purpose on a local disk partition.
  • Sized appropriately according to the Ops Manager System Requirements.
  • Writable by the mongodb-mms user.
mkdir /data/backupDaemon
sudo chown mongodb-mms:mongodb-mms /data/backupDaemon
sudo sudo chmod 774 -R /data/backupDaemon
  1. In Ops Manager, while logged in as the user you registered during installation, click the Admin link at the top right of the page.
  2. Click the Backup tab.
  3. Follow the prompts to configure the Backup storage. Ops Manager walks you through the configuration.
  4. For snapshot storage, select either the local filesystem or the backup database. If you use a File System Store, you still need a small MongoDB database for oplog storage. At the prompt to configure the connection string to the backup database, enter your local hostname and port:

Ops Manager automatically prefixes connection strings with mongodb://. Your connection string should match the following:


Online Backups – PITR Restore

Ops Manager backups, once started, are an ongoing and continuous process. Data is continually backed up as long as the backup remains synchronized with the database.





Centralized Authentication /RBAC Management


Add a custom role



Alert Logs

Ops Manager collects log information for both MongoDB processes and its agents. For MongoDB processes, you can access both real-time logs and on-disk logs.The MongoDB logs provide the diagnostic logging information for your mongod and mongos processes.



Reference :

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Powered by

Up ↑

%d bloggers like this: