Welcome to Knowledge Base!

KB at your finger tips

Book a Meeting to Avail the Services of MongoDB overtime

This is one stop global knowledge base where you can learn about all the products, solutions and support features.

Categories
All

MongoDB

Return All Connected Organizations — MongoDB Cloud Manager

Return All Connected Organizations¶

On this page

  • Required Roles
  • Resource
    • Request Path Parameters
    • Request Query Parameters
    • Request Body Parameters
  • Response
    • Response Document
    • results Embedded Document
  • Example Request
  • Example Response

The federationSettings resource allows you to return all connected organizations for a federated authentication configuration.

Base URL: https://cloud.mongodb.com/api/public/v1.0

Required Roles¶

You must have the Organization Owner role for at least one connected organization in the federation configuration to call this endpoint.

Resource¶

GET /federationSettings/{FEDERATION-SETTINGS-ID}/connectedOrgConfigs/

Request Path Parameters¶

Name Type Description
FEDERATION-SETTINGS-ID string Unique 24-hexadecimal digit string that identifies the federated authentication configuration.

Request Query Parameters¶

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 envelope : true in the query.

For endpoints that return a list of results, the results object is an envelope. Cloud Manager adds the status field to the response body.

false

Request Body Parameters¶

This endpoint does not use HTTP request body parameters.

Response¶

Response Document¶

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 of objects One object for each item detailed in the results Embedded Document section.
links array of objects 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 .
totalCount 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.

results Embedded Document¶

Each document in the result array contains the federated authentication configuration for each connected organization.

Name Type Description
domainAllowList array List that contains the approved domains from which organization users can log in.
domainRestrictionEnabled boolean

Flag that indicates whether domain restriction is enabled for the connected organization.

Note

userConflicts returns null when "domainRestrictionEnabled": false .

identityProviderId string Unique 20-hexadecimal digit string that identifies the identity provider associated with the connected organization.
orgId string Unique 24-hexadecimal digit string that identifies the connected organization.
postAuthRoleGrants array List that contains the default roles granted to users who authenticate through the IdP in a connected organization.
roleMappings array List that contains the role mappings configured in this organization.
userConflicts array

List that contains the usernames that don’t match any domain on the allowed list.

Note

userConflicts returns null when "domainRestrictionEnabled": false .

Example Request¶

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
     --header "Accept: application/json" \
     --header "Content-Type: application/json" \
     --include \
     --request GET "https://<OpsManagerHost>:<Port>/api/public/v1.0/federationSettings/{FEDERATION-SETTINGS-ID}/connectedOrgConfigs"

Example Response¶

{
 "links": [
     {
         "href": "https://<OpsManagerHost>:<Port>/api/public/v1.0/federationSettings/{FEDERATION-SETTINGS-ID}/connectedOrgConfigs?pageNum=1&itemsPerPage=100",
         "rel": "self"
     }
 ],
 "results": [
     {
         "domainAllowList": [],
         "domainRestrictionEnabled": false,
         "identityProviderId": null,
         "orgId": "5f86fb11e0079069c9ec3132",
         "postAuthRoleGrants": [],
         "roleMappings": [],
         "userConflicts": null
     }
 ],
 "totalCount": 1
}

Stay Ahead in Today’s Competitive Market!
Unlock your company’s full potential with a Virtual Delivery Center (VDC). Gain specialized expertise, drive seamless operations, and scale effortlessly for long-term success.

Book a Meeting to Avail the Services of MongoDBovertime

Stop Monitoring a Process — MongoDB Cloud Manager

Stop Monitoring a Process¶

On this page

  • Understand the Objectives
  • Complete the Prerequisites
  • Follow These Steps

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.

Understand the Objectives¶

Learn how to use the Cloud Manager Administration API to:

  • Find the host ID for the process.
  • Stop monitoring the process that matches the host ID.
  • Verify that Cloud Manager no longer monitors the process.

Complete the Prerequisites¶

Complete these prerequisites before you complete the tutorial.

  • Configure your access to the Cloud Manager Administration API .
  • Get the permissions needed to change monitoring settings. You need one of the following roles:
    • Project Monitoring Admin
    • Project Owner
  • Terminate the backups for the process before you stop monitoring it.

Follow These Steps¶

Complete all the following steps to use the API to stop monitoring a process.

1

Find the host ID for the process.¶

Use the Get One Host by Hostname and Port resource to find the process and retrieve the id value.

Learn What This Step Does¶

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.

Issue This Command¶

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

Copy the Host’s ID¶

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",
}
2

Stop monitoring the process that matches the host ID.¶

Use the Stop Monitoring One Host resource to stop monitoring the host.

Learn What This Step Does¶

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.

Issue This Command¶

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}"
3

Verify that Cloud Manager no longer monitors the process.¶

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} .

Learn What This Step Does¶

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.

Issue This Command¶

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

Check the Response Details¶

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.

Read article

Disks — MongoDB Cloud Manager

Disks¶

Retrieves the disks and disk partitions on which MongoDB runs.

Base URL: https://cloud.mongodb.com/api/public/v1.0

Endpoints¶

The following endpoints are available for hosts .

Method Endpoint Description
GET /groups/{PROJECT-ID}/hosts/{HOST-ID}/disks Retrieves all disk partitions on the specified host.
GET /groups/{PROJECT-ID}/hosts/HOST-ID/disks/{PARTITION-NAME} Retrieves a single disk parition.
Read article

Configure AWS Integration — MongoDB Cloud Manager

Configure AWS Integration¶

On this page

  • Considerations
  • Rolling Resync onto New EC2 Instances
  • Update a Replica Set’s Hostnames

Important

The ability to provision MongoDB servers in AWS using Cloud Manager was retired in October 2017.

  • Any existing clusters continue as they are.
  • This retirement impacts DNS entries in the following ways:
    • Entries for existing servers continue to resolve to the same IP address to which they currently resolve until at least January 1, 2023.
    • Servers that undergo a change of IP address due to maintenance or an instance stop/restart will no longer be resolvable via their mongodbdns.com hostname.
    • All existing mongodbdns.com hostnames will stop working in May 2023.
  • Cloud Manager can manage hosts provisioned directly through AWS . See Provision Servers for Automation .
  • If you are interested in fully managed provisioning on AWS , evaluate MongoDB Atlas.

If you want to continue using Cloud Manager to manage these deployments, update the hostname for each host using one of the following methods for a replica set:

  • Rolling Resync onto New EC2 Instances
  • Update a Replica Set’s Hostnames

Considerations¶

These procedures involve stepping down the old primary and triggering at least one election for a new primary. All writes to the primary fail during the period starting when the rs.stepDown() method is received until either a new primary is elected, or if there are no electable secondaries, the original primary resumes normal operation. For MongoDB versions 4.0 and earlier, all client connections are closed.

Consider performing this procedure during a maintenance window during which applications stop all write operations to the cluster.

To learn more about elections, see rs.stepDown() behavior and Replica Set Elections .

Rolling Resync onto New EC2 Instances¶

1

Create a new EC2 instance for each member of the replica set.¶

2

Replace each non-primary replica set member with a new EC2 instance.¶

  1. Add a new instance to the replica set using its EC2 hostname. To learn more, see Add Members to a Replica Set.
  2. Wait for the initial sync to complete. To learn how to get the status of an initial sync, see the MongoDB manual.
  3. Remove one old replica set member with a mongodbdns.com hostname. To learn more, see Remove Members from Replica Set.

Repeat for each non-primary replica set member.

3

Change your application connection string to use the AWS EC2 hostnames.¶

4

Replace the primary with a new EC2 instance.¶

  1. Add the last new instance to the replica set using its EC2 hostname. To learn more, see Add Members to a Replica Set.

  2. Wait for the initial sync to complete. To learn how to get the status of an initial sync, see the MongoDB manual.

  3. Connect to the primary and step it down. To learn more, see rs.stepDown() .

    Note

    Stepping down the primary triggers at least one election for a new primary. To learn more about elections, see Replica Set Elections .

  4. Remove the old primary with the mongodbdns.com hostname from the replica set. To learn more, see Remove Members from Replica Set.

Update a Replica Set’s Hostnames¶

Follow the Change Hostnames while Maintaining Replica Set Availability procedure in the MongoDB manual.

An overview of the linked procedure is as follows:

1

Connect to the primary.¶

2

Remove a secondary member from the replica set and re-add it using its EC2 hostname.¶

Repeat for each non-primary member of the replica set.

3

Change your application connection string to use the AWS EC2 hostnames.¶

4

Reconnect to the primary and step it down.¶

Note

Stepping down the primary triggers at least one election for a new primary. To learn more about elections, see Replica Set Elections .

5

Connect to the new primary.¶

6

Remove the old primary from the replica set and re-add it using its EC2 hostname.¶

Read article

Install MongoDB Agent — MongoDB Cloud Manager

Install MongoDB Agent¶

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:

Install the MongoDB Agent to Manage Deployments
Recommended: You have a project and want to install the MongoDB Agent to manage your MongoDB deployments. You can also monitor and back up your MongoDB deployments following this workflow.
Install the MongoDB Agent to Only Monitor or Backup Deployments
You have a project and want to install the MongoDB Agent to monitor and/or back up your MongoDB deployments. You are choosing not to manage your MongoDB deployments at this time.
Read article

View, Retrieve, and Manage Logs — MongoDB Cloud Manager

View, Retrieve, and Manage Logs¶

On this page

  • MongoDB Real-Time Logs
    • View MongoDB Real-Time Logs
    • Enable or Disable Log Collection for a Deployment
    • Enable or Disable Log Collection for the Project
  • MongoDB On-Disk Logs
    • Configure Log Rotation
  • Agent Logs
    • View Agent Logs
    • Configure Agent Log Rotation

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.

  • The MongoDB logs provide the diagnostic logging information for your mongod and mongos processes.
  • The Agent logs provide insight into the behavior of your Cloud Manager agents.

MongoDB Real-Time Logs¶

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.

View MongoDB Real-Time Logs¶

1
2

(Optional) For sharded clusters, filter which process type is listed.¶

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.
3

On the line listing the process, click Metrics

4

Click the Logs tab.¶

The tab displays log information. If the tab is not displayed, see Enable or Disable Log Collection for a Deployment to enable log collection.

5

Refresh the browser window to view updated entries.¶

Enable or Disable Log Collection for a Deployment¶

1

Navigate to the Clusters view for your deployment.¶

  1. If it is not already displayed, select the organization that contains your desired project from the office icon Organizations menu in the navigation bar.
  2. If it is not already displayed, select your desired project from the Projects menu in the navigation bar.
  3. If it is not already displayed, click Deployment in the sidebar.
  4. Click the Clusters view.
2

On the line for any process, click the ellipsis [ ] icon then click Monitoring Settings

3

Toggle Collect Logs For Host as desired.¶

  1. Click the Logs tab.
  2. Toggle the Collect Logs For Host to Off or On , as desired.
4

Click X to close the Monitoring Settings box.¶

If you turn off log collection, existing log entries remain in the Logs tab, but Cloud Manager does not collect new entries.

Enable or Disable Log Collection for the Project¶

1

Click Settings , then Project Settings

2

Toggle the Collect Logs For All Hosts option to Yes or No , as desired.¶

MongoDB On-Disk Logs¶

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.

Configure Log Rotation¶

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:

  • Set separate rules for rotating server logs and audit logs.
  • Compress and delete audit logs using Cloud Manager. For security reasons, we recommend managing your audit log compression and deletion outside of Cloud Manager.

If you’re running earlier versions of MongoDB Enterprise or the MongoDB Agent, Cloud Manager:

  • Uses your System Log Rotation settings to rotate both the server logs and the audit logs.
  • Doesn’t compress or delete audit logs. If you configure compression and deletion, Cloud Manager applies these settings to the server logs only.

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.

1

Open the MongoDB Log Settings

  1. Click Deployment .
  2. In the More drop-down list, click MongoDB Log Settings .
2

Enable log rotation.¶

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.

3

Configure the 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 .

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% .

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.

4

Click Confirm & Deploy to deploy your changes.¶

Otherwise, click Cancel and you can make additional changes.

Agent Logs¶

Cloud Manager collects logs for all your MongoDB Agents.

View Agent Logs¶

1

Click Deployment , then the Agents tab, then Agent Logs

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.

2

Filter the log entries.¶

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.

Configure Agent Log Rotation¶

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:

  • MongoDB Agent General Logging Settings
  • MongoDB Agent Monitoring Logging Settings
  • MongoDB Agent Backup Logging Settings
1

Click Deployment , then the Agents tab.¶

2

Click Downloads & Settings

3

Scroll down to the Agent Log Settings section.¶

4

Edit the log settings.¶

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 .

5

Click Review & Deploy to review your changes.¶

6

Click Confirm & Deploy to deploy your changes.¶

Otherwise, click Cancel and you can make additional changes.

Read article