Edit/filter call stack of ExceptionTelemetry for better readability

[Kile-Asmussen]

Is your feature request related to a problem?

Currently, for my application, exception telemetry as reported in the portal.azure.com widget have unusably bad call stacks. 75% of all the lines in the call stack are taken up by internal calls in the compiler, making it very difficult to see what calls in my own application code are visible.

The callstack visible in ApplicationInsights is VERY DIFFERENT from the StackTrace property of the exception that was thrown, which is confusing in diagnosing problems. I find myself often copying over the callstack and editing it in a text editor just to be able to read it

Describe the solution you'd like.

It would be very convenient if in a TelemetryProcessor, it was possible to somehow edit the "Call Stack" field as seen in the portal.azure.com widget. Filter out lines of the frames that are not useful, etc.

Describe alternatives you've considered.

Creating new Exception Telemetry events from scratch in a processor. Does not seem to fully work for unknown reasons.

Using reflection to access internal/private classes and properties. The data is available in internal fields/properties, which I can see with my debugger, but editing them does not seem to work reliably.

Switching all my exception telemetry to Custom Events. Undesirable for obvious reasons, if easy.

Switching our entire tech stack to OpenTelemetry. Expensive.

Additional context.

It's a pretty sad state of affairs.

[harsimar]

Hi,
Just to give some context regarding exception parsing, there was an intentional decision made in Application Insights 2.x regarding how the stack was parsed - essentially the frames would be ordered from outermost to innermost frames (to a specific limit), to allow for the most useful stacks to be closer to the top. As an example, if there were 6 frames, it would be in the order of 1 6 2 5 3 4.

We are currently working on Application Insights 3.x, which is now based on OpenTelemetry and uses the Azure Monitor OpenTelemetry exporter internally. My current observation is that with 3.x, you will see the same behavior when using TrackException(), as the exporter parses open telemetry log based exceptions in the same way.

I understand that in your case, it isn't convenient to have exceptions parsed in this way. There are a couple of alternatives I can think of when using ApplicationInsights 3.x:

• Which overload are you using to call TrackException? Perhaps before calling TrackException, you can retrieve the stack trace of the exception, parse through it how you see fit, and put the parsed result into a custom dimension for the exception telemetry. It wouldn't directly edit the "Call Stack" field, but you could query Log Analytics for the custom dimension and get your sanitized stack trace from there.
• OpenTelemetry has the concept of processors - you could try creating a BaseProcessor to process the LogRecord.Exception and put the information you need into a different attribute of the log record.

Not knowing which parts of the stack trace would be relevant to you, it would be difficult for us to implement a processor that gets applied to everyone. We also won't be investing further effort into Application Insights 2.x TelemetryProcessors, as those are removed in 3.x. OpenTelemetry is the industry standard which we have chosen to adopt moving forward.