opentelemetry-collector-contrib: [exporter/googlecloud] Correctly translate exception-events from OpenTelemetry to Google Trace format
The OpenTelemtry spec provides info on exception-handling that is based adding exception-info as Event: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/exceptions.md
Currently, the exception-events passthrough as-is without any extra processing, which leads to following representation in Trace UI:
Notice that the stacktrace above is incomplete and has been character-limited by GCP, which significantly reduces its usefulness.
Meanwhile, referencing the following screenshot from: https://cloud.google.com/trace/docs/trace-labels
The above screenshot includes a specially formatted section for displaying call-stack, which is extremely helpful.
So it would be great if the exceptions exported by OpenTelemetry could be formatted to Trace’s conventions to allow displaying them in correct format as achieved by using native Google.Diagnostic
libraries. This seems to require a rather tricky stack-trace parsing (especially considering different languages will have their own stack-trace representation), but is there a possibility to develop some conventions to improve the feasibility of this (such as expecting special tags within spans/traces with segments of pre-parsed stack-trace)?
Just in case, .NET Core is my primary development language here and it seems to have fairly under-developed libraries for exporting Otel data to GCP, which is one of the major reasons for using OpenTelemetry Collector.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 17 (10 by maintainers)
Finally had the chance to try this out. Though adding the
exception.stacktrace
attribute didnt quite work, it just adds a/stacktrace
label in UI with clipped stacktrace text (same result as issue description).@dashpole any further thoughts on the intermediate workaround (https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/12885#issuecomment-1210018097)
I don’t know if that would be a great contract for the exporter to have. It would be fairly difficult for clients to implement correctly, so I would prefer having something in the exporter. I’m wondering if starting with something as simple as “split the stacktrace into one attribute for each line” (e.g.
exception.stacktrace.0
,exception.stacktrace.1
) would make this useable while we figure out how we want to handle this…