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

Allow customizing formatting of stack traces #1532

Open
anuraaga opened this issue Mar 11, 2021 · 2 comments
Open

Allow customizing formatting of stack traces #1532

anuraaga opened this issue Mar 11, 2021 · 2 comments
Labels
spec:trace Related to the specification/trace directory

Comments

@anuraaga
Copy link
Contributor

Currently we define that stack traces are always formatted in a certain way using the standard language formatters. But some users may need to reformat the trace. SDKs could provide an option, such as a function mapping exception to string, to allow this.

@anuraaga anuraaga added the spec:trace Related to the specification/trace directory label Mar 11, 2021
@iNikem
Copy link
Contributor

iNikem commented Mar 11, 2021

But some users may need to reformat the trace.

Can you give an example of such use-case?

@HaloFour
Copy link

HaloFour commented Mar 11, 2021

This is a situation that I am dealing with at the moment. We are using OpenTelemetry to trace our Spring WebFlux applications and export the span information to ECS-formatted logs which we then ingest into a shared Splunk instance. The problem is that Spring WebFlux stack traces are generally absolutely ginormous and Splunk will only parse and map JSON fields up to a certain size per event. This is causing the majority of log events representing a span containing exception information to not be indexed properly in Splunk.

The functionality to reformat stack traces is very common in logging libraries and I would suggest that offering at least the ability to format the stack trace would be helpful, even if the SDK or Instrumentation doesn't offer any implementations out of the box beyond the default for the given language.

Also, see: #955

I'd also be happy if the raw exception/error information were to flow through perhaps as a type of event or attribute which would allow any given exporter the freedom to interpret it and for logging exporters specifically to take advantage of whatever formatting configuration exists in that logging library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec:trace Related to the specification/trace directory
Projects
None yet
Development

No branches or pull requests

3 participants