Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Fluent logs were written to disk in order to: 1. Avoid a feedback loop of collecting its own logs 2. Allow collector investigation when there are issues by being able to review persistent logs. This strategy has proven to be problematic and can lead to node issues if fluent log rotation is now working properly and logs are not being cleaned up. Logs should be reverted to be written to stdout and excluded from collection. The pattern for the container logs for thcollector: sh-4.4# ls | grep fluent fluentd-m65p9_openshift-logging_fluentd-591768f9629810d85fbe623c4afc76bd96424e67e48ccdc2128f40cd0a94611d.log fluentd-m65p9_openshift-logging_fluentd-9872757d29cc899822c2586f9e519c8d365044ab7330371564085ba6e600fbf6.log Possibly partially responsible for https://bugzilla.redhat.com/show_bug.cgi?id=1780698
This should be backported to 4.2 and 4.3
Tested with ose-cluster-logging-operator-v4.4.0-202002050701, the fluentd pod logs are set to stdout, and aren't collected to the ES. But there still have the env vars `LOGGING_FILE_*` in the fluentd pods, should these env vars be removed ? # oc exec fluentd-6rkql env |grep LOGGING_FILE LOGGING_FILE_PATH=/var/log/fluentd/fluentd.log LOGGING_FILE_AGE=10 LOGGING_FILE_SIZE=1024000
(In reply to Qiaoling Tang from comment #4) > Tested with ose-cluster-logging-operator-v4.4.0-202002050701, the fluentd > pod logs are set to stdout, and aren't collected to the ES. > > But there still have the env vars `LOGGING_FILE_*` in the fluentd pods, > should these env vars be removed ? > > # oc exec fluentd-6rkql env |grep LOGGING_FILE > LOGGING_FILE_PATH=/var/log/fluentd/fluentd.log > LOGGING_FILE_AGE=10 > LOGGING_FILE_SIZE=1024000 We will do this as tech debt
Per c4 and c5, move this bug to VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:0581