Navigation
This version of the documentation is archived and no longer supported. It will be removed on EOL_DATE. To learn how to upgrade your version of MongoDB Ops Manager, refer to the upgrade documentation.
You were redirected from a different version of the documentation. Click here to go back.
This version of the manual is no longer supported. It will be removed on EOL_DATE.

Automation

Ops Manager Automation allows you to deploy, configure, and manage MongoDB deployments with the Ops Manager UI. Ops Manager Automation relies on an Automation Agent, which must be installed on every server in the deployment. The Automation Agents periodically poll the Ops Manager service to determine the current goal, and continually report their status to Ops Manager.

Automation Runs Only on 64-bit Architectures

Ops Manager provides only 64-bit downloads of the Automation Agent.

Using Own Hardware

  • If you deploy Automation manually, ensure that you have one Automation Agent on every server.

  • If you deploy the agent manually, you must create MongoDB’s dbpath and the directory for the MongoDB binaries and ensure that the user running the agent owns these directories.

    If you install using the rpm package, the agent runs as the mongod user; if using the deb package, the agent runs as the mongodb user. If you install using the tar.gz archive file, you can run the agent as any user.

Networking

Connectivity to MongoDB Ports

All hosts must be able to allow communication between MongoDB ports. The default is 27017, but you can configure alternate port ranges in the Ops Manager interface.

The Automation Agent must be able to connect to Ops Manager on port 8080 (HTTP) or port 8443 (HTTPS). For more information on access to ports and IP addresses, see Security Overview.

Intra-cluster Connectivity Issue

When performing a rolling update, the Automation Agent tries to avoid downtime. It needs to collect state from other members of the cluster. A connectivity issue (between mongods and mongoses), such as hostname resolution or misconfigured firewall, may prevent the Automation Agent from determining the remote processes state and completing the change.

To ensure all members of the cluster can communicate with each other over the mongo port:

  1. For a non-sharded cluster:
    1. Log into each mongod.
    2. From that mongod host, log into all the other members of the replica set.
  2. For a sharded cluster:
    1. Log into each mongod.
    2. From that mongod host, log into all the other members of the shard.
    3. Log into each mongos.
    4. From that the mongos host:
      1. Log into the other mongos hosts.
      2. Log into all the other members of each shard.

Automation Configuration

After completing the automation configuration, ensure that the deployment plan satisfies the needs of your deployment. Check hostnames and ports before confirming the deployment.

Sizing

  • Ensure that you provision hosts with enough space to run MongoDB and support the requirements of your data set.
  • Ensure that you provision a sufficient number of hosts to run your deployment. Each mongod should run on its own host.

Frequent Connection Timeouts

The Automation Agent may frequently time out of connections for one or more of the following reasons:

  • Connection timeouts
  • High network latency
  • High server load
  • Large SSL keys
  • Insufficient CPU speed

By default, connections time out after 40 seconds. MongoDB recommends gradually increasing the value of the dialTimeoutSeconds Automation Agent configuration setting to prevent frequent premature connection timeouts. However, increasing this value also increases the time required to deploy future configuration changes. Experiment with small, incremental increases until you determine the optimum value for your deployment.

To learn more, see dialTimeoutSeconds in Connection Settings at Automation Agent Configuration.

Deployments

A banner that displays We have detected a potential problem while deploying… appears when certain conditions apply. These are some examples.

Deployment Change Unable to Complete / Not Proceeding

If you have added or restarted a deployment and the deployment remains in the In Progress state for several minutes, the banner displays.

At this point, you have four options:

  1. Click View Diagnostics.

    The View Diagnostics modal displays any errors that may have happened during deployment.

  2. Click View Status.

    The Automation Status modal displays the deployment processes, when they last reported their deployment status, what task they are trying to complete, and the deployment status.

    To learn more about the status of any of the individual processes, you can click the ellipsis icon and select either View Details or View Agent Logs.

    • View Details shows what the deployment plan for the process is and which stage of that plan the Automation Agent currently is.
    • View Agent Logs opens a new browser window with the Deployment > Agents > Agent Logs screen shown and the contents of the Automation Agent log displayed by default. Click the View menu to select a different agent log.
  3. Click View Agent Logs.

    A new browser window opens with the Deployment > Agents > Agent Logs screen shown and the contents of the Automation Agent log displayed by default. Click the View menu to select a different agent log.

  4. Click Allow Override & Edit Configuration.

    If you diagnose an error and need to correct the deployment configuration, follow the procedure to edit the deployment.

If you shut down the deployment and still cannot find a solution, remove the deployment from Ops Manager.

Automation Agents Are Down or Not Communicating

If the Automation Agents are having issues communicating with the Ops Manager host or the MongoDB instances, the banner displays. This can be resolved in one of two ways depending upon whether or not you expect the Automation Agent(s) to be communicating:

Automation Agents need to communicate

If the Automation Agent(s) should be communicating with the Ops Manager host or MongoDB instances, confirm the following for each Automation Agent:

  1. The Agent is up and running on each host.
  2. The Agent and the Ops Manager hosts can communicate.

Automation Agents do not need to communicate

If the Automation Agent(s) is (are) no longer needed and should not be communicating with the Ops Manager host or MongoDB instances, confirm the following for each Automation:

  1. Click the Allow Editing & Override Current Configuration link in the warning banner.
  2. Remove all processes (mongod and mongos) running on the hosts that serve the unneeded Automation Agents.

Automation Agent Permissions

A permissions issue may prevent automation from completing a change. If View Status or View Diagnostics report an permissions-related error (such as open /data/db/mongod.lock: permission denied), ensure that the Automation Agent user owns and have read and write permissions to the dbpath and logpath files.

←   Authentication Monitoring  →