This is one stop global knowledge base where you can learn about all the products, solutions and support features.
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.
On this page
The Automation uses an automation configuration to determine the desired state of a MongoDB deployment and to effect changes as needed. If you modify the deployment through the Cloud Manager web interface, you never need manipulate this configuration.
If you are using the Automation without Cloud Manager, you can construct and distribute the configuration manually.
Optional fields are marked as such.
A field that takes a
<number>
as its value can take integers and
floating point numbers.
This lists the version of the automation configuration.
"version" : "<integer>"
| Name | Type | Necessity | Description |
|---|---|---|---|
| version | integer | Required | Revision of this automation configuration file. |
Cloud Manager downloads automatic versions and runs starting scripts in the directory set in options.downloadBase .
"options" : {
"downloadBase" : "<string>",
}
| Name | Type | Necessity | Description |
|---|---|---|---|
| options | object | Required | Path for automatic downloads of new versions. |
| options.downloadBase | string | Required | Directory on Linux and UNIX platforms for automatic version downloads and startup scripts. |
The
mongoDbVersions[n]
array defines specification objects for
the MongoDB instances found in the
processes
array. Each
MongoDB instance in the
processes
array must have a
specification object in this array.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
"mongoDbVersions[n]" : [
{
"name" : "<string>",
"builds" : [
{
"platform" : "<string>",
"url" : "<string>",
"gitVersion" : "<string>",
"modules" : [ "<string>", ... ],
"architecture" : "<string>",
"bits" : "<integer>",
"win2008plus" : "<Boolean>",
"winVCRedistUrl" : "<string>",
"winVCRedistOptions" : [ "<string>", ... ],
"winVCRedistDll" : "<string>",
"winVCRedistVersion" : "<string>"
},
...
],
},
...
]
|
| Name | Type | Necessity | Description |
|---|---|---|---|
| mongoDbVersions[n] | array of objects | Required | Specification objects for the MongoDB instances found in the processes array. Each MongoDB instance in processes must have a specification object in mongoDbVersions[n] . |
| mongoDbVersions[n].name | string | Required | Name of the specification object. The specification object is attached to a MongoDB instance through the instance’s processes.version parameter in this configuration. |
| mongoDbVersions[n].builds[k] | array of objects | Required | Builds available for this MongoDB instance. |
| mongoDbVersions[n].builds[k].platform | string | Required | Platform for this MongoDB instance. |
| mongoDbVersions[n].builds[k].url | string | Required | URL from which to download MongoDB for this instance. |
| mongoDbVersions[n].builds[k].gitVersion | string | Required | Commit identifier that identifies the state of the code used to build the MongoDB process. The MongoDB buildInfo command returns the gitVersion identifier. |
| mongoDbVersions[n].builds[k].modules | array | Required | List of modules for this version. Corresponds to the modules parameter that the buildInfo command returns. |
| mongoDbVersions[n].builds[k].architecture | string | Required | Processor’s architecture. Cloud Manager accepts amd64 or ppc64le . |
| mongoDbVersions[n].builds[k].bits | integer | Deprecated | Processor’s bus width. Don’t remove or make modifications to this parameter. |
| mongoDbVersions[n].builds[k].win2008plus | Boolean | Optional | Set to true if this is a Windows build that requires either Windows 7 later or Windows Server 2008 R2 or later. |
| mongoDbVersions[n].builds[k].winVCRedistUrl | string | Optional | URL from which the required version of the Microsoft Visual C++ redistributable can be downloaded. |
| mongoDbVersions[n].builds[k].winVCRedistOptions | array of strings | Optional | String values that list the command-line options to be specified when running the Microsoft Visual C++ redistributable installer. Each command-line option is a separate string in the array. |
| mongoDbVersions[n].builds[k].winVCRedistDll | string | Optional | Name of the Microsoft Visual C++ runtime DLL file that the agent checks to determine if a new version of the Microsoft Visual C++ redistributable is needed. |
| mongoDbVersions[n].builds[k].winVCRedistVersion | string | Optional | Minimum version of the Microsoft Visual C++ runtime DLL that must be present to skip over the installation of the Microsoft Visual C++ redistributable. |
agentVersion specifies the version of the MongoDB Agent.
Note
While you can update the MongoDB Agent version through this configuration property, you should use the Update Agent Versions endpoint to ensure your versions are up to date.
"agentVersion" : {
"name" : "<string>",
"directoryUrl" : "<string>"
}
| Name | Type | Necessity | Description |
|---|---|---|---|
| agentVersion | object | Optional | Version of the MongoDB Agent to run. If the running version does not match this setting, the MongoDB Agent downloads the specified version, shuts itself down, and starts the new version. |
| agentVersion.name | string | Optional | Desired version of the MongoDB Agent. |
| agentVersion.directoryUrl | string | Optional | URL from which to download the MongoDB Agent. |
The monitoringVersions array specifies the version of the Monitoring Agent. Cloud Manager has made this parameter obsolete. To update the monitoring log settings, use the Update Monitoring Configuration Settings endpoint.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
"monitoringVersions" : [
{
"name" : "<string>",
"hostname" : "<string>",
"urls" : {
"<platform1>" : {
"<build1>" : "<string>",
...,
"default" : "<string>"
},
...
},
"baseUrl" : "<string>",
"logPath" : "<string>",
"logRotate" : {
"sizeThresholdMB" : <number>,
"timeThresholdHrs" : <integer>,
"numUncompressed": <integer>,
"percentOfDiskspace" : <number>,
"numTotal" : <integer>
}
},
...
]
|
| Name | Type | Necessity | Description |
|---|---|---|---|
| monitoringVersions | array of objects | Optional | Objects that define version information for each Monitoring Agent. |
| monitoringVersions.name | string | Required |
Version of the Monitoring Agent. See also MongoDB Compatibility Matrix Important This property is read-only. Any modifications made to this property are not reflected when updating the Monitoring Agent through the API . To update the Monitoring Agent version, use this endpoint . |
| monitoringVersions.hostname | string | Required | FQDN of the host that runs the Monitoring Agent. If the Monitoring Agent is not running on the host, Cloud Manager installs the agent from the location specified in monitoringVersions.urls . |
| monitoringVersions.urls | object | Required | Platform- and build-specific URL s from which to download the Monitoring Agent. |
| monitoringVersions.urls.<platform> | object | Required | Label that identifies an operating system and its version. The field contains an object with key-value pairs, where each key is either the name of a build or default and each value is a URL for downloading the Monitoring Agent. The object must include the default key set to the default download URL for the platform. |
| monitoringVersions.baseUrl | string | Required |
Base URL
used for the
mmsBaseUrl
setting.
|
| monitoringVersions.logPath | string | Optional | Directory where the agent stores its logs. The default is to store logs in /dev/null . |
| monitoringVersions.logRotate | object | Optional | Enables log rotation for the MongoDB logs for a process. |
| monitoringVersions.logRotate.sizeThresholdMB | number | Required | Maximum size in MB for an individual log file before rotation. |
| monitoringVersions.logRotate.timeThresholdHrs | integer | Required | Maximum time in hours for an individual log file before rotation. |
| monitoringVersions.logRotate.numUncompressed | integer | Optional | Maximum number of total log files to leave uncompressed, including the current log file. The default is 5 . In earlier versions of Cloud Manager, this field was named maxUncompressed . The earlier name is still recognized, though the new version is preferred. |
| monitoringVersions.logRotate.percentOfDiskspace | number | Optional | Maximum percentage of total disk space all log files should take up before deletion. The default is .02 . |
| monitoringVersions.logRotate.numTotal | integer | 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 monitoringVersions.logRotate settings. |
The backupVersions array specifies the version of the Backup Agent. Cloud Manager has made this parameter obsolete. To update the backup log settings, use the Update Backup Configuration Settings endpoint.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
"backupVersions[n]" : [
{
"name" : "<string>",
"hostname" : "<string>",
"urls" : {
"<platform1>" : {
"<build1>" : "<string>",
...,
"default" : "<string>"
},
...
},
"baseUrl" : "<string>",
"logPath" : "<string>",
"logRotate" : {
"sizeThresholdMB" : "<number>",
"timeThresholdHrs" : "<integer>",
"numUncompressed": "<integer>",
"percentOfDiskspace" : "<number>",
"numTotal" : "<integer>"
}
},
...
]
|
| Name | Type | Necessity | Description |
|---|---|---|---|
| backupVersions[n] | array of objects | Optional | Objects that define version information for each Backup Agent. |
| backupVersions[n].name | string | Required |
Version of the Backup Agent. See also MongoDB Compatibility Matrix Important This property is read-only. Any modifications made to this property are not reflected when updating the Backup Agent through the API . To update the Backup Agent version, see this endpoint . |
| backupVersions[n].hostname | string | Required | FQDN of the host that runs the Backup Agent. If the Backup Agent is not running on the host, Cloud Manager installs the agent from the location specified in backupVersions[n].urls . |
| backupVersions[n].urls | object | Required | Platform- and build-specific URL s from which to download the Backup Agent. |
| backupVersions[n].urls.<platform> | object | Required | Label that identifies an operating system and its version. The field contains an object with key-value pairs, where each key is either the name of a build or default and each value is a URL for downloading the Backup Agent. The object must include the default key set to the default download URL for the platform. |
| backupVersions[n].baseUrl | string | Required | Base URL used for the mothership and https settings in the Custom Settings . For example, for “baseUrl”=https://cloud.mongodb.com , the backup configuration fields would have these values: mothership=api-backup.mongodb.com and https”=true . |
| backupVersions[n].logPath | string | Optional | Directory where the agent stores its logs. The default is to store logs in /dev/null . |
| backupVersions[n].logRotate | object | Optional | Enables log rotation for the MongoDB logs for a process. |
| backupVersions[n].logRotate.sizeThresholdMB | number | Required | Maximum size in MB for an individual log file before rotation. |
| backupVersions[n].logRotate.timeThresholdHrs | integer | Required | Maximum time in hours for an individual log file before rotation. |
| backupVersions[n].logRotate.numUncompressed | integer | Optional | Maximum number of total log files to leave uncompressed, including the current log file. The default is 5 . |
| backupVersions[n].logRotate.percentOfDiskspace | number | Optional | Maximum percentage of total disk space all log files should take up before deletion. The default is .02 . |
| backupVersions[n].logRotate.numTotal | integer | Optional | If a number is not specified, the total number of log files defaults to 0 and is determined by other backupVersion.logRotate settings. |
The processes array determines the configuration of your MongoDB instances. Using this array, you can:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
"processes": [{
"<args>": {},
"alias": "<string>",
"authSchemaVersion": "<integer>",
"backupRestoreUrl": "<string>",
"cluster": "<string>",
"defaultRWConcern": {
"defaultReadConcern": {
"level": "<string>"
},
"defaultWriteConcern": {
"j": "<boolean>",
"w": "<string>",
"wtimeout": "<integer>"
}
}
"disabled": "<Boolean>",
"featureCompatibilityVersion": "<string>",
"hostname": "<string>",
"lastCompact" : "<dateInIso8601Format>",
"lastRestart" : "<dateInIso8601Format>",
"lastResync" : "<dateInIso8601Format>",
"lastKmipMasterKeyRotation" : "<dateInIso8601Format>",
"logRotate": {
"sizeThresholdMB": "<number>",
"timeThresholdHrs": "<integer>",
"numUncompressed": "<integer>",
"percentOfDiskspace": "<number>",
"numTotal": "<integer>"
},
"manualMode": "<Boolean>",
"name": "<string>",
"numCores": "<integer>",
"processType": "<string>",
"version": "<string>"
}]
|
| Name | Type | Necessity | Description |
|---|---|---|---|
| processes | array | Required |
Contains objects that define the
mongos
and
mongod
instances
that Cloud Manager monitors. Each object defines a different instance.
|
| processes[n].args2_6 | object | Required |
MongoDB configuration object for MongoDB versions 2.6 and later. See also Supported configuration options . |
| processes[n].alias | string | Optional | Hostname alias (often a DNS CNAME) for the host on which the process runs. If an alias is specified, the MongoDB Agent prefers this alias over the hostname specified in processes.hostname when connecting to the host. You can also specify this alias in replicaSets.host and sharding.configServer . |
| processes[n].authSchemaVersion | integer | Required |
Schema version of the user credentials for MongoDB database users. This should match all other elements of the processes array that belong to the same cluster.
See also Upgrade to SCRAM-SHA-1 in the MongoDB 3.0 release notes. |
| processes[n].backupRestoreUrl | string | Optional |
Delivery URL for the restore. Cloud Manager sets this when creating a restore. See also Automate Backup Restoration through the API . |
| processes[n].cluster | string | Conditional |
Name of the sharded cluster. Set this value to the same value in
the
sharding.name
parameter in the
sharding
array for
the
|
| defaultRWConcern.defaultReadConcern.level | string | Optional |
Consistency and isolation properties set for the data read from replica sets and replica set shards. MongoDB Atlas accepts the following values:
|
| defaultRWConcern.defaultWriteConcern.j | boolean | Optional | Flag that indicates whether the write acknowledgement must be written to the on-disk journal. |
| defaultRWConcern.defaultWriteConcern.w | string | Optional |
Desired number of mongod instances that must acknowledge a write operation in a replica sets and replica set shards. MongoDB Atlas accepts the following values:
|
| defaultRWConcern.defaultWriteConcern.wtimeout | number | Optional | Desired time limit for the write concern expressed in milliseconds. Set this value when you set defaultRWConcern.defaultWriteConcern.w to a value greater than 1 . |
| processes[n].disabled | Boolean | Optional | Flag that indicates if this process should be shut down. Set to true to shut down the process. |
| processes[n].featureCompatibilityVersion | string | Required |
Version of MongoDB with which this process has feature compatibility. Changing this value can enable or disable certain features that persist data incompatible with MongoDB versions earlier or later than the featureCompatibilityVersion you choose.
See also setFeatureCompatibilityVersion |
| processes[n].hostname | string | Required | Name of the host that serves this process. This defaults to localhost . |
| processes[n].lastCompact | string | Optional |
Timestamp in ISO 8601 date and time format in UTC when Cloud Manager last reclaimed free space on a cluster’s disks. During certain operations, MongoDB might move or delete data but it doesn’t free the currently unused space. Cloud Manager reclaims the disk space in a rolling fashion across members of the replica set or shards. To reclaim this space:
To remove any ambiguity as to when you intend to reclaim the
space on the cluster’s disks, specify a time zone with your
ISO 8601 timestamp. For example, to set
processes.lastCompact
to 28 January 2021 at 2:43:52 PM US Central Standard Time, use
|
| processes[n].lastRestart | string | Optional | Timestamp in ISO 8601 date and time format in UTC when Cloud Manager last restarted this process. If you set this parameter to the current timestamp, Cloud Manager forces a restart of this process after you upload this configuration. If you set this parameter for multiple processes in the same cluster, the Cloud Manager restarts the selected processes in a rolling fashion across members of the replica set or shards. |
| processes[n].lastResync | string | Optional |
Timestamp in ISO 8601 date and time format in UTC of the last initial sync process that Cloud Manager performed on the node. To trigger the init sync process on the node immediately, set this value to the current time as an ISO 8601 timestamp. Warning
Use this parameter with caution. During
initial sync,
Automation removes the entire contents of the node’s
If you set this parameter:
See also Initial Sync |
| processes[n].lastKmipMasterKeyRotation | string | Optional | Timestamp in ISO 8601 date and time format in UTC when Cloud Manager last rotated the master KMIP key. If you set this parameter to the current timestamp, Cloud Manager rotate the key after you upload this configuration. |
| processes[n].logRotate | object | Optional | MongoDB configuration object for rotating the MongoDB logs of a process. |
| processes[n].logRotate. numTotal | integer | Optional | Total number of log files that Cloud Manager retains. If you don’t set this value, the total number of log files defaults to 0 . Cloud Manager bases rotation on your other processes.logRotate settings. |
| processes[n].logRotate. numUncompressed | integer | Optional | Maximum number of total log files to leave uncompressed, including the current log file. The default is 5 . |
| processes[n].logRotate. percentOfDiskspace | number | Optional |
Maximum percentage of total disk space that Cloud Manager can use to store the log files expressed as decimal. If this limit is exceeded, Cloud Manager deletes compressed log files until it meets this limit. Cloud Manager deletes the oldest log files first. The default is 0.02 . |
| processes[n].logRotate. sizeThresholdMB | number | Required | Maximum size in MB for an individual log file before Cloud Manager rotates it. Cloud Manager rotates the log file immediately if it meets the value given in either this sizeThresholdMB or the processes.logRotate.timeThresholdHrs limit. |
| processes[n].logRotate. timeThresholdHrs | integer | Required |
Maximum duration in hours for an individual log file before the next rotation. The time is since the last rotation. Cloud Manager rotates the log file once the file meets either this timeThresholdHrs or the processes.logRotate.sizeThresholdMB limit. |
| processes[n].manualMode | Boolean | Optional |
Flag that indicates if MongoDB Agent automates this process.
|
| processes[n].name | string | Required | Unique name to identify the instance. |
| processes[n].numCores | integer | Optional | Number of cores that Cloud Manager should bind to this process. The MongoDB Agent distributes processes across the cores as evenly as possible. |
| processes[n].processType | string | Required |
Type of MongoDB process being run. Cloud Manager accepts
mongod
or
mongos
for this parameter.
|
| processes[n].version | string | Required | Name of the mongoDbVersions specification used with this instance. |
clusterWideConfigurations specifies the parameters to set across a replica set or sharded cluster without requiring a rolling restart .
1 2 3 4 5 6 7 8 9 |
"clusterWideConfigurations" : {
"<replicaSetID/clusterName>": {
"changeStreamOptions": {
"preAndPostImages": {
"expireAfterSeconds": <integer>
}
}
}
}
|
| Name | Type | Necessity | Description |
|---|---|---|---|
| replicaSetID/clusterName | object | Optional | The change stream options to apply to the replica set or sharded cluster. MongoDB Agent only checks if this configuration is in a valid JSON format but doesn’t check the values for correctness. |
| changeStreamOptions.preAndPostImages.expireAfterSeconds | number | Required |
Retention policy of change stream pre- and post-images in seconds. If you omit the value, the cluster retains the pre- and post-images until it removes the corresponding change stream events from the oplog. If you remove this value, MongoDB Agent only removes this parameter from its automation configuration, but not from the server. See also changeStreamOptions. |
The replicaSets array defines each replica set’s configuration. This field is required for deployments with replica sets.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
"replicaSets":
[
{
"_id": "<string>",
"protocolVersion": "<string>",
"members":
[
{
"_id": "<integer>",
"host": "<string>",
"arbiterOnly": "<boolean>",
"buildIndexes": "<boolean>",
"hidden": "<boolean>",
"priority": "<number>",
"tags": "<object>",
"secondaryDelaySecs": "<integer>",
"votes": "<number>"
},{
"_id": "<integer>",
"host": "<string>",
"arbiterOnly": "<boolean>",
"buildIndexes": "<boolean>",
"hidden": "<boolean>",
"priority": "<number>",
"tags": "<object>",
"secondaryDelaySecs": "<integer>",
"votes": "<number>"
},{
"_id": "<integer>",
"host": "<string>",
"arbiterOnly": "<boolean>",
"buildIndexes": "<boolean>",
"hidden": "<boolean>",
"priority": "<number>",
"tags": "<object>",
"secondaryDelaySecs": "<integer>",
"votes": "<number>"
}
],
"force":
{
"currentVersion": "<integer>"
}
}
]
|
| Name | Type | Necessity | Description |
|---|---|---|---|
| replicaSets | array | Optional |
Configuration of each replica set . The MongoDB Agent uses the values in this array to create valid replica set configuration documents . The agent regularly checks that replica sets are configured correctly. If a problem occurs, the agent reconfigures the replica set according to its configuration document. The array can contain the following top-level fields from a replica set configuration document: _id ; version ; and members . See also replSetGetConfig |
| replicaSets[n]._id | string | Required | The name of the replica set. |
| replicaSets[n].protocolVersion | string | Optional | Protocol version of the replica set. |
| replicaSets[n].members | array | Optional |
Objects that define each member of the replica set. The members.host field must specify the host’s name as listed in processes.name . The MongoDB Agent expands the host field to create a valid replica set configuration. See also replSetGetConfig. |
| replicaSets[n].members[m]._id | integer | Optional | Any positive integer that indicates the member of the replica set. |
| replicaSets[n].members[m].host | string | Optional | Hostname, and port number when applicable, that serves this replica set member. |
| replicaSets[n].members[m].arbiterOnly | boolean | Optional | Flag that indicates whether this replica set member acts as an arbiter. |
| replicaSets[n].members[m].buildIndexes | boolean | Optional |
Flag that indicates whether the
mongod
process builds indexes
on this replica set member.
|
| replicaSets[n].members[m].hidden | boolean | Optional | Flag that indicates whether the replica set allows this member to accept read operations. |
| replicaSets[n].members[m].priority | number | Optional | Relative eligibility for Cloud Manager to select this replica set member as a primary. Larger number increase eligibility. This value can be between 0 and 1000, inclusive for data-bearing nodes. Arbiters can have values of 0 or 1. |
| replicaSets[n].members[m].tags | object | Optional | List of user-defined labels and their values applied to this replica set member. |
| replicaSets[n].members[m].secondaryDelaySecs | integer | Optional | Amount of time in seconds that this replica set memberr should lag behind the primary. |
| replicaSets[n].members[m].votes | number | Optional | Quantity of votes this replica set member can cast for a replica set election. All data bearing nodes can have 0 or 1 votes. Arbiters always have 1 vote. |
| replicaSets[n].force | object | Optional |
Instructions to the MongoDB Agent to force a replica set to use the Configuration Version specified in replicaSets.force.CurrentVersion . With this object, the MongoDB Agent can force a replica set to accept a new configuration to recover from a state in which a minority of its members are available. |
| replicaSets[n].force.currentVersion | integer | Optional |
Configuration Version that the MongoDB Agent forces the replica set to use. Set to -1 to force a replica set to accept a new configuration. Warning Forcing a replica set reconfiguration might lead to a rollback of majority-committed writes. Proceed with caution. Contact MongoDB Support if you have questions about the potential impacts of this operation. |
The sharding array defines the configuration of each sharded cluster. This parameter is required for deployments with sharded clusters.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 |
"sharding" : [
{
"managedSharding" : <boolean>,
"name" : "<string>",
"configServerReplica" : "<string>",
"collections" : [
{
"_id" : "<string>",
"key" : [
[ "shard key" ],
[ "shard key" ],
...
],
"unique" : <boolean>
},
...
],
"shards" : [
{
"_id" : "<string>",
"rs" : "<string>",
"tags" : [ "<string>", ... ]
},
...
],
"tags" : [
{
"ns" : "<string>",
"min" : [
{
"parameter" : "<string>",
"parameterType" : "<string>",
"value" : "<string>"
}
],
"max" : [
{
"parameter" : "<string>",
"parameterType" : "<string>",
"value" : "<string>"
}
],
"tag" : "<string>"
},
...
]
},
...
]
|
| Name | Type | Necessity | Description |
|---|---|---|---|
| sharding | array of objects | Optional | Objects that define the configuration of each sharded cluster . Each object in the array contains the specifications for one cluster. The MongoDB Agent regularly checks each cluster’s state against the specifications. If the specification and cluster don’t match, the agent will change the configuration of the cluster, which might cause the balancer to migrate chunks. |
| sharding.managedSharding | boolean | Conditional | Flag that indicates whether Cloud Manager Automation manages all sharded collections and tags in the deployment |
| sharding.name | string | Conditional |
Name of the cluster. This must correspond with the value in
processes.cluster
for a
mongos
.
|
| sharding.configServerReplica | string | Conditional |
Name of the config server replica set . You can add this array parameter if your config server runs as a replica set. If you run legacy mirrored config servers that don’t run as a replica set, use sharding.configServer . |
| sharding.configServer | array of strings | Conditional |
Names of the config server hosts. The host names match the names used in each host’s processes.name parameter. If your sharded cluster runs MongoDB 3.4 or later, use sharding.configServerReplica . Important MongoDB 3.4 removes support for mirrored config servers. |
| sharding.collections | array of objects | Conditional | Objects that define the sharded collections and their shard keys . |
| sharding.collections._id | string | Conditional | namespace of the sharded collection. The namespace is the combination of the database name and the name of the collection. For example, testdb.testcoll . |
| sharding.collections.key | array of arrays | Conditional |
Collection’s shard keys . It contains:
|
| sharding.collections.unique | boolean | Conditional | Flag that indicates whether MongoDB enforces uniqueness for the shard key. |
| sharding.shards | array of objects | Conditional | Cluster’s shards . |
| sharding.shards._id | string | Conditional | Name of the shard. |
| sharding.shards.rs | string | Conditional | Name of the shard’s replica set. This is specified in the replicaSets._id parameter. |
| sharding.shards.tags | array of strings | Conditional |
Zones assigned to this shard. You can add this array parameter if you use zoned sharding. |
| sharding.tags | array of objects | Conditional | Definition of zones for zoned sharding. Each object in this array defines a zone and configures the shard key range for that zone. |
| sharding.tags.ns | string | Conditional |
Namespace of the collection that uses zoned sharding. The namespace combines the database name and the name of the collection. Example testdb.testcoll |
| sharding.tags.min | array | Conditional |
Minimum value of the shard key range. Specify the field name, field type, and value in a document of the following form. {
"field" : <string>,
"fieldType" : <string>,
"value" : <string>
}
To use a compound shard key, specify each field in a separate document, as shown in the example after this table. For more information on shard keys, see Shard Keys in the MongoDB manual. |
| sharding.tags.max | array | Conditional |
Maximum value of the shard key range. Specify the field name, field type, and value in a document of the following form. {
"field" : <string>,
"fieldType" : <string>,
"value" : <string>
}
To use a compound shard key, specify each field in a separate document, as shown in the example after this table. For more information on shard keys, see Shard Keys in the MongoDB manual. |
| sharding.tags.tag | string | Conditional | Name of the zone associated with the shard key range specified by sharding.tags.min and sharding.tags.max . |
Example
The sharding.tags Array with Compound Shard Key
The following example configuration defines a compound shard key range with a min value of { a : 1, b : ab } and a max value of { a : 100, b : fg } . The example defines the range on the testdb.test1 collection and assigns it to zone zone1 .
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
"tags" : [
{
"ns" : "testdb.test1",
"min" : [
{
"parameter" : "a",
"parameterType" : "integer",
"value" : "1"
},
{
"parameter" : "b",
"parameterType" : "string",
"value" : "ab"
}
],
"max" : [
{
"parameter" : "a",
"parameterType" : "integer",
"value" : "100"
},
{
"parameter" : "b",
"parameterType" : "string",
"value" : "fg"
}
],
"tag" : "zone1"
}
]
|
The balancer object is optional and defines balancer settings for each cluster.
1 2 3 4 5 |
"balancer": {
"<clusterName1>": {},
"<clusterName2>": {},
...
}
|
| Name | Type | Necessity | Description |
|---|---|---|---|
| balancer | object | Optional | Parameters named according to clusters, each parameter containing an object with the desired balancer settings for the cluster. The object uses the stopped and activeWindow parameters, as described in the procedure to schedule the balancing window in this tutorial in the MongoDB manual. |
Cloud Manager doesn’t require the
auth
object. This object defines
authentication-related settings.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
{
"auth": {
"authoritativeSet": "<boolean>",
"autoUser": "<string>",
"autoPwd": "<string>",
"disabled": "<boolean>",
"deploymentAuthMechanisms": ["<string>", "<string>"],
"autoAuthMechanisms": ["<string>"],
"key": "<string>",
"keyfile": "<string>",
"newAutoPwd": "<string>",
"newKey": "<string>",
"usersDeleted": [{
"user": "<string>",
"dbs": ["<string>", "<string>"]
}],
"usersWanted": [{
"authenticationRestrictions": [{
"clientSource": ["(IP | CIDR range)", "(IP | CIDR range)"],
"serverAddress": ["(IP | CIDR range)", "(IP | CIDR range)"]
}],
"db": "<string>",
"initPwd": "<string>",
"otherDBRoles": {
"<string>": ["<string>", "<string>"]
},
"roles": [{
"db": "<string>",
"role": "<string>"
}],
"pwd": "<string>",
"user": "<string>"
}]
}
}
|
| Name | Type | Necessity | Description | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| auth | object | Optional |
Defines authentication-related settings. Note If you omit this parameter, skip the rest of this section. |
||||||||||||
| auth.authoritativeSet | boolean | Conditional |
Sets whether or not Cloud Manager enforces a consistent set of managed MongoDB users and roles in all managed deployments in the project.
auth.authoritativeSet defaults to false . Required if “auth” : true . |
||||||||||||
| auth.autoUser | string | Conditional |
Username that the Automation uses when connecting to an instance. Required if “auth” : true . |
||||||||||||
| auth.autoPwd | string | Conditional |
Password that the Automation uses when connecting to an instance. Required if “auth” : true . |
||||||||||||
| auth.disabled | boolean | Optional | Flag indicating if auth is disabled. If not specified, disabled defaults to false . | ||||||||||||
| auth.deploymentAuthMechanisms | array of strings | Conditional |
Lists the supported authentication mechanisms for the processes in the deployment. Required if “auth” : true . Specify:
|
||||||||||||
| auth.autoAuthMechanisms | array of strings | Conditional |
Sets the authentication mechanism used by the Automation. If not specified, disabled defaults to false . Required if “auth” : true . Note This parameter contains more than one element only when it’s configured for both SCRAM-SHA-1 and SCRAM-SHA-256. Specify:
|
||||||||||||
| auth.key | string | Conditional |
Contents of the key file that Cloud Manager uses to authenticate to the MongoDB processes. Required if “auth” : true and “auth.disabled” : false . Note If you change the auth.key value, you must change the auth.keyfile value. |
||||||||||||
| auth.keyfile | string | Conditional |
Path and name of the key file that Cloud Manager uses to authenticate to the MongoDB processes. Required if “auth” : true and “auth.disabled” : false . Note If you change the auth.keyfile value, you must change the auth.key value. |
||||||||||||
|
auth
.newAutoPwd
|
string | Optional |
New password that the Automation uses when connecting to an instance. To rotate passwords without losing the connection:
Note You can set this option only when you include SCRAM-SHA-1 or SCRAM-SHA-256 as one of the authentication mechanisms for the Automation in auth.autoAuthMechanisms . |
||||||||||||
| auth.newKey | string | Optional |
Contents of a new key file that you want Cloud Manager to use to authenticate to the MongoDB processes. When you set this option, Cloud Manager rotates the key that the application uses to authenticate to the MongoDB processes in your deployment. When all MongoDB Agents use the new key, Cloud Manager replaces the value of auth.key with the new key that you provided in auth.newKey and removes auth.newKey from the automation configuration. |
||||||||||||
| auth.usersDeleted | array of objects | Optional | Objects that define the authenticated users to be deleted from specified databases or from all databases. This array must contain auth.usersDeleted.user and auth.usersDeleted.dbs . | ||||||||||||
| auth.usersDeleted[n].user | string | Optional | Username of user that Cloud Manager should delete. | ||||||||||||
| auth.usersDeleted[n].dbs | array of strings | Optional | List the names of the databases from which Cloud Manager should delete the authenticated user. | ||||||||||||
| auth.usersWanted | array of objects | Optional | Contains objects that define authenticated users to add to specified databases. Each object must have the auth.usersWanted[n].db , auth.usersWanted[n].user , and auth.usersWanted[n].roles parameters, and then have exactly one of the following parameters: auth.usersWanted[n].pwd , auth.usersWanted[n].initPwd , or auth.usersWanted[n].userSource . | ||||||||||||
| auth.usersWanted[n].db | string | Conditional | Database to which to add the user. | ||||||||||||
| auth.usersWanted[n].user | string | Conditional | Name of the user that Cloud Manager should add. | ||||||||||||
| auth.usersWanted[n].roles | array | Conditional | List of the roles to be assigned to the user from the user’s database, which is specified in auth.usersWanted[n].db . | ||||||||||||
| auth.usersWanted[n].pwd | string | Conditional |
32-character hex SCRAM-SHA-1 hash of the password currently assigned to the user. Cloud Manager doesn’t use this parameter to set or change a password. Required if:
|
||||||||||||
| auth.usersWanted[n].initPwd | string | Conditional |
Cleartext password that you want to assign to the user. Required if:
|
||||||||||||
| auth.usersWanted[n].userSource | string | Deprecated | No longer supported. | ||||||||||||
| auth.usersWanted[n].otherDBRoles | object | Optional | If you assign the user’s database “auth.usersWanted[n].db” : “admin” , then you can use this object to assign the user roles from other databases as well. The object contains key-value pairs where the key is the name of the database and the value is an array of string values that list the roles be assigned from that database. | ||||||||||||
| auth.usersWanted[n].authenticationRestrictions | array of documents | Optional |
Authentication restrictions that the host enforces on the user. Warning
If a user inherits multiple roles with incompatible authentications
restrictions, that user becomes unusable. For example, if a user
inherits one role in which the
For more information about authentication in MongoDB, see Authentication. |
||||||||||||
| auth.usersWanted[n].authenticationRestrictions[k].clientSource | array of strings | Conditional | If present when authenticating a user, the host verifies that the given list contains the client’s IP address CIDR range. If the client’s IP address is not present, the host does not authenticate the user. | ||||||||||||
| auth.usersWanted[n].authenticationRestrictions[k].serverAddress | array of strings | Conditional | Comma-separated array of IP addresses to which the client can connect. If present, the host verifies that Cloud Manager accepted the client’s connection from an IP address in the given array. If the connection was accepted from an unrecognized IP address, the host doesn’t authenticate the user. |
The ssl object enables TLS for encrypting connections. This object is optional.
"ssl" : {
"CAFilePath" : "<string>"
}
| Name | Type | Necessity | Description |
|---|---|---|---|
| ssl | object | Optional |
Enables TLS for encrypting connections. To use TLS , choose a package that supports TLS . All platforms that support MongoDB Enterprise also support TLS . |
| ssl.clientCertificateMode | string | Conditional | Indicates whether connections to Cloud Manager require a TLS certificate. The values are OPTIONAL and REQUIRE . |
| ssl.CAFilePath | string | Conditional |
Absolute file path to the certificate used to authenticate through TLS on a Linux or UNIX host. Cloud Manager requires either ssl.CAFilePath or ssa.CAFilePathWindows if:
|
| ssl.CAFilePathWindows | string | Conditional |
Absolute file path to the certificate used to authenticate through TLS on a Windows host. Cloud Manager requires either ssl.CAFilePath or ssa.CAFilePathWindows if:
|
| ssl.autoPEMKeyFilePath | string | Conditional |
Absolute file path to the client private key (PEM) file that authenticates the TLS connection on a Linux or UNIX host. Cloud Manager requires either ssl.autoPEMKeyFilePath or ssa.autoPEMKeyFilePathWindows if you’re using TLS or X.509 authentication. |
| ssl.autoPEMKeyFilePathWindows | string | Conditional |
Absolute file path to the client private key (PEM) file that authenticates the TLS connection on a Windows host. Cloud Manager requires either ssl.autoPEMKeyFilePath or ssa.autoPEMKeyFilePathWindows if you’re using TLS or X.509 authentication. |
| ssl.autoPEMKeyFilePwd | string | Conditional | Password for the private key (PEM) file specified in ssl.autoPEMKeyFilePath or ssa.autoPEMKeyFilePathWindows . Cloud Manager requires this password if the PEM file is encrypted. |
The
roles
array is optional and describes user-defined roles.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
"roles" : [
{
"role" : "<string>",
"db" : "<string>",
"privileges" : [
{
"resource" : { ... },
"actions" : [ "<string>", ... ]
},
...
],
"roles" : [
{
"role" : "<string>",
"db" : "<string>"
}
]
"authenticationRestrictions" : [
{
"clientSource": [("<IP>" | "<CIDR range>"), ...],
"serverAddress": [("<IP>" | "<CIDR range>"), ...]
}, ...
]
},
...
]
|
| Name | Type | Necessity | Description |
|---|---|---|---|
| roles | array of objects | Optional | Roles and privileges that MongoDB has assigned to a cluster’s user-defined roles. Each object describes a different user-defined role. Objects in this array contain the same fields as documents in the system roles collection, except for the _id field. |
| roles[n].role | string | Conditional | Name of the user-defined role. |
| roles[n].db | string | Conditional | Database to which the user-defined role belongs. |
| roles[n].privileges | array of documents | Conditional | Privileges this role can perform. |
| roles[n].privileges[k].resource | string | Conditional | Specifies the resources upon which the privilege actions apply. |
| roles[n].privileges[k].actions | string | Conditional |
Actions permitted on the resource. See also Privilege Actions |
| roles[n].roles | array of documents | Conditional | Roles from which this role inherits privileges. |
| roles[n].authenticationRestrictions | array of documents | Optional |
Authentication restrictions that the MongoDB server enforces on this role. Warning
If a user inherits multiple roles with incompatible authentications
restrictions, that user becomes unusable. For example, if a user
inherits one role in which the
For more information about authentication in MongoDB, see Authentication. |
| roles[n].authenticationRestrictions[k].clientSource | array of strings | Conditional | If present, when authenticating a user, the MongoDB server verifies that the client’s IP address is either in the given list or belongs to a CIDR range in the list. If the client’s IP address is not present, the MongoDB server does not authenticate the user. |
| roles[n].authenticationRestrictions[k].serverAddress | array of strings | Conditional | Comma-separated array of IP addresses to which the client can connect. If present, the MongoDB server verifies that it accepted the client’s connection from an IP address in the given array. If the MongoDB server accepts a connection from an unrecognized IP address, the MongoDB server does not authenticate the user. |
The kerberos object is optional and defines a kerberos service name used in authentication.
"kerberos": {
"serviceName": "<string>"
}
| Name | Type | Necessity | Description |
|---|---|---|---|
| kerberos | object | Optional | Key-value pair that defines the kerberos service name agents use to authenticate via kerberos. |
| kerberos.serviceName | string | Required |
Label that sets:
|
The indexConfigs array is optional and defines indexes to be built for specific replica sets.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
"indexConfigs": [{
"key": [
["<string>", "<value>"]
],
"rsName": "<string>",
"dbName": "<string>",
"collectionName": "<string>",
"collation": {
"locale": "<string>",
"caseLevel": <boolean>,
"caseFirst": "<string>",
"strength": <number>,
"numericOrdering": <boolean>,
"alternate": "<string>",
"maxVariable": "<string>",
"normalization": <boolean>,
"backwards": <boolean>
},
"options": {
"<key>": "<value>"
}
}]
|
| Name | Type | Necessity | Description | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| indexConfigs | array of objects | Optional | Specific indexes to be built for specific replica sets. | |||||||||
| indexConfigs.key | array of arrays | Required | Keys in the index. This “array of arrays” contains a single array if the index has just one key. | |||||||||
| indexConfigs.rsName | string | Required | Replica set on which MongoDB builds the index. | |||||||||
| indexConfigs.dbName | string | Required | Database that MongoDB indexes. | |||||||||
| indexConfigs.collectionName | string | Required | Collection that MongoDB indexes. | |||||||||
| indexConfigs.collation | object | Optional |
Language-specific rules to use when sorting and matching strings if the index uses collation. If you include the indexConfigs.collation object, you must include the indexConfigs.collation.locale parameter. All other parameters are optional. If you don’t include the indexConfigs.collation object, the index can’t include collation. |
|||||||||
| indexConfigs.collation.locale | string | Required |
Locale that the ICU defines. The MongoDB Server Manual lists the supported locales in its Collation Locales and Default Parameters section. To specify simple binary comparison, set this value to simple . |
|||||||||
| indexConfigs.collation.caseLevel | boolean | Optional |
Flag that indicates how the index uses case comparison. If you set this parameter to true , the index uses case comparison. This parameter applies only if you set indexConfigs.collation.strength to 1 or 2 . See also Collation |
|||||||||
| indexConfigs.collation.caseFirst | string | Optional |
Sort order of case differences during tertiary level comparisons. The MongoDB Server Manual lists the possible values in its Collation section. |
|||||||||
| indexConfigs.collation.strength | number | Optional |
Level of comparison to perform. Corresponds to ICU Comparison Levels. The MongoDB Server Manual lists the possible values in its Collation section. |
|||||||||
| indexConfigs.collation.numericOrdering | boolean | Optional |
Flag that indicates how to compare numeric strings.
The default is false . See also Collation |
|||||||||
| indexConfigs.collation.alternate | string | Optional |
Setting that determines how collation should consider whitespace and punctuation as base characters during comparisons. The MongoDB Server Manual lists the possible values in its Collation section. |
|||||||||
| indexConfigs.collation.maxVariable | string | Optional |
Characters the index can ignore. This parameter applies only if indexConfigs.collation.alternate is set to shifted . The MongoDB Server Manual lists the possible values in its Collation section. |
|||||||||
| indexConfigs.collation.normalization | boolean | Optional |
Flag that indicates if the text should be normalized. If you set this parameter to true , collation:
The default is false . See also Collation |
|||||||||
| indexConfigs.collation.backwards | boolean | Optional |
Flag that indicates how the index should handle diacritic strings. If you set this parameter to true , strings with diacritics sort from the back to the front of the string. The default is false . See also Collation |
|||||||||
| indexConfigs.options | document | Required | Index options that the MongoDB Go Driver supports. |