Introduction

MongoDB is a NoSQL database management application. NoSQL database systems offer an alternative to traditional relational databases using SQL (Structured Query Language). Data is stored in tables, rows, and columns in a relational database, with relationships between entities. MongoDB is a widely used, open-source, NoSQL (Not Only SQL) database. Here are some key points about MongoDB:

• Document-Oriented Database
• Flexible Schema
• Scalability
• High Performance
• Aggregation Framework
• Replication and High Availability

Key Use cases

Discovery Use cases

• It discovers the MongoDB cluster and its component nodes.
• Publishes relationships between resources to have a topological view and ease of maintenance.

Monitoring Use cases

• Provides metrics related to job scheduling time and status etc..
• Concern alerts will be generated for each metric to notify the administrator regarding the issue with the resource.

Supported Target Versions

• Validated on MongoDB version 6.0.10

Prerequisites

• OpsRamp Classic Gateway 14.0.0 and above.
• OpsRamp Nextgen Gateway 14.0.0 and above.
  Note: OpsRamp recommends using the latest Gateway version for full coverage of recent bug fixes, enhancements, etc.
• Ensure that the provided IP address/host name, port, and credentials are valid and accessible for successful integration.
  • Verify network connectivity from the gateway using:
    ping <IP Address/Host Name>
  • Check port accessibility using:
    telnet <IP Address/Host Name> <Port>
  • Validate SSH access using the provided credentials:
    ssh -p <Port> <username>@<IP Address/Host Name>
• Provided IPAddress/hostname, Credentials (SSH and MongoDB database) should work for accessing MongoDB clusters.
• The SSH credentials should be same for all the MongoDB replica set cluster nodes.
• The MongoDB credentials should be the same for all the MongoDB replica set node instances.

For Linux Base OS

We are using macAddress as a uniqueId for resource creation. To fetch the MAC Address we are using the ip addr show command. So we need ip command path in PATH environment variable, please add below mentioned lines in .profile or .bashrc file in all the MongoDB servers ( User should have a home directory then only .bash_profile or .bashrc file will be present).

<code>
    PATH={ipPath}:$PATH
</code><br>
<code>
    export PATH
</code><br><br>

**Notes**: 

- Where ipPath is path where ip command binary is present. for example: if ip command is present in "/usr/sbin", then provide PATH=/usr/sbin:$PATH
- As we are utilizing a remote SSH connection, if the environment PATH does not include the binary path for the command, you may encounter a 'command not found' exception.

• As part of discovery we are fetching the serial number and system UUID of the individual nodes. These details are fetched through command-line(SSH).
  • If the SSH credentials being provided are “root” users, no changes need to be made.
  • If the SSH credentials being provided are of a “non-sudo” user, then we need to make an entry in the /etc/sudoers file as below:

• With the above entry, we will be able to execute that sudo command.

• We are using both SSH credentials (for ssh/cli access) and mongoDB instance credentials(for mongoDB instance connection). You may connect to the mongoDB instance using a connection string.

• MongoDB hosts should be resolvable from the gateway.

  • If you are using the NextGen gateway and the hosts are not resolving from the gateway and vprobe container.

    See How to manually add DNS Name Servers to k3s? to manually add DNS name servers to k3s

  • If you are using the classic gateway, add a DNS server entry in the resolv.conf file or mention hosts in the /etc/hosts file.

For Windows Base OS

PowerShell Remoting over WinRM

Configuration steps

• Enable PowerShell Remoting on every applicable target:

    Enable-PSRemoting -Force

• Add the user to Remote Management Users:

    net localgroup "Remote Management Users" /add "<user>"

• Add the OpsRamp Gateway IP to TrustedHosts:

    Set-Item WSMan:\localhost\Client\TrustedHosts -Force -Concatenate -Value "<OpsRampGatewayIP>"

• To allow any host, when explicitly required:

    Set-Item WSMan:\localhost\Client\TrustedHosts -Force -Value "*"

• Configure and restart WinRM:

    Set-Service WinRM -StartupType Automatic
    Restart-Service WinRM -Force

• Open the applicable WinRM port on every target: 5985 for WinRM over HTTP or 5986 for WinRM over HTTPS.
• If the user is a non-administrator, grant remote WMI read-only access to the Root\CIMV2 namespace and its subnamespaces. Ensure all required privileges are enabled before installing the integration.

OpenSSH Server

Pre-checks

Check whether OpenSSH Server is installed and check the SSH service:

Get-WindowsCapability -Online -Name OpenSSH.Server*
Get-Service sshd

Configuration steps

• Install OpenSSH Server if it is not already installed:

    Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

• Start sshd and configure automatic startup:

    Start-Service sshd
    Set-Service sshd -StartupType Automatic

• Open inbound TCP port 22:

    New-NetFirewallRule `
            -Name "Allow-SSH-Port-22" `
            -DisplayName "Allow SSH Port 22" `
            -Protocol TCP `
            -Direction Inbound `
            -LocalPort 22 `
            -Action Allow `
            -Profile Domain,Private,Public

• Open C:\ProgramData\ssh\sshd_config as an administrator:

    notepad C:\ProgramData\ssh\sshd_config

• Configure password authentication and the permitted SSH user in sshd_config:

    PasswordAuthentication yes
    AllowUsers <ssh-username>

• Set Windows PowerShell as the OpenSSH default shell:

    Set-ItemProperty `
            -Path "HKLM:\SOFTWARE\OpenSSH" `
            -Name DefaultShell `
            -Value "$PSHOME\powershell.exe"

• Restart sshd and confirm that it is running:

    Restart-Service sshd
    Get-Service sshd

Validate connectivity from the Gateway

Run the following checks from the Gateway:

ping <IP-address-or-hostname>
telnet <IP-address-or-hostname> 22
ssh <username>@<IP-address-or-hostname>

The SSH connection must be established successfully, and PowerShell must be configured as the default shell. After connecting, run this command to verify the installed PowerShell version and confirm that PowerShell is the active shell:

$PSVersionTable.PSVersion

• Non-admin account must be able to execute the command mongod --version, from Gateway machine.
• Target mongodb windows server ip and port (default 27017) must be reachable from the gateway machine.

DB Privileges for Linux and Windows Base OS

For connecting to the mongoDB instance, a user with readAnyDatabase and clusterMonitor role on the admin database will suffice. In case of replica set clusters the same user credential is expected to be available on all the nodes.

For example we have created the user as below:

Hierarchy of MongoDB resources

For a replica set cluster:

    • MongoDB Replica Set
             • MongoDB Server

For a standalone MongoDB instance:

    • MongoDB Server

You may take the node ip, either standalone or one replica set node (in case of replica set cluster) and the concerned port as input as part of configuration. You would require ssh credentials for the mongoDB server and mongoDB instance credentials as well for executing the remote SSH/ CLI commands.

Supported Metrics

Default Monitoring Configurations

MongoDB has default Global Device Management Policies, Global Templates, Global Monitors and Global Metrics in OpsRamp. You can customize these default monitoring configurations as per your business use cases by cloning respective Global Templates and Global Device Management Policies. We recommend doing this activity before installing the application to avoid noise alerts and data.

1. Default Global Device Management Policies

   You can find the Device Management Policy for each Native Type at Setup > Resources > Device Management Policies. Search with suggested name in global scope. Each Device Management Policy follows below naming convention:

   {appName nativeType - version - Mode}

   Ex: mongodb MongoDB Replica Set - 1 - Cluster(i.e, appName = mongodb, nativeType = MongoDB Replica Set , version = 1, , Mode = Cluster)

2. Default Global Templates

   You can find the Global Templates for each Native Type at Setup > Monitoring > Templates. Search with suggested names in global scope. Each template follows below naming convention:

   {appName Mode nativeType 'Template' - version}

   Ex: mongodb Cluster MongoDB Replica Set Template- 1(i.e, appName = mongodb, Mode = Cluster, nativeType = MongoDB Replica Set, version = 1)

3. Default Global Monitors

   You can find the Global Monitors for each Native Type at Setup > Monitoring > Monitors. Search with suggested name in global scope. Each Monitors follows below naming convention:

   {monitorKey appName nativeType - version}

   Ex: MongoDB Replica Set Cluster Monitor mongodb MongoDB Replica Set 1 (i.e, monitorKey =MongoDB Replica Set Cluster Monitor, appName = mongodb, nativeType = MongoDB Replica Set , version = 2)

Configure and Install the MongoDB Integration

1. From All Clients, select a client.
2. Navigate to Setup > Account.
3. Select the Integrations tab.
4. The Installed Integrations page, where all the installed integrations are displayed. Click + ADD on the Installed Integrations page.
5. If you do not have any installed applications, you will be navigated to the Available Integrations page. The Available Integrations page displays all the available applications along with the newly created application with the version.
   Note: Search for the application using the search option available. Alternatively, use the All Categories option to search.
6. Click ADD in the MongoDB tile.
7. In the Configurations page, click + ADD. The Add Configuration page appears.
8. Enter the following BASIC INFORMATION:

Notes:

• IP Address/Host Name should be accessible from Gateway.
• App Failure Notifications: if turned on, you will be notified in case of an application failure that is, Connectivity Exception, Authentication Exception.

9. Select the following Custom Attribute:

Note: The custom attribute that you add here will be assigned to all the resources that are created by the integration. You can add a maximum of five custom attributes (key and value pair).

10. In the Native Types section, select the native types to be discovered.
11. In the DISCOVERY SCHEDULE section, select recurrence pattern to add one of the following patterns:
    • Minutes
    • Hourly
    • Daily
    • Weekly
    • Monthly
12. Click ADD.

The configuration is saved and displayed on the configurations page after you save it.
Note: From the same page, you may Edit and Remove the created configuration.

13. Under the ADVANCED SETTINGS, Select the Bypass Resource Reconciliation option, if you wish to bypass resource reconciliation when encountering the same resources discovered by multiple applications.

    Note: If two different applications provide identical discovery attributes, two separate resources will be generated with those respective attributes from the individual discoveries.

14. Click NEXT.

15. (Optional) Click +ADD to create a new collector. You can either use the pre-populated name or give the name to your collector.

16. Select an existing registered profile.

17. Click FINISH.

The integration is installed and displayed on the INSTALLED INTEGRATION page. Use the search field to find the installed integration.

Modify the Configuration

• See Modify an Installed Integration or Application article.

  Note: Select MongoDB.

View the MongoDB Details

To discover resources for MongoDB, you have two options:

1. Navigate to Infrastructure > Search > DATABASES > MongoDB.
2. The MONGODB page is displayed, select the application name.
3. The RESOURCE DETAILS page appears from the right.
4. Click the ellipsis (…) on the top right and select View details.

5. Navigate to the Attributes tab to view the discovery details.

• Click the Metrics tab to view the metric details for MongoDB.

View resource metrics

To confirm MongoDB monitoring, review the following:

• Metric graphs: A graph is plotted for each metric that is enabled in the configuration.
• Alerts: Alerts are generated for metrics that are configured as defined for integration.

Resource Filter Input keys

MongoDB application Resources are filtered and discovered based on below keys:

Supported Alert Custom Macros

Customize the alert subject and description with below macros then it will generate alert based on customisation.
Supported macros keys:

Risks, Limitations & Assumptions

• The application can manage critical/recovery failure alerts for the following two scenarios when the user activates App Failure Notifications in the settings:
  • Connectivity Exception
  • Authentication Exception
• MongoDB will send any duplicate/repeat failure alert notification for every 6 hours.
• MongoDB cannot control monitoring pause/resume actions based on above alerts. Metrics can be used to monitor PowerMax resources and can generate alerts based on the threshold values.
• We have provided 22 as default Port for SSH and 27017 as default Port for MongoDB. Users can modify this value from application configuration page at any point of time if requires.
• Component level thresholds can be configured on each resource level.
• The Template Applied Time will only be displayed if the collector profile (Classic and NextGen Gateway) is version 18.1.0 or higher.
• The minimum supported version for the option to get the latest snapshot metric is Nextgen-14.0.0.
• MongoDB supports both Classic Gateway and NextGen Gateway.
• MongoDB will work only if each Mongo DB instance is configured on different server.
• For a MongoDB cluster, If Standalone Mode is selected part of configuration, only MongoDB Server will get created/updated. MongoDB Replica Set wont be discovered and will get deleted if already exists.

Version History