Reduce log pollution with unnecessary stack traces

Motivation

It’s hard to find relevant information in the log output if it’s polluted with stack traces of non-fatal errors or errors that are gracefully handled and mask the actual issue.

Proposal

Investigate options to reduce non-relevant information in the log, including

• --verbose flag enabling stack traces (and disabling them by default)
• reduce logging level of detail (log only exception msg instead of full exception including stack trace)
• …?

Consideration that may help with the decision-making for these options:

• fatality of potential error
• which kind of information is useful to debug it (e.g. entity dump instead of stack trace)
• can the underlying error be “handed through” / be enriched with more information
• …?

Additional notes

There’s no general “this is the right way to do this”. But we should investigate, brainstorm and discuss how we want to handle it. Also, once we got to an agreement, we might want to document this in the contributor guides.

[keturn]

I think for this discussion we’ll want to grab a few log files as case studies to center the conversation, and take notes on them as we go.

I am imagining this with a bunch of printouts and markers or crayons on a table, but I guess we will have to figure out some remote-friendly way to do it. 😆

[keturn]

Investing more in the logger’s configuration may also involve a side discussion: Do we want to stick with slf4j? I think that part of the java ecosystem has shifted since we adopted it.