First of all, thanks guys and gals for putting this course together! 
So I completed this course two days ago and wanted to raise a few general queries re Auditing in MongoDB. Here goes:
- Collection as a destination for audit logs: Currently, there are 3 destinations for audit logs; file, syslog and console. It would have been beneficial to have the option of outputting to a special audit collection and separate db. Oplogs are stored in a collection, so a similar concept could have been applied to audit logs. That way we can query audit logs (very useful), have a capped audit collection, encrypt, compress, TTL at collection level etc… and do other nice things that come with the WiredTiger and MongoDB alliance.
- Collection as a source for configuring auditing params: Considering the nature of MongoDB schemas, it’s a perfect structure (besides YAML) for setting up the configs for audit logs. Abstract the audit config from the DB config file!
- Changing filter params on-the-fly: Without doing a rolling upgrade, it’s quite tedious to add/edit/drop filters. This is because the config for audit logging is tied to the DB config file! In some organisations, auditing operations are not periodic/static and can change fairly frequently. If audit logs were configurable in a collection as per point 2, it would have been so much easier to add/edit/drop multiple auditing filters, and have timestamps of when a filter was setup, by whom, on what resource, and for how long.
-
TTL on filters and Rotate Logs: Imagine a fictitious scenario where I want to audit the following users: @kanikasingla, @Sonali_Mamgain, @Shubham_Ranjan and @Muskan_47318 for one week
, I can’t do that with ease 
. I have to remember to remove the filter a week later and in addition, perform a rolling upgrade each time. There’s no reference of this in the docs for Ops/Cloud Manager. No references to Stitch (Triggers) please! - Cap log size: The ability to set the max size of the log file to stop it from outgrowing set limits and/or overwriting data when a certain quota is reached. As per point 1, if audit logs were stored in a collection, that’s also backed by a compressed DB, this would have been possible using the existing concept of capped collections. And with this, it would have been easier to rotate the log when a quota is hit.
- Alerts and Monitoring: Being able to monitor and respond to events related to auditing seems very limited in this regard. Even with the integration with New Relic, I can’t see anywhere in the Ops/Cloud Manager docs that describes a robust way of handling this.
The documentation for Ops Manager and Cloud Manager touches on a few of these pain-points but I don’t see much improvement.
In my humble opinion, auditing should be detached from the DB config file. And a fresh approach on how Audit Logging in MongoDB is structured and handled should be considered; one that really leverages the power and resources of existing MongoDB/WiredTiger capabilities.
Thoughts, comments? Anyone?
Disclaimer: for your sanity, ignore any typos/grammatical errors 
