Skip to content
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

"Changing what is shipped" doesn't change but adds log paths #93

Open
sajoupa opened this issue Apr 1, 2022 · 3 comments
Open

"Changing what is shipped" doesn't change but adds log paths #93

sajoupa opened this issue Apr 1, 2022 · 3 comments

Comments

@sajoupa
Copy link

sajoupa commented Apr 1, 2022

The documentation indicates that the operator can change the log files that are shipped with the 'logpath' config item:

Changing what is shipped
By default, the Filebeat charm will ship any container logs present in /var/lib/docker/containers as well as everything in:

/var/log/*/*.log
/var/log/*.log

If you'd rather target specific log files:

juju config filebeat logpath=/var/log/mylog.log

But the actual behaviour is that the contents of logpath are added to the configuration files, in addition to the defaults.
I believe that the charm should do as documented, which is to replace "what is shipped".

@gtrkiller
Copy link

gtrkiller commented May 11, 2022

The juju config command is working as expected on a basic installation of the filebeat charm with ubuntu made from scratch. Could you please give more details about your environment, charm version and such to reproduce the error accordingly?

This is what I did:

# Deploy and relate everything
juju deploy ubuntu
juju deploy filebeat
juju relate filebeat ubuntu

# Wait for relation and deployment

# Confirm default paths in config file
juju ssh ubuntu/0 cat /etc/filebeat/filebeat.yml

# Change paths
juju config logpath='/var/log/merci.log'

# Confirm only configured path is as above
juju ssh ubuntu/0 cat /etc/filebeat/filebeat.yml

@mthaddon
Copy link

Have confirmed the environment in question is using cs:~filebeat-charmers/filebeat-24. We should confirm if this exhibits the behaviour described, and if so, it seems upgrading the charm (currently released version on https://charmhub.io/filebeat is 33) will fix the issue.

@mthaddon
Copy link

I've compared what's deployed on a unit in this juju model and found no significant differences. I think at this point we can't tell exactly what revision was deployed at the time of the issue, so all we can do is ask for the charm to be upgraded to the most recent version (version 33 on https://charmhub.io/filebeat), and if the issue persists, please report here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants