Audit logs - Phase1: Forward existing audit logs to the standard container/pod logs

For benefit of On Prem customers (and for Support to minimize use of Rails console for SaaS customers?): forward all existing application logs to the standard container/pod logs, so they can be queried with EFK, plus docs on how to do this. Users want the logs all in one place

@hery says something like

Openshift pod is multiple containers but when we deploy some of the logs are not forwarded to standard output. Some of our pods may not forward the outputs to the logs and they want to do it for all the logs. We need to verify that.
Sidekiq, unicorn, tagging the logs, database, request queryID,....what else?
Also what should we be logging?

Dev notes

Simple proposition

For many models we store in the database some audits with the audited gem

What we could do is to redirect a simple version of this information into the logs.
We will output the minimal required information:

• Type of the action (Create/Delete/Update)
• Object type
• ID of the object
• Name of the fields changed and its value.
• Date of action
• Type of action (Creation, Update, Deletion)
• ID of the user triggering the action if available (no user when triggered by a background job)
• Role of the user triggering the action if available

That will not solve the case when the event was unsuccessful. E.g. A user tried to create a service but an error occurred.
Given that information, in the phase 2, the customer can use the API to have more details on the changed fields.

Implementation idea

• Add a after_commit to https://github.com/3scale/porta/blob/master/config/initializers/audited_hacks.rb dumping the simplified content of the audit to the log
• Wrap it into a feature so the provider can opt-in
• Make sure we fill user with something when not available (e.g. events triggered in the background)

We will iterate over this base, including later more events and stream information to the logs.