Reassigning to the master team. This bug is for best practices/settings capturing kubelet and master API logs + auditing, not the elasticsearch logging component.
In all cases/versions, the logging levels set by default represents the levels desired to identify error conditions within the software and the time they occur. Existing serviceability tools (sosreports) collect the required payloads for reporting issues to engineering.
Prior to 3.7, it is generally recommended to keep audit logging disabled. There is no mechanism to filter the audit log to particular usage patterns (external actors, etc.). Depending on the amount of output generated here for a particular cluster workload, enabling or disabling the audit log is an installation by installation decision.
After 3.7, it is possible to enable audit logging for external usages of the API only. It is documented in 3.7+ . This may or may not be desirable depending on the patterns of interaction with the cluster and any historical issues which may exist for the organization.
We should follow up with specific recommendations on a case by case basis via CEE.
1 - https://access.redhat.com/documentation/en-us/openshift_container_platform/3.7/html-single/installation_and_configuration/#master-node-config-advanced-audit.
For 4.0, we should identify a brief meaning behind the numerical logging levels and identify the default to provide an idea the additional levels of output that will be received.
In 4.0, audit logging is enabled by default. We should identify how it can be filtered and under what situations you might want to filter it or disable it entirely (and how). This is likely the opposite of what is currently documented.
> In 4.0, audit logging is enabled by default. We should identify how it can be filtered and under what situations you might want to filter it or disable it entirely (and how). This is likely the opposite of what is currently documented.
I agree about a doc describing how to disable it. As for filtering we need thorough docs (with examples) and explanation of the default policy we need to create (see https://jira.coreos.com/browse/MSTR-264). That should provide sufficient information for any administrator to confidently update their policy.