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

log levels #122

Open
travi opened this issue Sep 25, 2018 · 0 comments
Open

log levels #122

travi opened this issue Sep 25, 2018 · 0 comments

Comments

@travi
Copy link
Member

travi commented Sep 25, 2018

Is your feature request related to a problem or a specific use case? Please describe.

i've wanted to include the more detailed logs from traverson in our log aggregator, but hadn't had enough reason to follow through until today. i was able to pipe from minilog to a writable stream that turns around and calls logger.trace() on our instance of a bunyan logger.

as i looked deeper into the traverson log output, i realized that there are some of the details that provide a useful story of the steps that happen, but others that are probably a little more detailed than would be useful in this case. i see that minilog provides some level of filtering that could be applied before i pipe to bunyan. however, it appears that all of the traverson logs are at the debug level.

Describe the solution you'd like

more separation of levels would enable simple whitelist/blacklist filtering by those levels. do you think there would be some level of logical grouping that could be applied to the logging?

the logs that seemed natural for me to aggregate were the ones like:

  • link for x found
  • request started
  • request returned

logs like the implementation of a transform function to be applied seemed less useful for the use case i was after, so could possibly make sense at a more detailed log level.

Describe alternatives you've considered

since minilog and the writable stream is all pipes, i could certainly write my own custom filter for minilog or be more selective of what was actually written to logger.trace() on the bunyan side of things. however, those options would require deeper inspection of the content of the messages and would run the risk of not matching if that content changed in the future.

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

No branches or pull requests

1 participant