/mms/mongodb-releases/ is continually updated with the most current minor release of each major version which can fill the partition.
This request is for "Only download to /mms/mongodb-releases/ those versions actually in use in a deployment"
eg if I am only using 4.2.20 in my actual deployments only download the most recent 4.2.x and not 3.6.x
of course if I do decide to deploy a 3.6.x deployment this FR would need to automatically be bypassed and download my 3.6.x and the most recent 3.6.x.
This request is similar to but not the same as another Feature Request:
[Do not download EOL releases](https://feedback.mongodb.com/forums/924355-ops-tools/suggestions/41942782-do-not-download-eol-releases)

When backup snapshots cannot be completed as scheduled, and they are behind, Ops Manager really should NEVER delete the most recent snapshot. For example, if the snapshot retention policy is to take a backup every 24 hours and keep daily backups for 2 days, and weekly backups for 2 weeks, a new snapshot should not automatically expire after 2 days. If backups are not completing for some reason, and it goes 2 days without a successful new snapshot, the most recent daily backups are deleted and we are left with the most recent weekly backup instead. There really should never be a case where the freshest backup snapshot is automatically deleted.

The following log messages are "info" level messages which can be found in the kubernetes logs from the ops-manager-db pods:

```sh
{"logType":"mongodb","contents":"2020-12-16T02:42:28.557+0000 I WRITE [conn7329] update monitoringstatus.config.agentSessions command: { q: { id: "mongodb-rs-1.mongodb-rs-svc.mongodb.svc.cluster.local-48cc126fc451d9fa2ffa7569363971f2-5fbedc8dc354771c77dd1932", s: "KHNA9JiqXcos5V0d" }, u: { $set: { s: "PRIMARY", p: true } }, multi: false, upsert: false } planSummary: IXSCAN { id: 1 } numYields:0 queryHash:6C451E2F planCacheKey:38AD5486 ok:0 errMsg:"E11000 duplicate key error collection: monitoringstatus.config.agentSessions index: cid1s_1 dup key: { cid: ObjectId('5fbedc8dc354771c77dd1932'), s: \"PRIMARY\" }" errName:DuplicateKey errCode:11000 locks:{ ParallelBatchWriterMode: { acquireCount: { r: 1 } }, ReplicationStateTransition: { acquireCount: { w: 1 } }, Global: { acquireCount: { w: 1 } }, Database: { acquireCount: { w: 1 } }, Collection: { acquireCount: { w: 1 } }, Mutex: { acquireCount: { r: 1 } } } flowControl:{ acquireCount: 1 } storage:{} 200ms"}

{"logType":"mongodb","contents":"2020-12-16T02:42:53.558+0000 I WRITE [conn129189] update backupagentstatus.backupAgentSessions command: { q: { groupId: ObjectId('5fbedc8dc354771c77dd1932'), tag: "unassigned", $or: [ { sessionKey: "5fd130ec9621b221acd18451" }, { heartbeat: { $lt: 1608086273347 } } ] }, u: { $set: { groupId: ObjectId('5fbedc8dc354771c77dd1932'), tag: "unassigned", sessionKey: "5fd130ec9621b221acd18451", heartbeat: 1608086573347, hostname: "mongodb-rs-0.mongodb-rs-svc.mongodb.svc.cluster.local", addr: "10.200.30.0" }, $inc: { callsSinceSuccess: 1 } }, multi: false, upsert: true } planSummary: IXSCAN { groupId: 1, tag: 1 } keysInserted:1 numYields:0 queryHash:5BA6C0B5 planCacheKey:AEFF88E2 ok:0 errMsg:"E11000 duplicate key error collection: backupagentstatus.backupAgentSessions index: groupId1tag_1 dup key: { groupId: ObjectId('5fbedc8dc354771c77dd1932'), tag: \"unassigned\" }" errName:DuplicateKey errCode:11000 locks:{ ParallelBatchWriterMode: { acquireCount: { r: 1 } }, ReplicationStateTransition: { acquireCount: { w: 1 } }, Global: { acquireCount: { w: 1 } }, Database: { acquireCount: { w: 1 } }, Collection: { acquireCount: { w: 1 } }, Mutex: { acquireCount: { r: 1 } } } flowControl:{ acquireCount: 1 } storage:{} 209ms"}
```

Despite the fact that the word "error" is in these logs many times, and they have an error code, error name, and error message, this is considered an info level log.

This is because the letter I is after the date. This makes using regex really hard when trying to setup alerts and monitoring, if I wanted to exclude info level logs.

It would be great of instead of using a letter like I, W, or E, a word or abbreviation was used such as INFO, WARN or ERROR.

What is the problem that needs to be solved? In some rare situations where upgrade of Cloud Manager's MongoDB Agent to the latest version leads to Golang panic (or any other critical issue) there's no way for Cloud Manager user to rollback MongoDB Agent version in case if this environment is running in Kubernetes Operator. The script which launch MongoDB Agent is using the latest version from Cloud Manager Project, without any option to change it other then editing the script itself which is not possible in Kubernetes pod.

Why is it a problem? (the pain) If after Cloud Manager's MongoDB Agent upgrade there are some critical issues (constant Golang panic, etc.) the user will be stuck awaiting MongoDB to rollback MongoDB Agent version in required Cloud Manager Project.

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.