- Troubleshooting >
- Automation
Automation¶
On this page
Ops Manager Automation allows you to deploy, configure, and manage MongoDB deployments with the Ops Manager UI. Ops Manager Automation relies on an Automation, which must be installed on every server in the deployment. The Automations 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.
Using Own Hardware¶
If you deploy Automation manually, ensure that you have one Automation 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 themongod
user; if using thedeb
package, the agent runs as themongodb
user. If you install using thetar.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 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 tries to avoid
downtime. It needs to collect state from other members of the cluster.
A connectivity issue (between mongod
s and mongos
es), such as
hostname resolution or misconfigured firewall, may prevent the
Automation from determining the remote processes state and
completing the change.
To ensure all members of the cluster can communicate with each other:
- For a non-sharded cluster:
- For a sharded cluster:
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 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 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 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:
Click View Diagnostics.
The View Diagnostics modal displays any errors that may have happened during deployment.
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 currently is.
- View Agent Logs opens a new browser window with the Deployment > Agents > Agent Logs screen shown and the contents of the Automation log displayed by default. Click the View menu to select a different agent log.
Click View Agent Logs.
A new browser window opens with the Deployment > Agents > Agent Logs screen shown and the contents of the Automation log displayed by default. Click the View menu to select a different agent log.
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.
Automations Are Down or Not Communicating¶
If the Automations 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(s) to be communicating:
Automations need to communicate¶
If the Automation(s) should be communicating with the Ops Manager host or MongoDB instances, confirm the following for each Automation:
- The Agent is up and running on each host.
- The Agent and the Ops Manager hosts can communicate.
Automations do not need to communicate¶
If the Automation(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:
- Click the Allow Editing & Override Current Configuration link in the warning banner.
- Remove all processes
(
mongod
andmongos
) running on the hosts that serve the unneeded Automations.
Automation 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 user owns and
has read and write permissions to the dbpath
and logpath
files.
Ensure TLS Certificates Contain a Subject Alternative Name¶
Warning
MongoDB Agent 10.2.24.6007 uses Go 1.15, which requires that TLS certificates contain a Subject Alternative Name (SAN) field. Before upgrading to MongoDB Agent 10.2.24.6007, ensure that all TLS certificates used in your MongoDB deployment contain a Subject Alternative Name.
You can temporarily continue to use TLS certificates without a
SAN by setting the $GODEBUG
environment variable. However, this
workaround will not be supported in upcoming releases of the
MongoDB Agent.
To temporarily use TLS certificates without a SAN, you must either:
- Upgrade your MongoDB Agent packages, which automatically sets the
$GODEBUG
environment variable on your host, or - Manually set the
$GODEBUG
environment variable for the Agent process tox509ignoreCN=0
on the host on which you will install the RPM, DEB, or Windows packages.
In Go 1.17, the
GODEBUG=x509ignoreCN=0
flag will not be supported.
Store Configuration Files in Memory for Existing Clusters¶
If you use Ops Manager version 4.2 or versions 4.4.0 - 4.4.6, you may encounter
errors when setting enableLocalConfigurationServer
to true
and restarting your MongoDB Agent.
This issue only affects existing clusters where
enableLocalConfigurationServer
is set to true
after the cluster
is created. Setting this value before creating the cluster does not trigger
this issue.
To safely change this setting for existing clusters:
At the end of your MongoDB Agent configuration file, add:
Shut down each process managed by the MongoDB Agent.
Restart the MongoDB Agent by running the following command:
Restart the MongoDB processes that you shut down.
Verify that the
automation-mongod.conf
file has the__rest
expansion directive.
For more information on storing configuration files in memory, see Configure MongoDB Agent for Externally Sourced Configuration File Values.