The Ops Manager Application Server Log Directory is typically located in /opt/mongodb/mms/logs/.

Currently, the log rotation of the Ops Manager log files /opt/mongodb/mms/logs/mms0.log, /opt/mongodb/mms/logs/daemon.log and /opt/mongodb/mms/logs/mms0-access.log are configured by default to rotate the log file every day and compress it with a retention of 30 days. After 30 days the compressed files are deleted.

Please allow the configuration of these log rotation settings through the Ops Manager Web UI.

Currently, this can only be done manually. The default installation of Ops Manager includes a file in /opt/mongodb/mms/conf called logback.xml. This is the file that the library uses to configure Ops Manager logs and log rotation for /opt/mongodb/mms/logs/mms0.log and /opt/mongodb/mms/logs/daemon.log. By default this is configured with the following settings:

`

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">

    <file>${log_path}.log</file>

    <encoder class="com.xgen.svc.mms.util.HeaderPatternLayoutEncoder$Classic">

        <pattern>

            %d{"yyyy-MM-dd'T'HH:mm:ss.SSSZ"} [%thread] %XF{groupId, "gid:%s "}%XF{jobId, "jobId:%s "}%-5level %logger [%file.%method:%line] - %msg%n

        </pattern>

    </encoder>

    <!-- Rollover the logs once per day, keep 30 days, compressed -->

    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">

        <fileNamePattern>${log_path}.%d{yyyyMMdd}.log.gz</fileNamePattern>

        <maxHistory>30</maxHistory>

    </rollingPolicy>

</appender>

`

The file /opt/mongodb/mms/conf/logback-access.xml controls rotation of the /opt/mongodb/mms/logs/mms0-access.log. It has the same <!-- Rollover the logs once per day, keep 30 days, compressed --> policy.

The logs will be compressed and rotated each day and deleted after 30 rolling days. If you modify the maxHistory option to 10, this should delete the files after 10 days. Please note that any upgrade of Ops Manager may overwrite this change with a new configuration file. Additionally, after modifying these values you will need to restart Ops Manager.

The /opt/mongodb/mms/logs/mms-migration.log, mms0-startup.log and daemon-startup.log log files are not rotated as it contains only some log entries generated during the startup/migration phases of the Ops Manager Application Server processes.

Currently, when you use OPS Manager to shard a collection, it automatically creates a foreground index that exactly matches the sharding key, when such index doesn't exist. When the sharding key column(s) is(are)already prefixing an existing index, it's not sufficent.
This is dangerous in Live environments because the whole database is blocked for a long time (sharded collections are usually big collections).
So, several features could exist :
- before continuing with sharding, OPS Manager warns that it needs to create this foreground index first. You can stop if you don't agree (and create this index by yourself first).
- OPS Manager creates instead a background index or creates this index with the rolling manner.
- OPS Manager is able to use one exiting indexes that contains the sharding key as a prefix of this index, no need to create a new one.

It may be desired to place Ops Manager behind a proxy or load balancer based on a URL path (aka sub-directory or prefix). For example, an nginx location may want to proxy pass connections to Ops Manager on "location /opsmanager"
Currently, the Ops Manager Base URL appears to only accept and use the scheme, hostname/domain, and port. Additional path details are ignored by redirects sourcing from javascript functions and html links/resources.

Current workarounds require a unique/dedicated server name for proxying or load balancing to Ops Manager web service(s).

This feature request is for supporting custom URL paths when using Ops Manager behind a proxy or similar network appliances.

When performing an automated snapshot restore in Ops Manager, the MongoDB Agents shut down all MongoDB cluster members while the snapshot(s) are downloaded to the dbPath's.
During this phase of the plan, the MongoDB Agents continue to attempt network connections to the cluster members; as frequently as ~4 per second per mongod. This traffic may pose problems for certain cluster deployment designs. Of note, clusters that are "micro-sharded" (multiple cluster members residing on the same physical hosts) and clusters with members in a remote datacenter can receive an amplification and/or excessive amount of connections relative to what the network can accommodate.

This feature request is to make the MongoDB Agents state aware. If the agent plans call for shutting down the cluster members, skip or avoid frequent network connectivity tests until the download of the snapshot(s) completes.

This enhancement will also have the benefit of reducing spurious error logging during cluster maintenance and restore from backup.