This is one stop global knowledge base where you can learn about all the products, solutions and support features.
On this page
Important
The ability to provision MongoDB servers in AWS using Cloud Manager was retired in October 2017.
mongodbdns.com
hostname.
mongodbdns.com
hostnames will stop working in
May 2023.
If you want to continue using Cloud Manager to manage these deployments, update the hostname for each host using one of the following methods for a replica set:
These procedures involve stepping down the old primary and triggering
at least one election for a new primary. All writes to the primary
fail during the period starting when the
rs.stepDown()
method is received until either a
new primary is elected, or if there are no electable secondaries, the
original primary resumes normal operation. For MongoDB versions 4.0 and
earlier, all client connections are closed.
Consider performing this procedure during a maintenance window during which applications stop all write operations to the cluster.
To learn more about elections, see rs.stepDown() behavior and Replica Set Elections .
mongodbdns.com
hostname. To learn more, see
Remove Members from Replica Set.
Repeat for each non-primary replica set member.
Add the last new instance to the replica set using its EC2 hostname. To learn more, see Add Members to a Replica Set.
Wait for the initial sync to complete. To learn how to get the status of an initial sync, see the MongoDB manual.
Connect to the primary and step it down. To learn more, see
rs.stepDown()
.
Note
Stepping down the primary triggers at least one election for a new primary. To learn more about elections, see Replica Set Elections .
Remove the old primary with the
mongodbdns.com
hostname from
the replica set. To learn more, see
Remove Members from Replica Set.
Follow the Change Hostnames while Maintaining Replica Set Availability procedure in the MongoDB manual.
An overview of the linked procedure is as follows:
Repeat for each non-primary member of the replica set.
Note
Stepping down the primary triggers at least one election for a new primary. To learn more about elections, see Replica Set Elections .
On this page
When you stop backups for a replica set or sharded cluster Cloud Manager stops taking new snapshots but retains existing snapshots until their listed expiration date.
If you later restart backups for replica set or cluster, Cloud Manager might perform an initial sync , depending on how much time has elapsed.
If you terminate a backup, Cloud Manager immediately deletes all the backup’s snapshots.
If prompted for an authentication code, enter the code and click Verify . Click Stop again.
Terminating a backup triggers a full backup
If you terminate a backup, Cloud Manager immediately deletes the backup’s snapshots. The next backup job runs as a full backup rather than an incremental backup.
If prompted for an authentication code, enter the code and click Verify . Click Stop again.
On this page
Cloud Manager issues alerts for the database and server conditions configured in your alert settings . When a condition triggers an alert, you receive the alert at regular intervals until the alert resolves or Cloud Manager cancels it. You should fix the immediate problem, implement a long-term solution, and view metrics to monitor your progress.
You can filter the organization activity feed by event type and time range. You can combine filtering methods together for greater control over the activity feed output.
Select the event categories or specific events you want to see from the activity feed. To exclude specific categories or events from the activity feed, click Select all categories and events , then deselect the categories and events you want to exclude.
You can filter events based on the following categories:
| Category | Description |
|---|---|
| Access | Events related to Cloud Manager users. |
| Alerts | Events related to alert configuration and monitoring. |
| Billing | Events related to payments and payment methods. |
| Others | Miscellaneous events, including log retrieval and mLab events. |
| Organization | Events related to your Cloud Manager organization. |
| Projects | Events related to Cloud Manager projects. |
You can filter the project activity feed by event type, cluster, and time range. You can combine filtering methods together for greater control over the activity feed output.
Select the event categories or specific events you want to see from the activity feed. To exclude specific categories or events from the activity feed, click Select all categories and events , then deselect the categories and events you want to exclude.
You can filter events based on the following categories:
| Category | Description |
|---|---|
| Access | Events related to Cloud Manager users. |
| Alerts | Events related to alert configuration and monitoring. |
| Billing | Events related to payments and payment methods. |
| Others | Miscellaneous events, including log retrieval and mLab events. |
| Organization | Events related to your Cloud Manager organization. |
| Projects | Events related to Cloud Manager projects. |
You can retrieve events for a specified organization or project using the Events API resource.
When you acknowledge the alert, Cloud Manager sends no further notifications to the alert’s distribution list until the acknowledgment period has passed or until you resolve the alert. The distribution list receives no notification of the acknowledgment.
If the alert condition ends during the acknowledgment period, Cloud Manager sends a notification of the resolution.
If you configure an alert with PagerDuty, a third-party incident management service, you can only acknowledge the alert on your PagerDuty dashboard.
To acknowledge a single alert, on the line item for the alert, click Acknowledge .
To acknowledge multiple, but not all, alerts:
To acknowledge all alerts:
Click the time frame for which you no longer wish to receive alerts.
Cloud Manager sends no further alert messages for the period of time you select.
If all alerts are checked, then another set of radio buttons appear:
To acknowledge a single alert, on the line item for the alert, click Acknowledge .
To acknowledge multiple, but not all, alerts:
To acknowledge all alerts:
Click the time frame for which you no longer wish to receive alerts.
Cloud Manager sends no further alert messages for the period of time you select.
If all alerts are checked, then another set of radio buttons appear:
You can undo an acknowledgment and again receive notifications if the alert condition still applies.
If the alert condition continues to exist, Cloud Manager resends the alerts.
If the alert condition continues to exist, Cloud Manager resends the alerts.
You can turn off alerts for a given process. This might be useful, for example, if you want to temporarily disable the process but do not want it hidden from monitoring. Use the following procedure both to turn alerts off or on.
Specify maintenance windows to temporarily turn off alert notifications for a given resource while you perform maintenance.
To view maintenance windows:
Note that selecting the
Host
target selects both
HOST
and
HOST_METRIC
alert configurations returned through the
alertConfigs endpoint
.
Installation Instructions in Cloud Manager Interface
Cloud Manager displays the MongoDB Agent install instructions after you choose your MongoDB Agent download. You can copy all the necessary commands from the Cloud Manager.
Caution
Please review the MongoDB Agent Prerequisites before installing the MongoDB Agent.
There are two workflows to follow when using MongoDB Agents with MongoDB hosts:
On this page
Cloud Manager collects log information for both MongoDB processes and its agents. For MongoDB processes, you can access both real-time logs and on-disk logs.
mongod
and
mongos
processes.
The MongoDB Agent issues the
getLog
command with every
monitoring ping. This command collects log entries from RAM cache of
each MongoDB process.
Cloud Manager enables real-time log collection by default. You can disable log collection for either all MongoDB deployments in a Cloud Manager project or for individual MongoDB deployments . If you disable log collection, Cloud Manager continues to display previously collected log entries.
The four buttons are listed in the following order, left to right: Shards , Configs , Mongos , and BIs .
| Process | Displays |
|---|---|
| Shards | mongod processes that host your data. |
| Configs | mongod processes that run as config servers to store a sharded cluster’s metadata. |
| Mongos | mongos processes that route data in a sharded cluster. |
| BIs | BI processes that access data in a sharded cluster. |
The tab displays log information. If the tab is not displayed, see Enable or Disable Log Collection for a Deployment to enable log collection.
If you turn off log collection, existing log entries remain in the Logs tab, but Cloud Manager does not collect new entries.
Cloud Manager collects on-disk logs even if the MongoDB instance is not
running. The MongoDB Agent collects the logs from the location you
specified in the MongoDB
systemLog.path
configuration option. The
MongoDB on-disk logs are a subset of the real-time logs and therefore
less verbose.
Note
This option isn’t available for deployed MongoDB processes if the
systemLog.destination
property is set to
syslog
.
You can configure log rotation for the on-disk logs. Cloud Manager rotates logs by default.
This procedure rotates both system and audit logs for Cloud Manager.
Cloud Manager can rotate and compress logs for clusters that the MongoDB Agent manages. If the MongoDB Agent only monitors a cluster, it ignores that cluster’s logs.
Important
If you’re running MongoDB Enterprise version 5.0 or later and MongoDB Agent 11.11.0.7355 or later, you can:
If you’re running earlier versions of MongoDB Enterprise or the MongoDB Agent, Cloud Manager:
MongoDB Community users can rotate, compress, and delete the server logs only.
Note
When using this feature, disable any platform-based log-rotation
services like
logrotate
. If the MongoDB Agent only monitors the
cluster, that cluster may use platform-based services.
Toggle System Log Rotation to ON to rotate server logs.
MongoDB Enterprise users running MongoDB Enterprise version 5.0 or later and MongoDB Agent 11.11.0.7355 and later can also toggle Audit Log Rotation to ON to rotate audit logs and configure audit log rotation separately.
If you’re running earlier versions of MongoDB Enterprise or the MongoDB Agent, setting System Log Rotation to ON also rotates audit logs.
Set log rotation to OFF if you don’t want Cloud Manager to rotate its logs. Log rotation is OFF by default.
After you enable log rotation, Cloud Manager displays additional log rotation settings.
Cloud Manager rotates the logs on your MongoDB hosts per the following settings:
| Field | Necessity | Action | Default |
|---|---|---|---|
| Size Threshold (MB) | Required | Cloud Manager rotates log files that exceed this maximum log file size. |
1000
|
| Time Threshold (Hours) | Required | Cloud Manager rotates logs that exceed this duration. |
24
|
| Max Uncompressed Files | Optional |
Log files can remain uncompressed until they exceed this number of files. Cloud Manager compresses the oldest log files first.
If you leave this setting empty, Cloud Manager will use the default
of
|
5
|
| Max Percent of Disk | Optional |
Log files can take up to this percent of disk space on your MongoDB host’s log volume. Cloud Manager deletes the oldest log files once they exceed this disk threshold.
If you leave this setting empty, Cloud Manager will use the default of
|
2%
|
| Total Number of Files | Optional |
Total number of log files. If a number is not specified, the
total number of log files defaults to
0
and is determined
by other
Rotate Logs
settings.
|
0
|
When you are done, click Save to review your changes.
Otherwise, click Cancel and you can make additional changes.
Cloud Manager collects logs for all your MongoDB Agents.
The page displays logs for the type of agent selected in the View drop-down list. The page filters logs according to any filters selected in through the gear icon.
To display logs for a different type of agent, use the View drop-down list.
To display logs for a specific hosts or MongoDB processes, click the gear icon and make your selections.
To clear filters, click the gear icon and click Remove Filters .
To download the selected logs, click the gear icon and click Download as CSV File .
Note
To view logs for a specific agent, you can alternatively click the Agents tab’s All Agents list and then click view logs for the agent.
If you use Automation to manage your cluster, follow this procedure to configure rotation of the Agent log files.
Note
If you haven’t enabled Automation, see the following documentation for information about how to manually configure logging settings in the agent configuration files:
Click the pencil icon to edit the Monitoring Agent or Backup Agent log settings:
| Name | Type | Description |
|---|---|---|
| Linux Log File Path | string |
Conditional: Logs on a Linux host. The path to which the agent writes its logs on a Linux host. The suggested value is: /var/log/mongodb-mms-automation/monitoring-agent.log
|
| Windows Log File Path | string |
Conditional: Logs on a Windows host. The path to which the agent writes its logs on a Windows host. The suggested value is: %SystemDrive%\MMSAutomation\log\mongodb-mms-automation\monitoring-agent.log
|
| Rotate Logs | Toggle | A toggle to select if the logs should be rotated. |
| Size Threshold (MB) | integer |
The size where the logs rotate automatically. The default value
is
1000
.
|
| Time Threshold (Hours) | integer |
The duration of time when the logs rotate automatically. The
default value is
24
.
|
| Max Uncompressed Files | integer |
Optional.
The greatest number of log files, including the
current log file, that should stay uncompressed. The suggested
value is
5
.
|
| Max Percent of Disk | integer |
Optional.
The greatest percentage of disk space on your
MongoDB hosts that the logs should consume. The suggested
value is
2%
.
|
| Total Number of Files | integer |
Optional.
The total number of log files. If a number is not specified,
the total number of log files defaults to
0
and is determined by other
Rotate Logs
settings.
|
When you are done, click Save .
Otherwise, click Cancel and you can make additional changes.
On this page
New
Cloud Manager provides a new organizations and projects hierarchy to help you manage your Cloud Manager deployments. Groups are now known as projects. You can create many projects in an organization.
In the organizations and projects hierarchy, an organization can contain many projects (previously referred to as groups). Under this structure, you can:
Groups are now projects. Previously, users managed deployments by groups, where each group was managed separately even if a user belonged to multiple groups.
If you have existing groups, organizations have been automatically created for your groups (now projects), and your groups have been placed under these organizations.
If your groups share the same billing settings, they have been placed in the same organization.
Deployments are now associated with projects. As before, deployments must have unique names within projects. See Projects and Edit Project Settings .
You can create teams of users and then assign teams of users to projects. See Cloud Manager Access .
You can view and accept invitations to organizations and projects. See Invitations to Organizations and Projects .