This is one stop global knowledge base where you can learn about all the products, solutions and support features.
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 .
On this page
This guide shows you how to configure federated authentication using Okta as your IdP .
After integrating Okta and Cloud Manager, you can use your company’s credentials to log in to Cloud Manager and other MongoDB cloud services.
Note
If you are using Okta’s built-in MongoDB Cloud app, you can use Okta’s documentation.
If you are creating your own SAML app, use the procedures described here.
To use Okta as an IdP for Cloud Manager, you must have:
Throughout the following procedure, it is helpful to have one browser tab open to your Federation Management Console and one tab open to your Okta account.
.cer
extension instead of
.cert
.
In the FMC dashboard, fill in the data fields with the following values:
| Field | Value |
|---|---|
| Configuration Name | A descriptive name of your choosing. |
| Issuer URI and Single Sign-On URL | Click the Fill With Placeholder Values button to the right of the text fields. You will get the real values from Okta in a later step. |
| Identity Provider Signature Certificate |
Click the
Choose File
button to upload the
You can either:
|
| Request Binding | HTTP POST |
| Response Signature Algorithm | SHA-256 |
Click the Next button.
In this step, copy values from the Cloud Manager FMC to the Okta Create SAML Integration page.
| Okta Data Field | Value | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Single sign on URL |
Use the Assertion Consumer Service URL from the Cloud Manager FMC. Checkboxes:
|
||||||||||||||
| Audience URI (SP Entity ID) | Use the Audience URI from the Cloud Manager FMC. | ||||||||||||||
| Default RelayState |
Optionally, add a RelayState URL to your IdP to send users to a URL you choose and avoid unnecessary redirects after login. You can use:
|
||||||||||||||
| Name ID format | Unspecified | ||||||||||||||
| Application username | |||||||||||||||
| Update application username on | Create and update |
Click the Click Show Advanced Settings link in the Okta configuration page and ensure that the following values are set:
| Okta Data Field | Value |
|---|---|
| Response | Signed |
| Assertion Signature | Signed |
| Signature Algorithm | RSA-SHA256 |
| Digest Algorithm | SHA256 |
| Assertion Encryption | Unencrypted |
Leave the remaining Advanced Settings fields in their default state.
Scroll down to the Attribute Statements (Optional) section and create three attributes with the following values:
| Name | Name Format | Value |
|---|---|---|
| Unspecified | user.email | |
| firstName | Unspecified | user.firstName |
| lastName | Unspecified | user.lastName |
Important
The values in the Name column are case-sensitive. Enter them exactly as shown.
Note
These values may be different if Okta is connected to an Active Directory. For the appropriate values, use the Active Directory fields that contain a user’s first name, last name, and full email address.
Click the Next button in the Okta configuration.
Select the radio button marked I’m an Okta customer adding an internal app .
Click the Finish button.
On the Okta application page, click the View Setup Instructions button in the middle of the page.
Note
The Okta setup instructions appear in a new browser tab.
In the Cloud Manager FMC , click the Finish button to return to the Identity Providers page. Click the Modify button for your newly created IdP .
Fill in the following text fields:
| FMC Data Field | Value |
|---|---|
| Issuer URI | Use the Identity Provider Issuer value from the Okta Setup Instructions page. |
| Single Sign-on URL | Use the Identity Provider Single Sign-On URL value from the Okta Setup Instructions page. |
Close the Okta setup instructions browser tab.
Click the Next button on the Cloud Manager FMC page.
Click the Finish button the FMC Edit Identity Provider page.
Mapping your domain to the IdP lets Cloud Manager know that users from your domain should be directed to the Login URL for your identity provider configuration.
When users visit the Cloud Manager login page, they enter their email address. If the email domain is associated with an IdP, they are sent to the Login URL for that IdP.
Important
You can map a single domain to multiple identity providers. If you do, users who log in using the MongoDB Cloud console are automatically redirected to the first matching IdP mapped to the domain.
To log in using an alternative identity provider, users must either:
Use the Federation Management Console to map your domain to the IdP :
Click Add a Domain .
On the Domains screen, click Add Domain .
Enter the following information for your domain mapping:
| Field | Description |
|---|---|
| Display Name | Name to easily identify the domain. |
| Domain Name | Domain name to map. |
Click Next .
Note
You can choose the verification method once. It cannot be modified. To select a different verification method, delete and recreate the domain mapping.
Select the appropriate tab based on whether you are verifying your domain by uploading an HTML file or creating a DNS TXT record:
Upload an HTML file containing a verification key to verify that you own your domain.
mongodb-site-verification.html
file
that Cloud Manager provides.
<https://host.domain>/mongodb-site-verification.html
.
Create a DNS TXT record with your domain provider to verify that you own your domain. Each DNS record associates a specific Cloud Manager organization with a specific domain.
Click DNS Record .
Click Next .
Copy the provided TXT record. The TXT record has the following form:
mongodb-site-verification=<32-character string>
Log in to your domain name provider (such as GoDaddy.com or networksolutions.com).
Add the TXT record that Cloud Manager provides to your domain.
Return to Cloud Manager and click Finish .
The Domains screen displays both unverified and verified domains you’ve mapped to your IdP . To verify your domain, click the target domain’s Verify button. Cloud Manager shows whether the verification succeeded in a banner at the top of the screen.
After successfully verifying your domain, use the Federation Management Console to associate the domain with Okta:
Important
Before you begin testing, copy and save the Bypass SAML Mode URL for your IdP . Use this URL to bypass federated authentication in the event that you are locked out of your Cloud Manager organization.
While testing, keep your session logged in to the Federation Management Console to further ensure against lockouts.
To learn more about Bypass SAML Mode , see Bypass SAML Mode .
Use the Federation Management Console to test the integration between your domain and Okta:
Example
If your verified domain is
mongodb.com
, enter
alice@mongodb.com
.
If you mapped your domain correctly, you’re redirected to your IdP to authenticate. If authenticating with your IdP succeeds, you’re redirected back to Cloud Manager.
Note
You can bypass the Cloud Manager log in page by navigating directly to your IdP ’s Login URL . The Login URL takes you directly to your IdP to authenticate.
Use the Federation Management Console to assign your domain’s users access to specific Cloud Manager organizations:
Click View Organizations .
Cloud Manager displays all organizations where you are an
Organization
Owner
.
Organizations which are not already connected to the Federation Application have Connect button in the Actions column.
Click the desired organization’s Connect button.
From the Organizations screen in the management console:
Click the Name of the organization you want to map to an IdP .
On the Identity Provider screen, click Apply Identity Provider .
Cloud Manager directs you to the Identity Providers screen which shows all IdPs you have linked to Cloud Manager.
For the IdP you want to apply to the organization, click Modify .
At the bottom of the Edit Identity Provider form, select the organizations to which this IdP applies.
Click Next .
Click Finish .
You can configure the following advanced options for federated authentication for greater control over your federated users and authentication flow:
Note
The following advanced options for federated authentication require you to map an organization .
All users you assigned to the Okta application can log in to Cloud Manager using their Okta credentials on the Login URL . Users have access to the organizations you mapped to your IdP .
Important
You can map a single domain to multiple identity providers. If you do, users who log in using the MongoDB Cloud console are automatically redirected to the first matching IdP mapped to the domain.
To log in using an alternative identity provider, users must either:
If you selected a default organization role, new users who log in to Cloud Manager using the Login URL have the role you specified.