Navigation

Required Access for Monitoring Agent

If your MongoDB deployment enforces access control, the Ops Manager Monitoring Agent must authenticate to MongoDB as a user with the proper access.

If you use Automation, Ops Manager takes care of this for you. If you do not use Automation, follow the instructions on this page.

To authenticate, create a user with the appropriate roles in MongoDB. The following tutorials include instructions and examples for creating the MongoDB user:

MongoDB user roles are separate from Ops Manager user roles and are described in the MongoDB manual beginning with the Authorization page.

Considerations

To authenticate to sharded clusters, create shard-local users on each shard and create cluster-wide users:

  • Create cluster users while connected to the mongos: these credentials persist to the config servers.
  • Create shard-local users by connecting directly to the replica set for each shard.

Important

The Monitoring Agent user must be defined consistently for all processes in your Ops Manager deployment.

There are additional authentication configuration requirements for Ops Manager Monitoring when using MongoDB 2.4 with authentication.

Prerequisites

Connect to the mongod or mongos instance as a user with access to create users in the database. See db.createUser() method page for more information.

MongoDB 2.6

To monitor MongoDB 2.6 instances, including dbStats [2] and database profiling information [1], the monitoring agent must authenticate to the database as a user with the following access:

Required Role  
clusterMonitor role on the admin database  

For mixed MongoDB versions that use Monitoring Agents older than version 3.7.0, the specified access is inadequate to monitor deployments since the user cannot access the local database needed for mixed deployments. Monitoring a mixed deployment as a user with the specified access will produce an authorization error that will appear in the mongod logs. The pre-3.7.0 Monitoring Agent can recover from this error but causes the extra log entries. You can safely ignore these extra entries.

MongoDB 2.4

Monitor without Database Profiling

To monitor MongoDB 2.4 instances, including dbStats operations, the agent must authenticate as a user with the following access:

Required Roles  
clusterAdmin role on the admin database  
readAnyDatabase role on the admin database  

However, a user with the specified access cannot monitor with profiling. If this user tries to monitor with profiling, the mongod log file may report the following message at the default logging level:

command denied: { profile: -1 }

You can ignore this message if you do not want Ops Manager to collect profile data. If you want to collect profile data, configure Ops Manager monitoring as specified in Monitor with Database Profiling.

Monitor with Database Profiling

To monitor MongoDB 2.4 databases with database profiling [1], the agent must authenticate as a user with the following access:

Required Roles  
clusterAdmin role on the admin database  
readAnyDatabase role on the admin database  
dbAdminAnyDatabase roles in the admin database  
[1](1, 2) Profiling captures in-progress read and write operations, cursor operations, and database command information about the database.

Monitor without dbStats

To monitor MongoDB 2.4 databases without dbStats [2], the agent must authenticate as a user with the following access:

Required Role  
clusterAdmin role on the admin database  

Authentication Mechanisms

To authenticate, create the user in MongoDB with the appropriate access. The authentication method that the MongoDB deployment uses determines how to create the user as well as determine any additional agent configuration:

[2](1, 2) Monitoring without dbStats excludes database storage, records, indexes, and other statistics.