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

Set log_path in system config #4418

Closed
jocobwknight opened this issue Feb 28, 2024 · 5 comments · Fixed by #4604
Closed

Set log_path in system config #4418

jocobwknight opened this issue Feb 28, 2024 · 5 comments · Fixed by #4604
Labels
enhancement Feature request or improve operations

Comments

@jocobwknight
Copy link

Is your feature request related to a problem? Please describe.

I'm setting up AWX to install FluentD on VMs (not in Containers). Ansible's "ansible.builtin.service" doesn't have command line arguments like "-o" because it's using systemctl. So the logs can only be defaulted to /var/log.

Describe the solution you'd like

I'd simply like "log_path" to be an attribute I can set in the section of FluentD's config file. It's an attribute that can be set with command line arguments, but not in the config file.

Describe alternatives you've considered

I could modify the service file to include the "-o" command line argument, or have Ansible modify the code directly like in the system_config.rb file and so on so that attribute becomes available. In either case though it would just be a hacky temporary solution.

Additional context

My /var/log directory is mounted to a low capacity drive because we expected to be able to store all fluent related data in our /opt directory. For now I can set the log rotation very tightly to keep it from filling up, but I think the log path being configurable in the global settings file is a deserving feature that I'm surprised doesn't exist already.

@daipom daipom added feature request *Deprecated Label* Use enhancement label in general and removed waiting-for-triage labels Mar 7, 2024
@daipom
Copy link
Contributor

daipom commented Mar 7, 2024

I don't know why system_config does not have log_path option...
I'm wondering if there was a reason for this, but it seems more convenient to be able to set it up in the config file.

@daipom
Copy link
Contributor

daipom commented Mar 7, 2024

I could modify the service file to include the "-o" command line argument,

I think this is the main case now.
In Fluent Package, It is supposed to be set in a unit file or as environment variables.

https://github.com/fluent/fluent-package-builder/blob/1bd0d76c2e13a94a8d93c30bb51096e54d77bbf1/fluent-package/templates/etc/systemd/fluentd.service.erb#L32

ExecStart=/opt/<%= package_dir %>/bin/fluentd --log $FLUENT_PACKAGE_LOG_FILE --daemon <%= Shellwords.shellescape("/var/run/#{package_dir}/#{service_name}.pid") %> $FLUENT_PACKAGE_OPTIONS

@kenhys kenhys added enhancement Feature request or improve operations and removed feature request *Deprecated Label* Use enhancement label in general labels Jul 31, 2024
@Athishpranav2003
Copy link
Contributor

@daipom is this still active or the ENV variable method is your proposed fix?

@daipom
Copy link
Contributor

daipom commented Aug 14, 2024

@Athishpranav2003 Sorry for my late response.
Thanks for considering it!

I don't know why system_config does not have log_path option...
I'm wondering if there was a reason for this, but it seems more convenient to be able to set it up in the config file.

The reason would be that Fluentd needs to know the path before parsing the config file.
Fluentd outputs some logs before parsing.

It would be convenient if we could specify the path in the config file, but then there would be the problem of how to handle the logs before parsing.

If we can come up with a good solution, we can improve it, but if not, I don't see the need to force it.

@Athishpranav2003
Copy link
Contributor

Oh i see. It makes sense that the parsing logs are also crucial and they seem to create a problem here. I am currently not sure of any sol but maybe there is some way to tackle this. Ideally we can solve this by having a default logging destination and change that+copy the initial logs to the configured directory once its obtained. Idk what issues might occur in this case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature request or improve operations
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants