• Frequently Asked Questions >
• FAQ: MongoDB Agent

FAQ: MongoDB Agent

This addresses common questions about the MongoDB Agent.

General

What is the MongoDB Agent?

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

When was the MongoDB Agent in Cloud Manager launched?

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.

When must I switch to the MongoDB Agent?

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.

Can I update per cluster or per node?

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

Will the Cloud Manager UI change?

Yes. In areas like the Agent(s) and Servers tabs, some wording will change but nothing dramatic.

Will the Cloud Manager API support the MongoDB Agent?

Yes.

Can I programmatically upgrade to MongoDB Agent via the API?

Yes.

Will the new installer use a different filename?

No. It will remain mms-automation to make the update easier.

I have a PEM Key File and Password(s) set for my legacy Automation, Monitoring or Backup Agents? How’s that going to work?

When you update to MongoDB Agent, these settings are preserved. If you have set a PEM Key File and Password in the Security > Authentication & TLS/SSL section of Cloud Manager, it uses the current Automation Agent 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 page. A warning displays at the Configure Cloud Manager Agents section (Security > Authentication & TLS/SSL) that those values are being overridden with values from the custom configuration section.

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

Rest assured, you will be supported with MongoDB Agent. In general, the update flow proceeds as follows:

1. When the MongoDB Agent is available, you see the usual banner notification that your Monitoring Agent is 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. First, you read a brief explanation of what MongoDB Agent is with a link to relevant documentation.

   2. Second, you can enter any custom Monitoring configuration options you require for your Cloud Manager project.

   3. Third, you can download and install the new MongoDB Agent. Cloud Manager verifies that it has been installed correctly on the list of known servers.

      Note

      Previous authentication methods continue to work and MongoDB authentication information are entered in the same locations in the User Interface. (Monitoring user settings under the Monitoring Settings menu option of the ellipsis h icon menu.)

3. Once the MongoDB Agent is installed on a server, it enables the Monitoring where it existed as a standalone Agent before.

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

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

All done! From this point forward, the MongoDB Agent can update itself once you Confirm and Deploy a new version. You no longer need to download the binary each time a new version is available!

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

Rest assured, you will be supported with MongoDB Agent. In general, the update flow proceeds as follows:

1. When the MongoDB Agent is available, you see the usual 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. First, you read a brief explanation of what MongoDB Agent is with a link to relevant documentation.

   2. Second, you can enter any custom Monitoring and Backup configuration options you require for your Cloud Manager project.

   3. Third, you can download and install the new MongoDB Agent. Cloud Manager verifies that it has been installed correctly on the list of known servers.

      Note

      Previous authentication methods continue to work and MongoDB authentication information are entered in the same locations in the User Interface. (Monitoring user settings are found via the Monitoring Settings menu option in the ellipsis h icon menu. Backup user settings are found on the Backup screen under Options > ellipsis h icon > Edit Credentials.)

3. Once the MongoDB Agent is installed on a server, it enables the Monitoring and Backup where they existed as a standalone Agents before.

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

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

All done! From this point forward, the MongoDB Agent can update itself once you Confirm and Deploy a new version. You no longer need to download the binary each time a new version is available!

My clusters are already managed using all 3 legacy Agents, what will happen?

Step right onto Easy Street! The update flow proceeds as follows:

1. When the MongoDB Agent is available, you see the usual 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. First, you read a brief explanation of what MongoDB Agent is with a link to relevant documentation.
   2. Second, you see a list your current servers and you can update all of them to MongoDB Agent with the click of a single button. 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/or Backup were running as an Agent.
      • Removes the stopped Monitoring and Backup Agent binaries.
      • 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.

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

What about the three MongoDB Agent Users?

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 hasn’t removed the old MongoDB users in case you use those users for something else. However, Cloud Manager unlocked these users in its interface as part of the update so you may delete them.

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

You get both update flows: one for anything standalone as explained 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/Backup Agents, you follow the My clusters are already managed using all 3 Agents, what will happen? section.

←   FAQ: Monitoring and Alerts FAQ: Automation EoL for MongoDB 3.2  →

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