We upgraded from 8.15.3 to 8.16.1 and found that filebeat started filling up syslog with debug log messages. It seems to ignore the to_syslog: false config. Downgraded to 8.15.3 and the problem was gone. Did we miss changes to logging or other major changes that could cause this?
Here is our current config.
BEAT_LOG_OPTS=
and
logging:
files:
keepfiles: 3
name: filebeat.log
path: /var/log/filebeat
level: debug
to_files: true
to_syslog: false
Hi @t.alexandersen , could you share how you're running and installed Filebeat?
Is it running via Systemd?
What are the CLI arguments passed to Filebeat?
Can you share the output of ps aux |grep filebeat
?
Your logging configuration is correct, so Filebeat should be logging only to /var/log/filebeat
. Filebeat does not support multiple log outputs.
Can you see the log files on /var/log/filebeat
?
Are they correctly updated/are they active while Filebeat is running?
Hi @TiagoQueiroz
Thanks for following up.
We found the reason for the new behaviour. It is caused by this issue:
opened 06:50AM - 25 Nov 24 UTC
needs_team
Filebeat versions of 8.15.4 and higher no longer logs to "logging.files.path" wh… en "logging.to_files: true" is set, unless "logging.to_stderr: false" is explicitly set.
In versions <=8.15.3, setting "logging.to_stderr: false" was not required for "logging.to_files: true" to be honored.
- Filebeat >=8.15.4:
- Operating System: Rocky Linux 8.10, Ubuntu 22.04.5
- Steps to Reproduce:
1. Run Filebeat version >=8.15.4 with the following logging configuration:
```
logging.level: info
logging.to_files: true
logging.files:
path: /var/log/filebeat
name: filebeat
keepfiles: 7
permissions: 0640
```
2. Log files are not created under "logging.file.path".
3. Revert to running Filebeat <=8.15.3 with the same configuration.
4. Log files are created under "logging.file.path".
I see nothing in the release notes about this behavioral change, is it expected?
logging.to_files: true is no longer honored unless you set logging.to_stderr: false.
The workaround is to add logging.to_stderr: false to your config.
Thanks @t.alexandersen
I'm just a bit puzzled because I still cannot reproduce it.
Could you try reproducing with the configuration from my comment and also post here the output of ./filebeat version
?
In the GitHub issue we managed to find the root cause and a workaround. Look at the issue for more details.
As a workaround, one can set logging.to_stderr: false
to stop logging to stderr.
Here is an example of how to get logging back to files:
logging.level: info
logging.to_files: true
logging.to_stderr: false