Frequently Asked Questions

This document addresses common questions about Ops Manager and its use.

Monitoring FAQs

Host Configuration

How do I add a new host or server?

See Add Existing MongoDB Processes to Monitoring.

Can Ops Manager monitor itself?

Yes. You can use Ops Manager to monitor the backing MongoDB replica sets that hold data for the Ops Manager Application and Backup Daemon.

You cannot, however, use Ops Manager to backup or automate the backing replica sets.

Can I monitor Kerberos-enabled instances?

Yes. Monitoring does support monitoring for Kerberos-enabled MongoDB instances. See Configure the Monitoring Agent for Kerberos for more information.

How does Ops Manager gather database statistics?

In most instances, Monitoring will scale its request cycle to limit more expensive statistics gathering. The DB Stats information updates every 10 minutes, and the agent will throttle the frequency to reduce the impact on the database. [1] Even so, the “DB stats” operation impacts the performance of your database, as is possible when installations have a large number of databases and collections.

If the collection of database statistics impacts database performance, disable database stats collection before starting your agent. Select the Administration tab, then the Group Settings page, and then set Collect Database Specific Statistics to NO.

[1]	DB Stats will not appear until 30 minutes after you add the host to Monitoring

Monitoring Agent

Do I need a Monitoring Agent for every MongoDB Instance?

No. A single Monitoring Agent can connect to all MongoDB databases in your Ops Manager group. Unless you have multiple groups, complete your initial Monitoring Agent setup with a single agent.

For redundancy, you may wish to run a second Monitoring Agent. See the Monitoring Agent Redundancy for more information.

Can I use two Monitoring Agents to connect MongoDBs in different data centers?

No, not within the same group. The group’s Monitoring Agent must connect to every server in the MongoDB deployment. Configure firewalls to allow the Monitoring Agent to connect across data centers and servers.

Use multiple Monitoring Agents within a single Ops Manager group only to provide redundancy. For each Ops Manager group, the agent must be able to connect to every monitored MongoDB. Unless you have multiple groups, complete your initial Monitoring Agent setup with a single agent.

What happens if a Monitoring Agent becomes unavailable? How can I ensure my MongoDBs are always monitored?

You can run multiple Monitoring Agents. If one Monitoring Agent fails, another starts monitoring. As long as at least one Monitoring Agent is available, Ops Manager will not trigger a Monitoring Agent Down alert. To run multiple Monitoring Agents, see Monitoring Agent Redundancy.

You also can create an alert to notify you when an agent is down. In Ops Manager, click the Activity tab and then Alert Settings. Click the Add Alert button then set the alert through the fields in the Create a New Alert window.

Where should I run the Monitoring Agent?

The amount of resources the Monitoring Agent requires varies depending on infrastructure size, the number of servers and the databases it’s monitoring. Run the agent on an existing machine with additional capacity that does not run a mongod instance. You may also run the Monitoring Agent on a smaller dedicated instance.

The Monitoring Agent load scales with the number of monitored mongod plus mongos processes and the number of databases in your MongoDB environment.

Never install the Monitoring Agent on the same server as a data bearing mongod instance. This will allow you to perform maintenance on a the mongod and its host without affecting the monitoring for your deployment. Additionally a Monitoring Agent may contend for resources with the mongod

You can install the Monitoring Agent on the same system as an arbiter, a mongos, or an application server depending on the requirements of these services and available resources.

Can I run the Monitoring Agent on an AWS micro server?

If you monitor five or fewer mongod instances, you can use a AWS micro server.

Why can’t the Monitoring Agent connect to my host?

The most common problem is that the agent is unable to resolve the hostname of the server. Check DNS and the /etc/hosts file.

The second most common problem is that there are firewall rules in place that prohibit access to the server from the agent.

To test the connection, login to the server running the agent and run: mongo hostname:port/test If you are unable to connect, the agent will not be able to connect.

In addition, Monitoring supports monitoring for Kerberos-enabled instances.

Why does the Monitoring Agent connect with hostnames instead of IP addresses?

By default, the Monitoring Agent tries to connect by resolving hostnames. If the agent cannot connect by resolving a hostname, you can force the Monitoring Agent to prefer an IP address over its corresponding hostname for a specific IP address.

To create a preferred hostname, select the Administration tab, then the Group Settings page, and then click the Add button for the Preferred Hostnames setting. If your IP addresses have a common prefix, create a preferred hostname with the ends-with button or click the regexp button to use a regular expression.

Preferred hostnames also allow you to specify the hostname to use for servers with multiple aliases. This prevents servers from appearing multiple times under different names in the Ops Manager interface.

How do I download the Monitoring Agent?

You can update the Monitoring Agent from the Agents page on the Ops Manager Administration tab.

How do I setup and configure the agent?

See the README file included in the agent download.

How do I delete a Monitoring Agent from Ops Manager?

Monitoring Agents report their status to the Ops Manager. When an agent does not report for more than 24 hours, the agent no longer appears in Ops Manager.

For more details, see Remove Monitoring Agents from Ops Manager.

Can I run the Ops Manager Monitoring Agent with Ops Manager Backup?

Yes. Both the Ops Manager Monitoring Service and Ops Manager Backup can operate in the same environment. You will need to install and configure two separate Monitoring Agents: configure one agent for the Ops Manager environment and the other for the Ops Manager Service.

Data Presentation

What are all those vertical bars in my charts?

A red bar indicates a server restart.

A orange bar indicates the server is now a primary.

A brown bar indicates the server is now a secondary.

Why is my Monitoring Agent highlighted in red?

Your agent is out of date.

You can update the Monitoring Agent from the Agents page on the Ops Manager Administration tab.

Data Retention

What is the data retention policy for Ops Manager?

Ops Manager retains two distinct types of data: metrics, which describe usage; and snapshots, which back up your data.

Data-retention policies, as defined in the Terms of Service, are always subject to change.

As of this writing, Ops Manager preserves:

• Minute-level metrics for 48 hours.
• Hourly metrics for 94 days.
• Snapshots according to their retention policy.

Backup FAQs

Ops Manager Backup creates backups of MongoDB replica sets and sharded clusters. After an initial sync to MongoDB’s datacenters, Ops Manager Backup tails the operation log (oplog) to provide a continuous backup with point-in-time recovery of replica sets and consistent snapshots of sharded clusters. For more information, please review these frequently asked questions or create an Ops Manager Backup account.

Requirements

What version of MongoDB does Backup require?

To back up a sharded cluster, Backup requires version 2.4.3 or later.

To back up a replica set, Backup requires version 2.2 or later.

Are there any limits to the types of deployments Backup supports?

Yes. Backup does not currently support standalone deployments. Backup has full support for replica sets and sharded clusters.

Why doesn’t Backup support standalone deployments?

After an initial sync of your data to Ops Manager, Backup copies data from the oplog to provide a continuous backup with point-in-time recovery. Backup does not support standalone servers, which do not have an oplog. To support backup with a single mongod instance, you can run a one-member replica set.

See also

Convert a Standalone to a Replica Set.

How Does Ops Manager Measure Data Size?

Ops Manager uses the following conversions to measure snapshot size and to measure how much oplog data has been processed:

• 1 MB = 1024² bytes
• 1 GB = 1024³ bytes
• 1 TB = 1024⁴ bytes

Interface

How can I verify that I’m running the latest version of the Backup Agent?

If your Backup Agent is out of date, it will be highlighted in red on the Agents page of the Administration tab.

Why is my Backup Agent highlighted in red?

If your agent is highlighted in red on the Agents page of the Administration tab, your agent is out of date. For instructions on updating the agent, see Install Backup Agent.

Operations

How does Backup work?

You install the Backup Agent on a server in the same deployment with your MongoDB infrastructure. The agent conducts an initial sync of your data to Ops Manager. After the initial sync, the agent tails the oplog to provide a continuous backup of your deployment.

Where should I run the Backup Agent?

The Backup Agent can run anywhere in your infrastructure that has access to your mongod instances. To avoid contention for network and CPU resources, do not run the Backup Agent on the same hosts that provide your mongod instances.

The Backup Agent has the same performance profile impact as a secondary. For the initial backup, the load scales with the size of your data set. Once an initial backup exists, the load scales with oplog gigabytes used per hour.

Can I run the Backup and Monitoring Agents on a Single System?

There is no technical restriction that prevents the Backup Agent and the Monitoring Agent from running on a single system or host. However, both agents have resource requirements, and running both on a single system can affect the ability of these agents support your deployment in Ops Manager.

The resources required by the Backup Agent depend on rate and size of new oplog entries (i.e. total oplog gigabyte/per-hour produced.) The resources required by the Monitoring Agent depend on the number of monitored mongod instances and the total number of databases provided by the mongod instances.

Can I run multiple Backup Agents to achieve high availability?

You can run multiple Backup Agents for high availability. If you do, the Backup Agents must run on different hosts.

When you run multiple Backup Agents, only one agent per group or environment is the primary agent. The primary agent performs the backups. The remaining agents are completely idle, except to log their status as standbys and to periodically ask Ops Manager whether they should become the primary.

Does the Backup Agent modify my database?

The Backup Agent writes a small token called a “checkpoint” into the oplog of the source database at a regular interval. These tokens provide a heartbeat for Backup and have no effect on the source deployment. Each token is less than 100 bytes. See: Checkpoints for more about checkpoints.

Will the MongoDB Backup Service impact my production databases?

Backup will typically have minimal impact on production MongoDB deployments. This impact will be similar to that of adding a new secondary to a replica set.

By default, the Backup Agent will perform its initial sync, the most resource intensive operation for Backup, against a secondary member of the replica set to limit its impact. You may optionally configure the Backup Agent to perform the initial sync against the replica set’s primary, although this will increase the impact of the initial sync operation.

What is the load on the database during the initial Backup sync?

The impact of the initial backup synchronization should be similar to syncing a new secondary replica set member. The Backup Agent does not throttle its activity, and attempts to perform the sync as quickly as possible.

Can I backup my standalone deployment?

No. Backup does not currently support standalone deployments. To convert to a replica set, consult MongoDB’s replication documentation.

How do I perform maintenance on a Replica Set with Backup enabled?

Most operations in a replica set are replicated via the oplog and are thus captured by the backup process. Some operations, however, make changes that are not replicated: for these operations you must have the Backup service resync from your current replica set to include the changes.

The following operations are not replicated and therefore require resync:

• Renaming or deleting a database by deleting the data files in the data directory. As an alternative, remove databases using an operation that MongoDB will replicate, such as db.dropDatabase() from the mongo shell.
• Changing any data while the instance is running as a standalone.
• Using compact or repairDatabase to reclaim a significant amount of space. This is not strictly necessary but will ensure that the Ops Manager copy of the data is resized, which means quicker restores and lower costs.

See also

Maintenance Operations for Replica Set Members.

How Do I Delete a Backup Snapshot?

You can delete replica set backup snapshots and snapshots for replica sets in a sharded cluster set if the snapshots are not needed for point-in-time restores. See Delete Snapshots for Replica Sets and Sharded Clusters for details.

Configuration

What are “excluded namespaces”?

Excluded namespaces are databases and collections that Ops Manager will not back up. This is useful for large databases or collections that contain data that you will not need to restore: caches and logs, for example.

How can I prevent Backup from backing up a collection?

Backup allows you to specify “excluded namespaces”, which are collections or databases that you do not want Ops Manager to back up.

You can specify the namespaces to exclude when you initially enable backup on a replica set or sharded cluster, or can edit the list at any time by selecting the “gear icon” in the Sharded Cluster Status or Replcia Set Status tables in Ops Manager.

How can I change which namespaces are on the “excluded namespaces” list?

Click on the “gear icon” next to the name of the replica set or sharded cluster whose excluded namespaces you want to modify in the Sharded Cluster Status or Replcia Set Status tables in Ops Manager. A modal window will open, where you can add databases or collections to the list, or remove list items by clicking on the red x icon.

Removing a namespace from the excluded namespaces list necessitates a re-sync. Backup handles this re-sync.

How can I use backup if Backup Jobs Fail to Bind?

The most common reason that jobs fail to bind to a Backup daemon is when no daemon has space for local copy of the backed up replica set.

To increase capacity so that the backup job can bind, you can:

• add an additional backup daemon.
• increase the size of the file system that holds the rootDirectory directory.
• move the rootDirectory data to a new volume with more space, and create a symlink or configure the file system mount points so that the daemon can access the data using the original path.

How do I resolve applyOps Errors During Backups?

If you notice consistent errors in applyOps commands in your Backup logs, it may indicate that the daemon has run out of space.

To increase space on a daemon to support continued operations, you can:

• increase the size of the file system that holds the rootDirectory directory.
• move the rootDirectory data to a new volume with more space, and create a symlink or configure the file system mount points so that the daemon can access the data using the original path.

Restoration

Ops Manager Backup produces a copy of your data files that you can use to seed a new deployment.

How can Ops Manager provide point-in-time restores for any point in time?

Although it is faster to provide a restore for the time at which a snapshot was actually stored, this might not be ideal when restoring a replica set or sharded cluster. In consequence, the Backup service can build a restore to any point in time within a 24-hour period by replaying the oplog to the desired time.

For details, see the procedures for restoring replica sets and sharded clusters.

Can I take snapshots more frequently than every 6 hours?

No, Ops Manager does not support a snapshot schedule more frequent than every 6 hours. For more information, see Snapshot Frequency and Retention Policy.

Can I set my own snapshot retention policy?

Yes. Administrators can change the snapshot frequency and retention policy through the snapshotSchedule resource in the API.

For example, you may choose to capture more frequent snapshots for the most mission critical data, and capture snapshots less frequently for less critical data.

How long does it take to create a restore?

Ops Manager transmits all backups in a compressed form from the Ops Manager server to your infrastructure.

In addition, point-in-time restores that require creating a new snapshot take additional time, which depends on the size of the scheduled snapshot and the amount the oplog entries that Backup must apply to the preceding snapshot to roll forward to the requested point-in-time of the backup.

Does Backup perform any data validation?

Backup conducts basic corruption checks and provides an alert if any component (e.g., the agent) is down or broken, but does not perform explicit data validation. When it detects corruption, Backup errs on the side of caution and invalidates the current backup and sends an alert.

How do I restore? What do I get when I restore?

You can request a restore via Ops Manager, where you can then choose which snapshot to restore and how you want Backup to deliver the restore. All restores require 2-factor authentication. Ops Manager will send an authorization code via SMS code to your administrator. You must enter the authorization code into the backup interface to begin the restore process.

Note

From India, use Google Authenticator for two-factor authentication. Google Authenticator is more reliable than authentication with SMS text messages to Indian mobile phone numbers (i.e. country code 91).

Backup delivers restores as tar.gz archives of MongoDB data files.

Restore delivery options are:

• SCP to your Infrastructure: Backup will transmit the backup to your infrastructure over a secure channel. You must provide connection information for a host in your deployment.
• Download: Backup will make your restore data available using a custom, one-time-use URL.

How do I know an SCP restore push has completed and is correct?

When you receive restoration files through an SCP push, Ops Manager sends SHA-1 hash files, also called checksum files, along with the restore files. The hash files have the .sha1 extension,

To ensure the restore files are complete and correct, use the Unix shasum utility:

copy

shasum -c <checksum file>

What is the SCP public key for Ops Manager?

Ops Manager generates an SSH public key on a per user basis to use when delivering backups via SCP. To generate a key, see the steps to grant access via SSH public key in Select Backup File Delivery Method and Format.

How does Backup handle Rollbacks?

If your MongoDB deployment experiences a rollback, then Ops Manager Backup also rolls back.

Backup detects the rollback when a tailing cursor finds a mismatch in timestamps or hashes of write operations. Backup enters a rollback state and tests three points in the oplog of your replica set’s primary to locate a common point in history. Ops Manager rollback differs from MongoDB secondary rollback in that the common point does not necessarily have to be the most recent common point.

When Backup finds a common point, the service invalidates oplog entries and snapshots beyond that point and rolls back to the most recent snapshot before the common point. Backup then resumes normal operations.

If Ops Manager cannot find a common point, a resync is required.

What conditions will require a resync?

If the Backup Agent’s tailing cursor cannot keep up with your deployment’s oplog, then you must resync the Backup Service.

This scenario might occur, for example, if:

• Your application periodically generates a lot of data, shrinking the primary’s oplog window to the point that data is written to the oplog faster than Backup can consume it.
• If the Backup Agent is running on an under-provisioned or over-used machine and cannot keep up with the oplog activity.
• If the Backup Agent is down for a period of time longer than the oplog size allows. If you bring down your agents, such as for maintenance, restart them in a timely manner. For more information on oplog size, see Replica Set Oplog in the MongoDB manual.
• If all you delete all replica set data and deploy a new replica set with the same name, as might happen in a test environment where deployments are regularly torn down and rebuilt.
• If there is a rollback, and Backup cannot find a common point in the oplog.
• If an oplog event tries to update a document that does not exist in the Backup replica set, as might happen if syncing from a secondary that has inconsistent data with respect to the primary.

Administration FAQs

User and Group Management

How do I reset my password?

You can reset your password using the password reset form.

How do I change my password?

You can change your password by resetting your password.

What are the password requirements?

Passwords must be at least 8 characters long and contain at least one letter, one digit, and one special character.

How do I add a user to my company/group?

Instruct the user to create a new account through the URL for your Ops Manager installation.

After they have created an account, you can add their username to the company/group on the admin page.

How do I remove my company/group?

Please contact your Ops Manager administrator to remove a company or group from your Ops Manager account.

How can I configure multiple Google Authenticator apps to use the same account?

By selecting the Can’t scan the barcode? option during the procedure to Configure Two-Factor Authentication with Google Authenticator. The option provides a common key that multiple Google Authenticator apps can use.

Activity

My alert email says my host(s) are exposed to the public Internet. What does that mean?

This alert indicates only that the Ops Manager server can connect to the mongod that it is monitoring. It does not diagnose whether your host is exposed to the public, despite the alert message. This alert occurs if you configured a setting called Exposed DB Host Check, which is a setting used with the Cloud version of Ops Manager.

See Manage Alerts to disable or modify the exposed host alerts.

How do I modify my alert settings?

To enable, disable, or modify alerts, select the Activity tab and then the Alert Settings page. For more information, see Manage Alert Configuration.

How frequently can alerts be set?

Ops Manager processes alerts on a 5-minute interval. Therefore, the minimum frequency for an alert is 5 minutes. The default frequency for new alert configurations is 60 minutes.

Operations

Do Web or Database Hosting Companies Integrate with Ops Manager?

Web hosting companies can offer the ability to use Ops Manager with their hosted MongoDB databases, for example, to set up software agents to monitor and backup databases hosted on their servers. MongoDB has confirmed compatability with MongoHQ, MongoLab, and Heroku. Implementation details depend on each hosting company.

MongoHQ offers Ops Manager upon request as part of their Database as a Service (DaaS) business.

MongoLab offers Ops Manager as part of their Database as a Service (DaaS) business. MongoLab offers the service on their dedicated plans and shared replica set plan. They also provide instructions to tune MongoDB performance with Ops Manager on their servers.

MongoHQ and MongoLab are MongoDB Advanced Partners.

Heroku offers web hosting with a MongoHQ add-on and MongoLab add-on to use MongoDB databases from these database hosting companies. Heroku also offers Ops Manager monitoring of those databases with detailed setup instructions.

About Ops Manager

What open source projects does Ops Manager use?

• Database: MongoDB
• App framework: Google Guice
• Http server: Jetty
• Web framework: Jersey
• Misc server libs: Apache Commons
• UI lib: jQuery , Bootstrap
• Charts: dygraphs
• Graphics: Font-Awesome

←   Troubleshooting Reference  →

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.