Azure
Azure Functions + App Insights: Exception Tracking
The Azure Functions + App Insights integration is super helpful for us (thanks, folks). One quirk of this integration we're struggling with a bit is exceptions tracking.
Duplicate Exceptions
When dealing with dependencies (e.g. cosmosdb or other azure functions via http) in our Azure Functions we tend to wrap/augment any exceptions received from the dependency (e.g. thrown by the cosmos sdk) with our own custom exceptions. Something like this:
(dcx is a DocumentClientException in this example)
This allows us (for example), to treat 409 responses from multiple dependencies the same way when deciding what http status code to return to the caller. Our function methods are wrapped in a try catch in the catch we do something like this to log the exception.
This is what we get in application insights.
One exception is the custom one and the other is the handled and wrapped exception from the cosmos db sdk. The upshot of this is that we get two exceptions for every failure. At high volumes, this is a lot of duplication.
Note that in the above scenario, we return an http status code and the function never "fails." We're logging the exception ourselves with a custom telemetry client.
Lost Exception Properties
What if we let the function fail and let the run time log the exception. We do this in our non http function apps. We still have custom exceptions like the one below.
But in this case we let the function fail and we don't log the exception ourselves. The runtime successfully logs the exception but
- The custom properties on the exception don't make it to app insights.
- We never got a chance to add context properties to the exception telemetry.
Right now we're getting around this by basing the custom properties in the custom exception on the Exception.Data dictionary. We then pull these out and add them to the exception telemetry in a telemetry analyzer. It's working but seems somewhat cobbled together (which it was, around one in the morning heh).
These issues are tangentially related to #1028.
Thanks again for all the hard work on this integration, it really is super useful.
@brettsam
