Skip to content

Use tracing subscriber to log the log messages#287

Merged
tertsdiepraam merged 10 commits intomainfrom
like-and-subscribe
Nov 6, 2025
Merged

Use tracing subscriber to log the log messages#287
tertsdiepraam merged 10 commits intomainfrom
like-and-subscribe

Conversation

@tertsdiepraam
Copy link
Contributor

@tertsdiepraam tertsdiepraam commented Oct 29, 2025

🌈 Pretty colors 🌈

A next step would be to completely remove the log crate and start using tracing spans to give the logging more info, so we can start doing more filtering (e.g. filter on the zone).~

I apologize for the branch name.

@tertsdiepraam
Copy link
Contributor Author

I'd like to not wait to long with this as I don't want to keep syncing it.

@ximon18
Copy link
Member

ximon18 commented Oct 30, 2025

Just my 10c but if you're touching all the log statements anyway I'd import tracing::xxx and get rid of log:: at the call sites.

@tertsdiepraam
Copy link
Contributor Author

I suppose you're right, this was just easier. I'll see what I can do.

Copy link
Member

@mozzieongit mozzieongit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder why we even keep the log:: and now the tracing:: around instead of just importing the macro itself

}
pub fn launch(config: &LoggingConfig) -> Result<&'static Logger, String> {
let mut filter = EnvFilter::from_env("CASCADE_LOG");
filter = filter.add_directive(LevelFilter::from(*config.level.value()).into());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If CASCADE_LOG specifies a log level of WARN and config sets INFO. Does WARN get logged or is it overridden by INFO from config?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed CASCADE_LOG from here. However, your question still applies to the CASCADE_LOG_LEVEL and I'm getting lost in that code. It's doing what it was before.

@ximon18
Copy link
Member

ximon18 commented Oct 30, 2025

So do I understand correctly that "pretty colours" are only when logging to stdxxx? I don't see the colour codes in the output e.g. when logging to a file and also need to disable daemonizing to see the whole log output on stdxxx.

@tertsdiepraam
Copy link
Contributor Author

So do I understand correctly that "pretty colours" are only when logging to stdxxx? I don't see the colour codes in the output e.g. when logging to a file and also need to disable daemonizing to see the whole log output on stdxxx.

Yes, this was on purpose. Happy to change it. Even for files you can force it with FORCE_COLOR=1. Maybe syslog should include colors? Unsure how to determine that.

Copy link
Contributor

@bal-e bal-e left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blocker: tracing-rfc-5424 is licensed GPL-3.0-or-later. We cannot use it from Cascade.

Unrelated: Do we want to apply a ban on using log::*, like we did for println! / eprintln! for the CLI?

@mozzieongit
Copy link
Member

Yes, this was on purpose. Happy to change it. Even for files you can force it with FORCE_COLOR=1. Maybe syslog should include colors? Unsure how to determine that.

Files should not contain ansi color codes. If a user wants them, they should use FORCE_COLOR=1
Syslog should not include ansi color codes, the log level determines the color in output like journalctl for example.

Copy link
Contributor

@bal-e bal-e left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new syslog code looks great, well done! Some of my comments from my previous review are still relevant, but the main blocker for this PR is gone. I'd still like those answered before we move forward.

@tertsdiepraam
Copy link
Contributor Author

If a user wants them, they should use FORCE_COLOR=1

I did realize that this is currently not possible currently. Do we need that @mozzieongit?

@mozzieongit
Copy link
Member

If a user wants them, they should use FORCE_COLOR=1

I did realize that this is currently not possible currently. Do we need that @mozzieongit?

No

@tertsdiepraam tertsdiepraam merged commit ab8e629 into main Nov 6, 2025
27 checks passed
@tertsdiepraam tertsdiepraam deleted the like-and-subscribe branch November 24, 2025 10:30
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

Successfully merging this pull request may close these issues.

4 participants