Docs Menu
Docs Home
/
MongoDB Cloud Manager
/

FAQ: MongoDB Agent

On this page

  • General
  • What is the MongoDB Agent?
  • When was the MongoDB Agent in Cloud Manager launched?
  • When must I switch to the MongoDB Agent?
  • Can I update per cluster or per node?
  • Did the Cloud Manager UI change?
  • Does the Cloud Manager API support the MongoDB Agent?
  • Can I programmatically upgrade to MongoDB Agent via the API?
  • Does the new installer use a different filename?
  • I have a PEM Key File and Password(s) set for my legacy Automation, Monitoring or Backup Agents? What should I know when I switch to the MongoDB Agent?
  • I only use the legacy Monitoring Agent, what does this mean for me?
  • I only use the legacy Monitoring and Backup Agents, what does this mean for me?
  • My clusters are already managed using all 3 legacy Agents, what will happen?
  • What about the three MongoDB Agent Users?

This addresses common questions about the MongoDB Agent.

The MongoDB Agent helps you manage, monitor, and back up your MongoDB instances.

Cloud Manager rolled out the MongoDB Agent between May and June 2019. You must update as soon as possible to the MongoDB Agent because the legacy Agents are now EOL.

Now. Any legacy agent update requires switching to the MongoDB Agent. You must update all clusters in the project. Once updated, the Cloud Manager console renders the new interface for the MongoDB Agent.

No. Updates to MongoDB Agent must be done for all clusters in a project simultaneously.

Yes. The Agent(s) and Servers tabs were updated to reflect this change.

Yes.

Yes.

No. The name for the installer is mms-automation to make the update easier.

When you switch to using the MongoDB Agent, these settings are preserved. If you previously set a PEM Key File and Password in the Security > Settings section of Cloud Manager, Cloud Manager uses the current Automation Agent's PEM key file and Password as the MongoDB Agent PEM Key File and Password.

Any existing Monitoring and Backup PEM Key File and password(s) are exported into the new custom configuration section for Monitoring and Backup on the MongoDB Agent UI page. A warning displays in the Configure Cloud Manager Agents section (Security > Settings) that the values from the custom configuration section override these values.

The MongoDB Agent provides support in this case. The process of switching to using the MongoDB Agent proceeds as follows:

  1. When the MongoDB Agent is available, you see the banner notification that your Monitoring Agent is out of date.

  2. When you are ready to switch, click Update in the banner. A workflow that guides you through the update process starts.

    1. Read a MongoDB Agent description with a link to documentation.

    2. Specify custom Monitoring configuration options that you use for your Cloud Manager project.

    3. Download and install the MongoDB Agent. Cloud Manager verifies that the MongoDB Agent is installed correctly on the list of specified servers.

      Note

      Previously configured authentication methods continue to work. You provide the MongoDB authentication information in Monitoring Settings uder the menu.

  3. Once you install the MongoDB Agent on a server, the MongoDB Agent enables the Monitoring for projects where Monitoring existed as a standalone Agent before switching to theMongoDB Agent.

  4. The MongoDB Agent puts the previously used Monitoring Agents into standby mode and no longer shows them in the UI.

  5. The previously used standalone Monitoring Agents can no longer monitor instances. You can stop and remove them when ready.

From this point forward, the MongoDB Agent updates itself after you choose the Confirm and Deploy option for the new version. You no longer need to download the MongoDB Agent each time a new version becomes available!

The MongoDB Agent supports this use case. The flow for switching to the MongoDB Agent proceeds as follows:

  1. When the MongoDB Agent is available, you see the banner notification that your Monitoring and Backup Agents are out of date.

  2. When you are ready to update, click Update in the banner. A workflow that guides you through the update process starts.

    1. Read MongoDB Agent description with a link to documentation.

    2. Specify custom Monitoring and Backup configuration options that you use for your Cloud Manager project.

    3. Download and install the MongoDB Agent. Cloud Manager verifies that the MongoDB Agent been installed correctly on the list of known servers.

      Note

      Previous authentication methods continue to work. You provide MongoDB authentication information in Monitoring Settings under the menu. To specify Backup user settings, go to Backup under Options > > Edit Credentials.

  3. Once the MongoDB Agent is installed on a server, it enables the Monitoring and Backup in projects where the Agents were previously configured.

  4. The MongoDB Agent puts the previously used Monitoring and Backup Agents into standby mode and no longer shows them in the UI. The previously used standalone Monitoring Agents can no longer monitor instances. You can stop and remove them when ready.

From this point forward, the MongoDB Agent updates itself if you choose to use the Confirm and Deploy option for a new version. You no longer need to download the MongoDB Agent each time a new version becomes available!

The update flow proceeds as follows:

  1. When the MongoDB Agent is available, you see the banner notification that your legacy Agents are out of date.

  2. When you are ready to update, click Update in the banner. A workflow that guides you through the update process starts.

    1. Read the MongoDB Agent description with link to documentation.

    2. Review a list of your current servers and update them to the MongoDB Agent. As a part of this update process the MongoDB Agent:

      • Stops any legacy Monitoring and Backup Agents.

      • Enables Monitoring and Backup on the servers where Monitoring and Backup were running as Agents.

      • Removes the binaries for the stopped Monitoring and Backup Agents.

      • Unlocks the mms-monitoring-agent or mms-backup-agent users in your MongoDB instances so you can delete them, if desired. The MongoDB Agent uses the mms-automation user to connect to your instances.

From this point forward, the MongoDB Agent works as a single process for Automation, Monitoring, and Backup.

MongoDB consolidated the three MongoDB users that the legacy Automation Agent used (mms-automation, mms-monitoring-agent, mms-backup-agent) into one user. This user, mms-automation, can automate, monitor, and back up instances. MongoDB didn't remove the previous MongoDB users in case you use those users in other projects. However, Cloud Manager unlocked these users in its interface as part of the update so that you may delete them.

I mostly manage my clusters with the Automation Agent but I have a Standalone legacy Backup and Monitoring Agents, what does this mean for me? ----------------------------------------------------------------------------------------------------------------------------------------------------------

You get both update flows: one for any standalone Agent, as described in the previous sections:

I only use the legacy Monitoring Agent, what does this mean for me? or

I only use the legacy Monitoring and Backup Agents, what does this mean for me?

For those servers where Automation manages legacy Monitoring and Backup Agents, see My clusters are already managed using all 3 Agents, what will happen?.

Back

Monitoring and Alerts