You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.
The text was updated successfully, but these errors were encountered: