-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[all beats] Remove BEAT_LOG_OPTS from the systemd unit file #12024
Comments
Second this. I had to remove "Environment="BEAT_LOG_OPTS=-e"" from my service file to get logging to go where I specify in the config file. I'm using an rpm on Centos 7. |
We wanted to make beats to log by default to stdout/stderr on systemd-based OSs, so logs are collected by journald, for coherence with other services, see #8942. |
Wouldn't that leave duplicate logs? Making it send to stdout/stderr would log it to In #8942, i see this very issue was already discussed. The problem is, that if you don't have Journalbeat installed, your logs aren't going the place where you specify, leaving it in Having the default configuration file point to stdout/stderr would make a lot of sense. Then its clear for the user where it's going, and makes the change visible. Alternatively, the beat could fail/log that the logging options in the configuration file (if any) are overridden by the systemd unit file. Just making it clearer would be ideal. |
I just ran into this problem. Spent about an hour trying to figure out why the logging config options were being ignored before realizing |
This is incredibly confusing, and I ran into the same issue as @watsonian and similarly wasted a ton of time trying to debug. If there's a setting like this that overrides the other explicit config options, it would be helpful to at least update the docs to give people a heads-up. |
Same here! |
Another point is that if you collect metrics you have no good reason to keep duplicated metrics every x seconds in syslog + elastic. It's a waste of space. So i would like to keep my metrics in separate file and clear them in certain period. |
The problem with having -e in the systemd unit is that if you don't like it, you have to change it every time the package is upgraded, because In theory, it would also be possible to make The packaging system already takes care of preserving changes in |
@sanvila systemd unit files shouldn't be directly modified, you can create a drop-in file to override values. |
Ok, didn't know, thanks a lot. But even in such case, I still think it's slightly better to modify a single file than having to modify a file and create another one. |
this is still an issue for all the beats in 7.4. i spent some time debugging why metricbeat flooded messages file and sucked up all my diskspace. Then i realized all the beats ignores the settings in yaml file. |
I too wasted a ton of time on this expecting my files to be logged per config in filebeat.yml. I'm new to systemd |
To save people some time in the future, I just updated to 7.7 and found that all logging which we previously directed to log files using
stopped working (I'm using The solution is to remove the override as it's apparently no longer being used (even though docs like https://www.elastic.co/guide/en/beats/filebeat/7.7/running-with-systemd.html still actively recommend using
Now my systemd-controlled beats are logging to the log file again. |
thanks, @archon810 . To save even more time:
|
OS Version: I've only tested DEB installations on Ubuntu 18.04, but I'd imagine it happens on all systemd enabled Linux systems
Beat Version: 7.0.0, 7.0.1
In a unit file for any beat
BEAT_LOG_OPTS
is defaulted to-e
This will make logging options in the configuration file obsolete/ignored.
Examples:
Filebeat systemd unit file (snippet):
filebeat.yml (snippet):
Expected result:
Logging to files in the
/var/log/filebeat
directoryActual result:
Logging to
/var/log/syslog
Why not keep all the configurations in the configuration file, instead of having it split up in 2 files: systemd drop in file for logging options, and a configuration file for all other options?
Blindly removing the environmental variable
BEAT_LOG_OPTS
results in the configuration file being used for everything, and for logging to happen in the expected result.Is there ANY reason not to do this? It's both much simpler AND much cleaner for the user.
The text was updated successfully, but these errors were encountered: