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

add option to split streams on severity #671

Closed
wants to merge 1 commit into from

Conversation

krancour
Copy link

Fixes #403

#403 was closed with the following rationale:

Yeah, we won't support this directly in core since the use-case is too narrow. A custom hook or formatter is recommended.

Since that that time, I've humbly proposed that the use case may not be so narrow. (See comment.)

@sirupsen any chance you could consider re-opening this? I think there are log forwarders or aggregators that will assume messages received on stderr are indeed errors and therefore augment the message with text like ERR (for instance).

A co-worker recently ran into this with Cloud Foundry:

2017-09-08T06:38:28.86+0000 [APP/PROC/WEB/0] ERR time="2017-09-08T06:38:28Z" level=info msg="setting log level" logLevel=DEBUG
2017-09-08T06:38:28.86+0000 [APP/PROC/WEB/0] ERR time="2017-09-08T06:38:28Z" level=info msg="API server is listening" address="http://0.0.0.0:8080"

Given the prevalence of various container orchestrators and PaaSes and the wide array of log forwarders and aggregators they use (fluentd and logspout come to mind), this issue is likely to affect more and more people.

Since we need this functionality to continue using logrus, I decided to see what I could do with a hook, as had been suggested. I found, quickly, that using a hook wasn't the best idea from a performance standpoint. While I'd be relying on the hook to actually output formatted messaged to os.Stdout or os.Stderr, I'd have to set the logger's Out field to something like ioutil.Discard to avoid getting duplicate messages-- and that's totally fine, except for the fact that the overhead of formatting the message is then incurred twice over, only to discard it in one of those two cases. This didn't seem optimal.

Given the upvotes on my proposal that this may not be a narrow use case, I decided to look into how easy it might be to add support for this behavior directly into logrus. It wasn't hard as it turns out, and this PR is the result of that effort.

Please note that, quite importantly, this change preserves original behavior and merely enables the option to split log messages across two different io.Writers, depending on log message severity.

@emidander
Copy link

+1

@krancour
Copy link
Author

krancour commented Dec 1, 2017

@sirupsen is this something you could review?

@jeremyrickard
Copy link

+1

1 similar comment
@chrisva
Copy link

chrisva commented Jun 28, 2018

+1

@rubens21
Copy link

+1

1 similar comment
@huynvk
Copy link

huynvk commented Feb 21, 2020

+1

@jackzzj
Copy link

jackzzj commented Mar 4, 2020

Is this merged ?

@krancour
Copy link
Author

krancour commented Mar 5, 2020

It's not. I opened it and closed it after a year since I inferred that @sirupsen had no interest in this change.

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.

How to separate Stdout and Stderr output?
7 participants