Program errors are unavoidable. No one understands every single line of a framework or an operating system. The operating system cannot affect battery level or network overload. Reaching high availability is a process in which feedback plays an irreplaceable role.
There is nothing easier than sending an HTTP request when an exception is thrown and logging it on your server. At least in the time of C# 6.0, which supports an await in a catch block. Before this highly useful feature, it was wise to use some analytics service. Application Insights in Visual Studio Online was a very beneficial one.
Sometime later, Application Insights was moved to the new Azure Portal. I would leave it without any comment if the hierarchical event tree had been kept. You could use a slash in the event name, and the name before the slash was used for grouping events. This feature is now outdated.
Another amount of time later, Microsoft acquired HockeyApp. The reason was that Microsoft had been using HockeyApp with many in-house developed apps. It was cheaper to acquire HockeyApp than to invest in in-house Application Insights.
After the acquisition, all Application Insights customers were forced to move to HockeyApp. Changing measuring codes wasn’t necessary, but every developer knows that unsupported means dead, so the change is just a question of time. Nobody would expect full-featured HockeyApp analytics anyway.
I identified two main disadvantages of HockeyApp compared to Application Insights. After two years of HockeyApp integration, they are still present and unresolved (adequately).
The first problem is that not all handled exceptions can be reported. Crashes are reported by a completely different system. Crash data are available in the Dev Center, but two-thirds of them are described as Unknown even if the program debug database file is provided.
The second problem is that handled and unhandled exceptions cannot be distinguished from each other. Uploading a program debug database file separately from Dev Center app submission is uncomfortable. Handled exceptions can be reported as events to differentiate them, but it is not possible to place additional information into event properties (in fact you can, but won’t see them in the portal). All information must be placed into the event name, but there is currently a limit of 300 unique event names per app per week.
Fortunately, there is a brand new Application Insights Diagnostics Preview. You can see event details there, but so far it looks like this service is oriented exclusively to web applications. Meanwhile, Microsoft has released the Windows SDK for Google Analytics. If you use Google Analytics, you have to pay Google to access your own data because it provides you only a sample.
I won’t provide any qualified recommendations here because I don’t know of anything simple, fully functional, and sufficiently established. So far, I’ve been interested in post-mortem debugging for 8 years, and it has always been hard work.