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

Be able to configure tracing/log levels #541

Closed
markmandel opened this issue Jun 7, 2022 · 4 comments · Fixed by #574
Closed

Be able to configure tracing/log levels #541

markmandel opened this issue Jun 7, 2022 · 4 comments · Fixed by #574
Labels
area/operations Installation, updating, metrics etc kind/feature New feature or request

Comments

@markmandel
Copy link
Contributor

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.

tracing_subscriber::fmt().json().with_target(false).init();

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.

@markmandel markmandel added kind/feature New feature or request area/operations Installation, updating, metrics etc labels Jun 7, 2022
@XAMPPRocky
Copy link
Collaborator

I have this partially already implemented in the xds PR, I'll pull it out as a separate PR.

@XAMPPRocky
Copy link
Collaborator

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 info, and that you can override it with the RUST_LOG environment variable (which is standard across all Rust related projects). We could also read from the configuration or command line arguments here if desired.

quilkin/src/main.rs

Lines 102 to 108 in 2f7b2cb

let env_filter = tracing_subscriber::EnvFilter::builder()
.with_default_directive(tracing_subscriber::filter::LevelFilter::INFO.into())
.from_env_lossy();
tracing_subscriber::fmt()
.json()
.with_env_filter(env_filter)
.init();

@XAMPPRocky
Copy link
Collaborator

I think we can close this as we now support the standard log configuration variable (RUST_LOG).

@markmandel
Copy link
Contributor Author

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 😄

@markmandel markmandel linked a pull request Sep 22, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/operations Installation, updating, metrics etc kind/feature New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants