Problem Statement,
What is the problem? As of now (2021-03-17) Ops Manager does not support downloading MongoDB Server Audit process logs via UI/API. Atlas does have support for it (via GET /groups/{GROUP-ID}/clusters/{HOSTNAME}/logs/{LOG-NAME} API call).

Why is this a problem? Users needs to be able to download MongoDB Server Audit process logs via Ops Manager, same way as they do for MongoDB Server process logs/FTDC and MongoDB Agent logs (this significantly simplify troubleshooting, when required). Some users require to download MongoDB Server Audit process logs programmatically to store them in Security Information and Event Management (SIEM) system.

Proposal,
* Add MongoDB Server Audit process logs option support in POST /groups/{PROJECT-ID}/logCollectionJobs and in GET /groups/{PROJECT-ID}/logCollectionJobs/{JOB-ID}/download Public API calls as well as in Ops Manager Project UI. This will align functionality between Atlas and Ops Manager.

What is the problem that needs to be solved? Send an alert over all/selected alert channels, if all/selected alerts can't be delivered by Ops Manager's Application Server.

Why is it a problem? (the pain) We can miss an alert (or multiple alerts) from Ops Manager's Application Server if configured alert channel become unavailable since all Ops Manager Alerts are working in fire-and-forget style without any checks/mechanisms to see if the alert was delivered (some alert types can't have that guarantee at all (e.g. SNMP Alert Traps)).

Ops Manager - Alerting Framework.png flow diagram has been attached to this Feature Request with the desired outcome.

At present if a collection has a default collation configured, sharding such a namespace via Ops Manager results in a failure with the following symptom:

<myCluster_mongos_131> [13:21:17.050] Plan execution failed on step ShardCollections as part of move ShardCollections : <myCluster_mongos_131> [13:21:17.050] Failed to apply action. Result = <nil> : <myCluster_mongos_131> [13:21:17.050] Error calling shardCollection on sh.myColl with key = [[a 1]] : <myCluster_mongos_131> [13:21:14.994] Error executing WithClientFor() for cp=mubuntu:27017 (local=false) connectMode=AutoConnect : <myCluster_mongos_131> [13:21:14.993] Error running command for runCommandWithTimeout(dbName=admin, cmd=[{shardCollection sh.myColl} {key [{a 1}]} {unique false}]) : result={} identityUsed=mms-automation@admin[[MONGODB-CR/SCRAM-SHA-1]][24] : (BadValue) Collection has default collation: collation: { locale: "fr", caseLevel: false, caseFirst: "off", strength: 3, numericOrdering: false, alternate: "non-ignorable", maxVariable: "punct", normalization: false, backwards: false, version: "57.1" }. Must specify collation {locale: 'simple'}


In addition there is no way to specify a default collation if a collection is created via Ops Manager UI.

Please add support of default collation.

What is the problem that needs to be solved? Ops Manager's Org ID/Org Name/Project Name attributes needs to be added to Project (GET /groups/{PROJECT-ID}/alerts) / Global (GET /globalAlerts) Alerts API calls and Alert Webhooks.

Why is it a problem? (the pain) Ops Manager's Org ID/Org Name/Project Name attributes are currently missed in Project (GET /groups/{PROJECT-ID}/alerts) / Global (GET /globalAlerts) Alerts API calls and Alert Webhooks. Operator who watch Monitoring System (the one that receive Ops Manager Alerts) needs to see Ops Manager's Organization ID/Organization Name/Project Name in order to quickly understand to where that Ops Manager's Alert is related to. Monitoring System (the one that receive the alert from Ops Manager) needs to do additional work for alert received (via GET /groups/{PROJECT-ID} GET /orgs/{ORG-ID} API calls (if possible at all)) in order to resolve Ops Manager's Project ID (which is included into every alert) into Ops Manager's Organization ID/Organization Name/Project Name.

When setting a Programmatic API Key in the MongoDB Ops Manager for a given Project, it seems Project Owners are unable after setting the Key to update the IP Whitelist as they require Organization User Admin role to perform such action (screenshot attached).

I guess this makes sense if the same Programmatic API Key is shared between multiple Projects inside the same Organization, but not really if this is applied only to one single Project (i.e. Project Owners should be able to amend the IP Whitelisting of their own API Keys).

I wonder if this could be enhanced in further Ops Manager upgrades.