-
Notifications
You must be signed in to change notification settings - Fork 99
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
Be able to configure tracing/log levels #541
Comments
I have this partially already implemented in the xds PR, I'll pull it out as a separate PR. |
Since that's now merged, we can see how we're doing it currently, which is that we use by default we set it to Lines 102 to 108 in 2f7b2cb
|
I think we can close this as we now support the standard log configuration variable ( |
Let's leave this open until we get the updated documentation (tagged as an item for 0.4.0). Not feature complete until it's been documented 😄 |
Is your feature request related to a problem? Please describe.
With the original use of
slog
debugger the logging level was tied to the build level - debug logging on the debug build, and info logging on release.See: https://googleforgames.github.io/quilkin/main/book/using.html
As far as I can tell, it seems there is no current control mechanisms for log levels with Quilkin, since tracing_subscriber doesn't have configuration by env var or similar.
quilkin/src/main.rs
Line 76 in 37423cd
Describe the solution you'd like
My initial thought is to include a
logging
(tracing
?observability
? something?) section in the config yaml that allows configuration of tracing levels, and probably also output format, as outlined in #531 (since tracing levels control not just logging, but also overall tracing in the system).An EnvFilter would likely also be useful to incorporate to be able to provide fine grained control over logging levels throughout the system, and be able to enable more verbose debugging at one specific parts of the system.
Describe alternatives you've considered
We could use something like env_logger or use a command line argument, but I think it would be best to keep as much of the configuration as possible in a single place, in the yaml file.
Additional context
This work should also include review of if we need both a debug and release build and image of Quilkin anymore, as the original purpose is no longer required.
The text was updated successfully, but these errors were encountered: