-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Preserve the dedicated stack trace object all the way to encoder #1373
Comments
Hey @oakad, thanks for filing this. There's also an active PR right now (#1371) to support changing how stack traces are encoded. |
One may easily argue that stack traces are the most import pieces of info error log messages carry. So any improvement over the present basic encoding will be welcome. |
Right now, when stack trace is requested (via an annotation on a level enabler or via an explicit field) it is simply formatted into a largish string and treated like a simple string field. However, stack traces these days can be subject to analysis by automatic tooling and otherwise manipulated.
I think it will be beneficial to:
stacktrace.Stack
object publicly visibleStack
field to carry that object and not a stringstacktrace.Stack
object. The default encoder can keep using the default formatter, whereupon user provided encoder can do something more advancedTo my opinion, implementing this improvement is easy and seamless for most users. It will also allow for much safer processing of stacks in the log analysis systems as users will have the choice to supply their own encoders which can encode stack traces in analysis friendly way.
The text was updated successfully, but these errors were encountered: