Enable or Disable Performance Advisor for a Project¶

Performance Advisor is enabled by default. To disable or enable Performance Advisor:

Common Reasons for Slow Queries¶

If a query is slow, common reasons include:

• The query is unsupported by your current indexes.
• Some documents in your collection have large array fields that are costly to search and index.
• One query retrieves information from multiple collections with $lookup.

Index Considerations¶

Indexes improve read performance, but a large number of indexes can negatively impact write performance since indexes must be updated during writes. If your collection already has several indexes, consider this tradeoff of read and write performance when deciding whether to create new indexes. Examine whether a query for such a collection can be modified to take advantage of existing indexes, as well as whether a query occurs often enough to justify the cost of a new index.

The Performance Advisor can help identify and remove unnecessary indexes. To learn more, see Review Drop Index Recommendations .

Access Performance Advisor¶

To access the Performance Advisor :

The Performance Advisor displays up to 20 query shapes across all collections in the cluster and suggested indexes for those shapes. The Performance Advisor ranks the indexes according to their Impact , which indicates High or Medium based on the total wasted bytes read. To learn more about index ranking, see Review Index Ranking .

Index Suggestions¶

The Performance Advisor ranks the indexes that it suggests according to their Impact , which indicates High or Medium based on the total wasted bytes read. To learn more about how the Performance Advisor ranks indexes, see Review Index Ranking .

To learn how to create indexes that the Performance Advisor suggests, see Create Suggested Indexes .

Create Suggested Indexes¶

You can create indexes suggested by the Performance Advisor directly within the Performance Advisor itself. When you create indexes, keep the ratio of reads to writes on the target collection in mind. Indexes come with a performance cost, but are more than worth the cost for frequent queries on large data sets. To learn more about indexing strategies, see Indexing Strategies.

{ <option1>: <value1>, ... }

{ unique: true, name: "myUniqueIndex" }

{ "locale": "fr" }

Overview¶

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.

Procedure¶

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.

Next Steps¶

Once you have installed the MongoDB Agent to all your hosts, you can deploy your first replica set , cluster , or standalone .

Working with Multiple Environments¶

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.

Create One Project¶

Delete One Project¶

Additional Information¶

Use the following procedures to modify projects:

• Edit Project Settings
• Reopen a Locked Account
• Remove Project from Automation

Resource¶

POST /users/{USER-ID}/whitelist

Response¶

Example Request¶

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"
      }
    ]'

Example Response¶

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" : []
}