This is one stop global knowledge base where you can learn about all the products, solutions and support features.
On this page
This page describes compatibility between Cloud Manager features and MongoDB.
Cloud Manager support for End of Life MongoDB versions
Cloud Manager doesn’t support Backup, Monitoring, or Automation for versions earlier than MongoDB 3.6.
To learn more about backup considerations specific to MongoDB 4.4 and later and 4.2 and earlier, see Backup Considerations .
To learn more about MongoDB versioning, see MongoDB Versioning in the MongoDB Manual.
To monitor a deployment running MongoDB 3.6 or later release series, you must use Monitoring Agent version 2.7.0 or later.
To manage PowerPC Linux-based hosts, you must use Automation Agent 3.2.7.1927 or later.
Using Cloud Manager, you can configure all MongoDB deployment types: sharded clusters, replica sets, and standalones.
The shards in a sharded cluster must be replica sets. That is, a shard cannot be a standalone mongod . If you must run a shard as a single mongod (which provides no redundancy or failover), run the shard as a single-member replica set.
Note
You may not upgrade a sharded MongoDB deployment to version 3.4 if the deployment uses mirrored mongod instances as config servers. To allow the sharded deployment to be upgraded, see Convert Config Servers to a Replica Set . The conversion requires that the sharded deployment run MongoDB version 3.2.4 or later. Deployments running previous versions must upgrade to version 3.2.4 before an upgrade to version 3.4.
On this page
This tutorial shows you how to stop monitoring a process . Once you stop monitoring a process, Cloud Manager stops displaying its status and tracking its metrics.
Learn how to use the Cloud Manager Administration API to:
Complete these prerequisites before you complete the tutorial.
Project
Monitoring
Admin
Project
Owner
Complete all the following steps to use the API to stop monitoring a process.
Use the
Get One Host by Hostname and Port
resource to find the process and retrieve the
id
value.
The Get One Host by Hostname and Port resource uses the hostname and port you specify to find the process. Then, it returns information about this process. You can find the id needed for the next step in the response.
Copy the following curl command. Paste it into your preferred terminal or console. Replace the displayed placeholders with these values:
Placeholder | Description |
---|---|
{PUBLIC-KEY}
|
Public part of your API key. |
{PRIVATE-KEY}
|
Private part of your API key. |
{PROJECT-ID}
|
Unique identifier of the project that owns the host. |
{HOSTNAME}
|
Primary hostname that Cloud Manager uses to connect to the instance. This may be a hostname, an FQDN , an IPv4 address, or an IPv6 address. |
{PORT}
|
Port on which the process listens. |
Replace the placeholders in the command, then execute it.
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
--request GET "https://cloud.mongodb.com/api/public/v1.0/groups/{PROJECT-ID}/hosts/byName/{HOSTNAME}:{PORT}"
In the response body, copy the value returned in the
id
field. You need the
value for the next step.
Example
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
{
"alertsEnabled" : true,
"aliases": [ "server1.example.com:27017", "203.0.113.3:27017" ],
"authMechanismName" : "SCRAM-SHA-1",
"clusterId" : "<cluster-ID-1>",
"created" : "2021-04-22T19:56:50Z",
"groupId" : "<project-ID-1>",
"hasStartupWarnings" : false,
"hidden" : false,
"hostEnabled" : true,
"hostname" : "server1.example.com",
"id" : "{HOST-ID}",
"ipAddress": "203.0.113.3",
}
|
Use the Stop Monitoring One Host resource to stop monitoring the host.
The Stop Monitoring One Host resource doesn’t actually delete the host. The resource deletes the host from the list of hosts that Cloud Manager monitors. This removes the process from monitoring.
Copy the following curl command. Paste it into your preferred terminal or console. Replace the displayed placeholders with these values:
Placeholder | Description |
---|---|
{PUBLIC-KEY}
|
Public part of your API key. |
{PRIVATE-KEY}
|
Private part of your API key. |
{PROJECT-ID}
|
Unique identifier of the project that owns the host. |
{HOST-ID}
|
Unique identifier of the host for the process. Use the
id
from
step 1.
|
Replace the placeholders in the command, then execute it.
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
--request DELETE "https://cloud.mongodb.com/api/public/v1.0/groups/{PROJECT-ID}/hosts/{HOST-ID}"
Use the
Get One Host by Hostname and Port
resource again to attempt to find the process using its hostname and port. Then, verify
that
details
returns
No
host
with
hostname
and
port
{HOSTNAME}:{PORT}
exists
in
group
{PROJECT-ID}
.
The
Get One Host by Hostname and Port
resource uses the hostname and port you specify to find the process. Then, it
returns information about this process. You can tell that Cloud Manager doesn’t monitor
the process if the
details
value in the response is
No
host
with
hostname
and
port
{HOSTNAME}:{PORT}
exists
in
group
{PROJECT-ID}
.
This means that Cloud Manager can’t find the host in the
list of processes that it monitors.
Copy the following curl command. Paste it into your preferred terminal or console. Replace the displayed placeholders with these values:
Placeholder | Description |
---|---|
{PUBLIC-KEY}
|
Public part of your API key. |
{PRIVATE-KEY}
|
Private part of your API key. |
{PROJECT-ID}
|
Unique identifier of the project that owns the host. |
{HOSTNAME}
|
Primary hostname that Cloud Manager uses to connect to this instance. This may be a hostname, an FQDN, an IPv4 address, or an IPv6 address. |
{PORT}
|
Port on which the process listens. |
Replace the placeholders in the command, then execute it.
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
--request GET "https://cloud.mongodb.com/api/public/v1.0/groups/{PROJECT-ID}/hosts/byName/{HOSTNAME}:{PORT}"
In the response body, check the value returned in the
details
field. If
details
returns
No
host
with
hostname
and
port
{HOSTNAME}:{PORT}
exists
in
group
{PROJECT-ID}
, you succeeded. Cloud Manager no longer monitors the process.
On this page
The Cloud Manager Public API follows the REST architecture principles to expose internal resources that provide programmatic access to Cloud Manager’s features.
As with changes made through the web interface, changes made through the API are subject to Cloud Manager pricing . If you add servers and incur charges, you must have a valid credit card on file with Cloud Manager or risk having your account locked .
The API has the following features:
Each Cloud Manager user’s API capabilities match the permissions that their Cloud Manager Roles grant.
Example
A user with the
Project
Read
Only
role cannot modify
any resource within that project whether through the Cloud Manager UI or
the
API
.
All resources support a subset of these common HTTP Methods:
Method | Purpose |
---|---|
GET
|
Retrieve the JSON representation of a resource. |
POST
|
Create a new resource using the provided JSON representation. |
PUT
|
Replace a resource with the provided JSON representation. |
PATCH
|
Update the specified fields in a resource using the provided JSON representation. |
DELETE
|
Remove a resource. |
HEAD
|
Retrieve the response header without the JSON representation of the resource. |
All entities are represented in JSON . The following rules for requests and conventions of responses apply:
POST
or
PUT
, make sure
to specify the correct content type request header:
Content-Type:
application/json
When sending dates to the server (as query parameters or fields in
POST
or
PATCH
request entities), use dates formatted
according to the ISO 8601 standard. If you don’t specify a time
zone, Cloud Manager assumes
UTC
. Include a time zone designator to avoid
any ambiguity.
Example
2018-09-27
.
2018-09-27T16:00-04:00
.
In some cases, a timestamp is returned as a JSON representation of a BSON timestamp, most notably in the backup resources. This representation of a BSON timestamp provides a JSON document as an object with two fields:
Field | Definition |
---|---|
date
|
Seconds since the UNIX Epoch |
increment
|
An incrementing 32-bit integer ordinal for operations within a given second. |
Example
The third operation at September 27, 2018 at 4:00 PM EDT is expressed (with time zone) as
{ date: 2018-09-27T16:00-04:00, increment: 3 }
Invalid fields are rejected rather than ignored .
Example
You attempt to create a new entity and misspell one of the fields, or if you attempt to update an existing entity and include a field that cannot be modified, the Cloud Manager responds with an HTTP 400 status code and an error message stating which field was invalid.
Fields that contain numeric values in a particular unit are named so as to disambiguate the unit being used.
Example
A host’s uptime is returned in millseconds, so the name of the
host entity field is
uptimeMsec
.
Fields that do not have a current value are returned with an appropriate default value.
Example
Cloud Manager does not have any statistics for a newly discovered host, so any statistics-related fields have a value of zero.
Fields that do not have a sensible default value are omitted from the entity.
Example
A host that is not using authentication omits the
username
field from the returned entity.
Each resource includes one or more links to sub-resources and/or related resources.
Example
A host has a link to the project it belongs to, the replica set it belongs to, and so on.
Links are placed in the
links
field of an entity, which is an
array of link relation objects. Each link relation has two fields:
Field | Definition |
---|---|
rel
|
Name (or type) of the relation. Many of these are
considered Extension Relation Types and are prefixed by
http://mms.mongodb.com
.
|
href
|
Target URL . |
All entities include at least one link relation called
self
, which
is simply its own
URL
. When an entity is part of a list (i.e., when
requesting all hosts in a project), then it only includes the
self
link relation.
Example
This is a portion of a
host
resource with a few links:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
{
"id": "xxx",
"projectId": "yyy",
"hostname": "mongodb.example.com",
"port": 27017,
"links": [
{
"rel": "self",
"href": "https://cloud.mongodb.com/api/public/v1.0/projects/xxx/hosts/yyy"
},
{
"rel": "http://mms.mongodb.com/project",
"href": "https://cloud.mongodb.com/api/public/v1.0/projects/xxx"
}
]
}
|
To learn more, see the Web Linking Specification.
Note
Although the Web Linking Specification describes a format for including links in the HTTP response headers, it is not required. To make the API easily browsable, it includes the links in the response body rather than in the response headers.
Some resources return a list of entities.
Example
You can request a list of all hosts in a project .
When a list of entities is expected in a response, the results are returned in batches bounded by two query parameters:
Field | Definition |
---|---|
pageNum
|
Page number (1-based). Defaults to 1 if not specified. |
itemsPerPage
|
Number of items to return per page, up to a maximum of 500. Defaults to 100 if not specified. |
The response entity contains three fields:
Field | Definition |
---|---|
totalCount
|
Total number of items in the entire result set. Example
If a project has a total of 57 hosts, and you make a request
with
|
results
|
Result set, which is an array of entity documents. |
links
|
Contains one to three link relations:
|
If you make a request for a list of entities and there are no results,
then the
API
responds with an
HTTP
200 status code and an empty
results
array. It does
not
respond with a 404 in this case,
since the list of entities may not be empty at some point in the
future.
If you had requested a list of entities in a context that does not exist (i.e., the list of hosts for a non-existent project), then this results in a an HTTP 404 response status.
Example
This is an HTTP response for the second page of 10 hosts in a project with a total of 57 hosts:
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 |
{
"totalCount": 57,
"results": [
{
"id": "yyy",
"projectId": "xxx",
// additional host properties...
},
// additional host documents...
],
"links": [
{
"rel" : "self",
"href" : "https://www.mongodb.com/api/public/v1.0/projects/xxx/hosts?pageNum=2&itemsPerPage=10"
},
{
"rel": "previous",
"href": "https://www.mongodb.com/api/public/v1.0/projects/xxx/hosts?itemsPerPage=10&pageNum=1"
},
{
"rel": "next",
"href": "https://www.mongodb.com/api/public/v1.0/projects/xxx/hosts?itemsPerPage=10&pageNum=3"
}
]
}
|
Some clients may not be able to access the
HTTP
response headers
and/or status code. In that case, you can request that the response
include an
envelope
, which is simply an extra layer of information
in the
JSON
document that contains any relevant details that would
normally be in the response headers.
By default, the
API
does
not
include the response in an envelope.
To request one, simply add the query parameter
envelope=true
.
For responses that contain a single entity, the envelope contains two fields:
Field | Definition |
---|---|
status
|
HTTP status code. |
content
|
Requested entity. |
For responses that contain a list of entities, there is already an
envelope that wraps the results, so specifying
envelope=true
as a
query parameter in this case only adds the
status
field to the
existing envelope.
By default, extraneous whitespace is stripped from the
JSON
that
Cloud Manager returns. To ask for pretty-printed
JSON
, simply append the
pretty=true
query parameter to any request:
curl --user '{USERNAME}:{APIKEY}' --digest \
--header 'Accept: application/json' \
--include \
--request GET "https://cloud.mongodb.com/api/public/v1.0?pretty=true"
Note
All the examples in this document show pretty-printed JSON for clarity, although some example URL s may not contain this additional query parameter .
Responses utilize the standard HTTP response codes, including:
Code | Meaning | Notes |
---|---|---|
200 | OK |
The request was successful. This is the typical response to a
successful
GET
request.
|
201 | Created |
A new resource was created. This is the typical response to a
successful
POST
request.
|
202 | Accepted | A request for an asynchronous operation was accepted. |
400 | Bad Request | Something was wrong with the client request. |
401 | Unauthorized | Authentication is required but was not present in the request. Typically this means that the digest authentication information was omitted from the request, the provided credentials are incorrect, or the user associated with the given API key is not allowed to access the requested resource. |
403 | Forbidden | Access to the specified resource is not permitted. |
404 | Not Found | The requested resource does not exist. |
405 | Method Not Allowed |
The HTTP method is not supported for the specified resource. Keep in mind that each resource may only support a subset of HTTP methods. Example
You are not allowed to
|
409 | Conflict |
This is typically the response to a request to create or modify a property of an entity that is unique when an existing entity already exists with the same value for that property. Example If you attempt to create a project with the same name as an existing project, the request fails. |
5xx | Various server errors | Something unexpected went wrong. Try again later and consider notifying Cloud Manager Support. |
When a request results in an error, the response body contains a JSON document with additional details about what went wrong. The document contains five fields:
Field | Data Type | Definition |
---|---|---|
detail
|
string | Human-readable description of the API request error. |
error
|
integer | HTTP status code . |
errorCode
|
string | Named constant representing the API request error as shown in Cloud Manager Administration API Error Codes . |
parameters
|
array of strings | List of parameters passed in the API request. |
reason
|
string | HTTP status code definition . |
Example
Cloud Manager returns this response body for an incorrectly formatted request:
|
|
1 2 3 4 5 6 7 |
{
"detail" : "Cannot find resource /api/public/v1.0/softwareComponents/version.",
"error" : 404,
"errorCode" : "RESOURCE_NOT_FOUND",
"parameters" : [ "/api/public/v1.0/softwareComponents/version" ],
"reason" : "Not Found"
}
|
To review the list of codes, see Cloud Manager Administration API Error Codes .
As previously mentioned, the Cloud Manager API uses HTTP Digest Authentication. The details of digest authentication are beyond the scope of this document, but it essentially requires a username and a password which are hashed using a unique server-generated value called a nonce . The username is the username of a registered Cloud Manager account, and the password is a Public API Key associated with that account.
Keep the following points in mind:
Some resource methods require even more security and are additionally protected by whitelists that allow access to the resource only from the IP addresses listed. Each user configures their own whitelist of IP addresses that allow access to the resource.
The Cloud Manager has a concept of roles , which allow more fine-grained control of the operations a user is allowed to perform. The API resources also enforce the same authorization rules, so the resources and methods that can be accessed by an API key are governed by the roles granted to the associated user.
Example
To
DELETE
a host, the user that owns the
API
key used to
make the request must be a
Project
Monitoring
Admin
or
Project
Owner
in the project to which the host
belongs.
Many resources are tied to a project (former known as a group ), as evidenced by URL s of the following form:
/api/public/v1.0/groups/{PROJECT-ID}/
For these resources, the user tied to the API key must be a member of the project. Otherwise Cloud Manager responds with an HTTP 401 error.
The Automation Configuration Resource and Get Automation Status of Latest Plan resources provide endpoints that let you modify a project’s deployment and retrieve deployment status. You can modify a deployment by sending a new automation configuration to Cloud Manager. The automation configuration is where you describe and configure the MongoDB processes to be deployed. Cloud Manager refers to this as the deployment’s “goal state.” When you submit a new automation configuration through the API , the Automations adjust the current state of the system to match the goal state.
Important
There is no protection in the API to prevent concurrent modifications. If two administrators both start with a configuration based on the current version, make their own modifications, and then submit their modifications, the later modification wins.
Certain resources are subject to rate limiting.
For resources that are rate limited, Cloud Manager allows up to 100 requests per minute per project . Keep in mind that a Public API Key is assigned to a Cloud Manager user, but that user may access multiple projects.
Example
Consider two users: A and B.
User A belongs to project X, and user B belongs to projects X and Y.
At 1:00:00pm, User A makes 50 requests to a rate limited resource in project X, all of which complete by 1:00:20pm.
At 1:00:30pm, User B attempts to make 60 requests to a rate limited resource in project X.
Since User A has already used up 50 requests within the 1:00pm minute for project X, the last 10 requests User B attempts to make are rejected. However, User B can make requests to a rate limited resource in project Y, since each project maintains a separate request counter.
At 1:01pm, requests to project X may proceed, because the request counter used for rate limiting reset each minute.
If you exceed the rate limit, the
API
returns an
HTTP
429
Too
Many
Requests
response code.
See Cloud Manager Administration API Resources for a complete reference of all resources available in the Cloud Manager Public API .