This is one stop global knowledge base where you can learn about all the products, solutions and support features.
This document addresses common questions about Cloud Manager and its use.
On this page
Cloud Manager can automate operations for the MongoDB processes running on your hosts. Cloud Manager can both discover existing processes and deploy new ones.
Cloud Manager Automation relies on an Automation Agent, which must be installed on every server that runs a monitored MongoDB deployment. The Automation Agents periodically poll Cloud Manager to determine the goal configuration, deploy changes as needed, and report deployment status back to Cloud Manager.
Install the MongoDB Agent on each host that you want Cloud Manager to manage. The following procedure applies to all operating systems.
Instructions for a specific operating system can be read on Install MongoDB Agent .
On Linux hosts, if you installed MongoDB with a package manager, use the same package manager to install the MongoDB Agent. If you installed MongoDB without a package manager, use an archive to install the MongoDB Agent.
Once you have installed the MongoDB Agent to all your hosts, you can deploy your first replica set , cluster , or standalone .
On this page
new
Groups are now projects.
In Cloud Manager, MongoDB deployments are associated with projects.
You can create multiple projects in an organization. Each project has its own Monitoring, Backup and Automations associated with the project.
Projects within the same organization share the same billing settings.
For a project, the Monitoring must be able to connect to all hosts it monitors. If you have multiple MongoDB deployments in distinct environments and cannot monitor all deployments with a single agent (for instance, if your environments are separated by firewalls), you will need to add new projects.
You can also use multiple projects and agents if you want to separately monitor different MongoDB deployments that run in the same environment.
Important
Organization
Owner
or an
Organization
Project
Creator
.
Project
Owner
of the project.
You can also expand the Projects menu in the navigation bar, then click + New Project .
To learn more about MongoDB Atlas, see https://www.mongodb.com/cloud.
If you selected an MongoDB Atlas project, enter a name for the Organization .
If managing Cloud Manager users through LDAP , enter values for the following Optional LDAP Configuration fields .
Important
Multiple LDAP Groups Can Map to One Role
Cloud Manager roles can include more than one LDAP group. Type
multiple LDAP group names in the relevant role fields separated
by two semicolons (
;;
).
Field | Action |
---|---|
LDAP Groups for Project Owner Role |
Type the LDAP group(s) to which the Project Owners of the
Cloud Manager project belong. You can type multiple LDAP groups into
this field if they are separated by two semicolons (
;;
).
|
LDAP Groups for Automation Admin Role |
Type the LDAP group(s) to which Cloud Manager project’s Automation
Administrators belong. You can type multiple LDAP groups
into this field if they are separated by two semicolons
(
;;
).
|
LDAP Groups for Backup Admin Role |
Type the LDAP group(s) to which Cloud Manager project’s Backup
Administrators belong. You can type multiple LDAP groups
into this field if they are separated by two semicolons
(
;;
).
|
LDAP Groups for Monitoring Admin Role |
Type the LDAP group(s) to which Cloud Manager project’s Monitoring
Administrators belong. You can type multiple LDAP groups
into this field if they are separated by two semicolons
(
;;
).
|
LDAP Groups for User Admin Role |
Type the LDAP group(s) to which Cloud Manager project’s User
Administrators belong. You can type multiple LDAP groups
into this field if they are separated by two semicolons
(
;;
).
|
LDAP Groups for Read Only Role |
Type the LDAP group(s) to which Cloud Manager project’s Read Only
Users belong. You can type multiple LDAP groups into this
field if they are separated by two semicolons (
;;
).
|
For existing Cloud Manager users, enter their username. Usually, this is the email the person used to register.
For new Cloud Manager users, enter their email address to send an invitation.
Important
Deleting a project removes all the project’s artifacts, including all monitoring data. Cloud Manager no longer displays the project in selection lists.
You can delete a project if:
Project
Owner
access for the project.
Click the trash icon button for the project you wish to delete to open the Delete Project modal.
Agent | Procedure |
---|---|
Automations | Stop the agent’s process on each server. |
Monitoring | See Stop the Monitoring Agent and Remove Monitoring Agents from Cloud Manager . |
Backup | See Stop the Backup Agent and Remove the Backup Agent from Cloud Manager . |
Use the following procedures to modify projects:
Base URL:
https://cloud.mongodb.com/api/public/v1.0
POST /users/{USER-ID}/whitelist
Parameter | Type | Description |
---|---|---|
USER-ID | string | (Required.) Unique identifier of the current user. To retrieve the ID of the current user, see Get All Users in One Project . |
The following query parameters are optional:
Name | Type | Necessity | Description | Default |
---|---|---|---|---|
pageNum | number | Optional | One-based integer that returns a subsection of results. |
1
|
itemsPerPage | number | Optional | Number of items to return per page, up to a maximum of 500. |
100
|
pretty | boolean | Optional | Flag that indicates whether the response body should be in a prettyprint format. |
false
|
envelope | boolean | Optional |
Flag that indicates whether or not to wrap the response in an envelope.
Some
API
clients cannot access the
HTTP
response headers or
status code. To remediate this, set
For endpoints that return a list of results, the
|
false
|
The request body must be an array of whitelist entities, even if there is only one. The only field that you need to specify for each request object is the IP-ADDRESS .
If an IP address is already in the whitelist, it will be ignored.
If you specify a single IP address with the
/32
subnet mask, Cloud Manager
does not store the
/32
, as the
/32
does not change the address.
Example
An address of
12.34.56.78
is the same as
12.34.56.78/32
.
Parameter | Type | Description |
---|---|---|
ipAddress | string | (Required.) The IP address or CIDR block that you want to add to the specified user’s whitelist. |
The response JSON document includes an array of result objects, an array of link objects and a count of the total number of result objects retrieved.
Name | Type | Description |
---|---|---|
results
|
array | Array includes one object for each item detailed in the results Embedded Document section. |
links
|
array | Array includes one or more links to sub-resources and/or related resources. The relations between URL s are explained in the Web Linking Specification . |
totalCount
|
number | Integer count of the total number of items in the result set. It may be greater than the number of objects in the results array if the entire result set is paginated. |
Each result is one whitelist.
Name | Type | Description |
---|---|---|
cidrBlock
|
string | A CIDR-notated range of IP addresses. |
created
|
date | The date this IP address was added to the whitelist. |
ipAddress
|
string | A whitelisted IP address. |
lastUsed
|
date | The date of the most recent request that originated from this IP address. Note that this field is only updated when a whitelisted resource is accessed. |
lastUsedAddress
|
string | The address from which the last call to the API was issued. |
count
|
number | The total number of requests that originated from this IP address. Note that this field is only updated when a resource that is protected by the whitelist is accessed. |
links
|
array |
Links to related sub-resources. All links arrays in responses
contain at least one link called
self
. The relations between
URLs are explained in the Web Linking Specification.
|
curl --user '{PUBLIC-KEY}:{PRIVATE-KEY}' --digest \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--include \
--request POST "https://cloud.mongodb.com/api/public/v1.0/users/{USER-ID}/whitelist" --data '
[
{
"ipAddress" : "192.0.1.15",
"comment" : "IP address for Application Server A"
},
{
"cidrBlock" : "192.0.2.0/24",
"comment" : "CIDR block for Application Server B - D"
}
]'
HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=ISO-8859-1
Date: {dateInUnixFormat}
WWW-Authenticate: Digest realm="MMS Public API", domain="", nonce="{nonce}", algorithm=MD5, op="auth", stale=false
Content-Length: {requestLengthInBytes}
Connection: keep-alive
HTTP/1.1 201 Created
Vary: Accept-Encoding
Content-Type: application/json
Strict-Transport-Security: max-age=300
Date: {dateInUnixFormat}
Connection: keep-alive
Content-Length: {requestLengthInBytes}
X-MongoDB-Service-Version: gitHash={gitHash}; versionString={ApplicationVersion}
{
"totalCount" : 3,
"results" : [ {
"cidrBlock" : "12.34.56.78/32",
"ipAddress" : "12.34.56.78",
"created" : "2014-04-23T16:17:44Z",
"lastUsed" : "2016-08-17T19:34:05Z",
"lastUsedAddress" : "12.34.56.78",
"count" : 0,
"links" : []
}, {
"cidrBlock" : "76.54.32.10/32",
"ipAddress" : "76.54.32.10",
"created" : "2016-08-17T19:34:05Z",
"count" : 0,
"links" : []
}, {
"cidrBlock" : "2.3.4.5/32",
"ipAddress" : "2.3.4.5",
"created" : "2016-08-17T19:34:05Z",
"count" : 0,
"links" : []
} ],
"links" : []
}
On this page
Note
Groups and projects are synonymous terms. Your
{PROJECT-ID}
is the
same as your project id. For existing groups, your group/project id
remains the same. This page uses the more familiar term group when
referring to descriptions. The endpoint remains as stated in the
document.
Base URL:
https://cloud.mongodb.com/api/public/v1.0
GET /groups/byName/{GROUP-NAME}
Name | Type | Description |
---|---|---|
GROUP-NAME | string | (Required.) The name of the project. |
The following query parameters are optional:
Name | Type | Necessity | Description | Default | ||||||
---|---|---|---|---|---|---|---|---|---|---|
pretty | boolean | Optional | Flag indicating whether the response body should be in a prettyprint format. |
false
|
||||||
envelope | boolean | Optional |
Flag that indicates whether or not to wrap the response in an envelope. Some API clients cannot access the HTTP response headers or status code. To remediate this, set envelope=true in the query. For endpoints that return one result, the response body includes:
|
false
|
This endpoint doesn’t use HTTP request body parameters.
Name | Type | Description |
---|---|---|
activeAgentCount | integer |
Number of active agents sending regular pings to Cloud Manager.
The value is refreshed about every 24 hours and cached. If
you start a new agent or stop an existing one, the change
can take up to 30 minutes to show up in the
|
hostCounts | object | Total number of hosts by type. The embedded fields should be self-explanatory. |
id | string | Unique identifier for the group. |
lastActiveAgent | string |
Time Cloud Manager last updated the
activeAgentCount
total for
the project. Cloud Manager refreshes this value every 24 hours and
caches it to record the number of active MongoDB Agents.
|
links | object array |
One or more links to sub-resources and/or related resources. All
links
arrays in responses include at least one link called
self
. The relationships between
URL
s are explained in the
Web Linking Specification
.
|
name | string | Display name for the project. |
orgId | string | Unique identifier for the organization to which the project belongs. |
publicApiEnabled | boolean |
Flag indicating that the
API
is enabled for this project.
This is a read-only field that is always
true
.
|
replicaSetCount | integer | Total number of replica sets for this project. |
shardCount | integer | Total number of shards for this project. |
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
--include \
--request GET "https://cloud.mongodb.com/api/public/v1.0/groups/byName/{GROUP-NAME}?pretty=true"
Important
Some characters are not allowed in URLs. These are called
reserved characters.
If your
{GROUP-NAME}
includes reserved characters, like spaces,
you must replace them with their
percent encoding.
Example
Instead of making this request (via curl):
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
--header "Accept: application/json" \
--include \
--request GET "https://cloud.mongodb.com/api/public/v1.0/groups/byName/My%20Project?pretty=true"
Make this request (via curl):
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
--header "Accept: application/json" \
--include \
--request GET "https://cloud.mongodb.com/api/public/v1.0/groups/byName/My%20Group?pretty=true"
HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=ISO-8859-1
Date: {dateInUnixFormat}
WWW-Authenticate: Digest realm="MMS Public API", domain="", nonce="{nonce}", algorithm=MD5, op="auth", stale=false
Content-Length: {requestLengthInBytes}
Connection: keep-alive
HTTP/1.1 200 OK
Vary: Accept-Encoding
Content-Type: application/json
Strict-Transport-Security: max-age=300
Date: {dateInUnixFormat}
Connection: keep-alive
Content-Length: {requestLengthInBytes}
X-MongoDB-Service-Version: gitHash={gitHash}; versionString={ApplicationVersion}
{
"activeAgentCount": 1,
"agentApiKey": "{AGENT-API-KEY}",
"hostCounts": {
"arbiter": 2,
"config": 1,
"primary": 4,
"secondary": 8,
"mongos": 2,
"master": 0,
"slave": 0
},
"id": "{PROJECT-ID}",
"lastActiveAgent": ISODate("2016-08-05T07:23:34Z"),
"links" : [],
"name": "My Project",
"orgId" : "111111111cccccf38dc78bdf",
"publicApiEnabled": true,
"replicaSetCount": 3,
"shardCount": 2,
}
On this page
This tutorial manipulates the Cloud Manager Administration API’s automation configuration to deploy a sharded cluster that is owned by another user. The tutorial first creates a new project, then a new user as owner of the project, and then a sharded cluster owned by the new user. You can create a script to automate these procedures for use in routine operations.
To perform these steps, you must have sufficient access to Cloud Manager. A
user with the
Project
Owner
role has sufficient access.
The procedures install a cluster with two
shards
. Each
shard comprises a three-member
replica set
. The tutorial
installs one
mongos
and three
config servers
.
Each component of the cluster resides on its own server, requiring a
total of 10 hosts.
The tutorial installs the MongoDB Agent on each host.
Provision ten hosts to serve the components of the sharded cluster . For host requirements, see the Production Notes in the MongoDB manual.
Each host must provide its
MongoDB Agent
with full
networking access to the hostnames and ports of the MongoDB Agents on
all the other hosts. Each agent runs the command
hostname
-f
to self-identify its hostname and port and report them to Cloud Manager.
Tip
To ensure agents can reach each other, provision the hosts using Automation . This installs the MongoDB Agents with correct network access. Use this tutorial to reinstall the Automations on those machines.
As you work with the API , you can view examples on the GitHub example page.
The API resources use one or more of these variables. Replace these variables with your desired values before calling these API resources.
Name | Type | Description |
---|---|---|
PUBLIC-KEY
|
string | Your public API Key for your API credentials. |
PRIVATE-KEY
|
string | Your private API Key for your API credentials. |
cloud.mongodb.com
|
string | URL of your Cloud Manager instance. |
GROUP-ID
|
string | Unique identifier of your project from your Project Settings . |
Use the Cloud Manager Administration API to send a projects document to create the new project.
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
--header "Content-Type: application/json" \
--request POST "https://cloud.mongodb.com/api/public/v1.0/groups?pretty=true" \
--data '
{
"name": "{GROUP-NAME}"
}'
The
API
returns a document that includes the project’s
agentApiKey
and
id
.
agentApiKey
and
id
in the returned document.¶
Record these values for use in this procedure and in other procedures in this tutorial.
Use the
/users
endpoint to add a user to the new project.
The body of the request should contain a users JSON document with the user’s information.
Set the user’s
roles.roleName
to
GROUP_OWNER
and the user’s
roles.groupId
set to the new group’s‘
id
.
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
--header 'Accept: application/json' \
--header "Content-Type: application/json" \
--request POST "https://cloud.mongodb.com/api/public/v1.0/users?pretty=true" \
--data '
{
"username": "<new_user@example.com>",
"emailAddress": "<new_user@example.com>",
"firstName": "<First>",
"lastName": "<Last>",
"password": "<password>",
"roles": [{
"groupId": "{PROJECT-ID}",
"roleName": "GROUP_OWNER"
}]
}'
To learn how to install the MongoDB Agent, follow the procedure for the appropriate platform .
When the MongoDB Agent first runs, it downloads the
mms-cluster-config-backup.json
file, which describes the desired
state of the
automation configuration
.
On one of the hosts, navigate to
/var/lib/mongodb-mms-automation/
and open
mms-cluster-config-backup.json
. Confirm that the file’s
version
field is set to
1
. Cloud Manager automatically increments
this field as changes occur.
To add or update a deployment, retrieve the configuration , make changes as needed, and send the updated configuration though the API to Cloud Manager.
The following procedure deploys an updated automation configuration through the API :
Use the automationConfig resource to retrieve the configuration. Issue the following command, replacing the placeholders with the Variables for Cluster Creation API Resources.
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
--request GET "https://cloud.mongodb.com/api/public/v1.0/groups/{PROJECT-ID}/automationConfig?pretty=true" \
--output currentAutomationConfig.json
Validate the downloaded Automation Configuration file.
Compare the
version
field of the
currentAutomationConfig.json
with that of the Automation
Configuration backup file,
mms-cluster-config-backup.json
. The
version
value is the last element in both
JSON
documents.
You can find this file on any host running the MongoDB Agent at:
/var/lib/mongodb-mms-automation/mms-cluster-config-backup.json
%SystemDrive%\MMSAutomation\versions\mms-cluster-config-backup.json
If the
version
values match, you are working with the current
version of the Automation Configuration file.
Create a document with the following fields. As you build the configuration document, refer the description of an automation configuration for detailed explanations of the settings. For examples, see the MongoDB Labs page.
1 2 3 4 5 6 7 8 9 10 11 |
{
"options": {
"downloadBase": "/var/lib/mongodb-mms-automation",
},
"mongoDbVersions": [],
"monitoringVersions": [],
"backupVersions": [],
"processes": [],
"replicaSets": [],
"sharding": []
}
|
In the
monitoringVersions.hostname
field, enter the hostname of
the server where Cloud Manager should install the Monitoring. Use the fully
qualified domain name that running
hostname
-f
on the server
returns, as in the following:
1 2 3 4 5 6 7 8 9 10 |
"monitoringVersions": [
{
"hostname": "<server_x.example.com>",
"logPath": "/var/log/mongodb-mms-automation/monitoring-agent.log",
"logRotate": {
"sizeThresholdMB": 1000,
"timeThresholdHrs": 24
}
}
]
|
This configuration example also includes the
logPath
field, which
specifies the log location, and
logRotate
, which specifies the
log thresholds.
This sharded cluster has 10 MongoDB instances, as described in the
Deploy a Cluster through the API
, each running on its own
server. Thus, the automation configuration’s
processes
array will
have 10 documents, one for each MongoDB instance.
The following example adds the first document to the
processes
array. Replace
<process_name_1>
with any name you choose, and
replace
<server1.example.com>
with the
FQDN
of the host.
Add 9 documents: one for each MongoDB instance in your sharded cluster.
Specify the
args2_6
syntax for the
processes.<args>
field.
See
MongoDB Settings that Automation Supports
for more
information.
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 |
"processes": [
{
"version": "4.0.6",
"name": "<process_name_1>",
"hostname": "<server1.example.com>",
"logRotate": {
"sizeThresholdMB": 1000,
"timeThresholdHrs": 24
},
"authSchemaVersion": 5,
"featureCompatibilityVersion": "4.0",
"processType": "mongod",
"args2_6": {
"net": {
"port": 27017
},
"storage": {
"dbPath": "/data/"
},
"systemLog": {
"path": "/data/mongodb.log",
"destination": "file"
},
"replication": {
"replSetName": "rs1"
}
}
},
]
|
Add two replica set documents to the
replicaSets
array. Add
three members to each document.
Example
This section adds one replica set member to the first replica set document:
Important
You must include
"protocolVersion":
1
in the root document
for each replica set.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
"replicaSets": [
{
"_id": "rs1",
"members": [
{
"_id": 0,
"host": "<process_name_1>",
"priority": 1,
"votes": 1,
"slaveDelay": 0,
"hidden": false,
"arbiterOnly": false
}
],
"protocolVersion": 1
}
]
|
In the
sharding
array, add the replica sets to the shards, and
add the config server replica set name, as in the following:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
"sharding": [
{
"shards": [
{
"tags": [],
"_id": "shard1",
"rs": "rs1"
},
{
"tags": [],
"_id": "shard2",
"rs": "rs2"
}
],
"name": "sharded_cluster_via_api",
"configServerReplica": "rs-config",
"collections": []
}
]
|
Use the automationConfig resource to send the updated automation configuration.
Issue the following command with path to the updated configuration document and replace the placeholders with the Variables for Cluster Creation API Resources.
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
--header "Content-Type: application/json"
--request PUT "https://cloud.mongodb.com/api/public/v1.0/groups/{PROJECT-ID}/automationConfig?pretty=true" \
--data @currentAutomationConfig.json
Upon successful update of the configuration, the API returns the HTTP
200
OK
status code to indicate the request has succeeded.
Retrieve the automation configuration from Cloud Manager and confirm it contains the changes. To retrieve the configuration, issue the following command, replacing the placeholders with the Variables for Cluster Creation API Resources.
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
--request GET "https://cloud.mongodb.com/api/public/v1.0/groups/{PROJECT-ID}/automationConfig?pretty=true"
Use the automationStatus resource to verify the configuration update is fully deployed. Issue the following command, replacing the value placeholders given in Variables for Cluster Creation API Resources:
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
--request GET "https://cloud.mongodb.com/api/public/v1.0/groups/{PROJECT-ID}/automationStatus?pretty=true"
The
curl
command returns a
JSON
object containing the
processes
array and the
goalVersion
key and value. The
processes
array contains a document for each server that hosts a
MongoDB instance. The new configuration is successfully deployed when
all
lastGoalVersionAchieved
fields in the
processes
array
equal the value specified for
goalVersion
.
Example
In this response,
processes[2].lastGoalVersionAchieved
is
behind
goalVersion
. This indicates that the MongoDB instance
at
server3.example.com
is running one version behind the
goalVersion
. Wait several seconds and issue the
curl
command again.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
{
"goalVersion": 2,
"processes": [{
"hostname": "server1.example.com",
"lastGoalVersionAchieved": 2,
"name": "ReplSet_0",
"plan": []
}, {
"hostname": "server2.example.com",
"lastGoalVersionAchieved": 2,
"name": "ReplSet_1",
"plan": []
}, {
"hostname": "server3.example.com",
"lastGoalVersionAchieved": 1,
"name": "ReplSet_2",
"plan":[]
}]
}
|
To view the new configuration in the Cloud Manager console, click Deployment .
To make an additional version of MongoDB available in the cluster, see Update the MongoDB Version of a Deployment .