App Insights TelemetryInitializer 中的异常处理答案

【问题标题】：Exception handling in App Insights TelemetryInitializerApp Insights TelemetryInitializer 中的异常处理
【发布时间】：2017-10-23 16:23:16
【问题描述】：

我正在使用ITelemetryInitializer 的Initialize 方法向我的AppInsights 事件添加几个自定义属性。其中一些是从数据库或其他可能失败的来源中检索的。问题是，对于 try-catch 子句是否应包含在 Initialize 方法中，开发人员是否有任何官方建议？

根据我的观察，在方法中抛出异常并不会阻止遥测的出现，尽管无法看到自定义属性，正如预期的那样。我可以依靠这种行为吗？如果我不手动处理异常并让 AppInsights 的代码处理它们，是否会以某种方式影响性能？

【问题讨论】：

标签： azure azure-application-insights

【解决方案1】：

这取决于，不是吗。如果遥测初始化程序添加了多个自定义属性，并且第一个自定义属性失败并出现异常，您是否要尝试添加其他自定义属性。如果是这样，请在每个自定义属性周围放置一个 try/catch。

如果它只是一个属性，或者一旦第一个属性失败就不应添加所有属性，那么您可以选择不处理异常。然而，在我看来，我希望控制异常传播并选择自己处理它们。（根据情况，可能会用空捕获忽略它们）

如果在遥测初始化程序因未处理的异常而失败时，例如将 SDK 更改为不将遥测数据发送到 App Insights 时，完全忽略它们可能会在未来出现问题。至少如果您决定走这条路，请尝试查看 SDK 的源代码，看看未处理的异常会发生什么。

【讨论】：

我得出了与您相同的结论，我绝对不想依赖这种行为，除非它记录在某处，即“来自 ITelemetryInitializer.Initialize 的任何异常都被 SDK 吞没。如果要执行其他操作，请手动捕获异常。基本上，我正在寻找来自 MS 的官方声明或文档，例如像 Serilog 为丰富者所做的那样，明确说明他们的异常被吞并并通过设计写入自我日志。
对于多个属性，我决定为此目的使用单独的初始化程序，因此选择是在 try-catch 与围绕整个方法主体的空捕获或根本没有 try-catch 之间进行选择。
关于那个官方文档，我不会指望找到它。这些 SKD 是全球记录的，但我从未见过它记录到如此详细的水平。您最好是源代码本身 (github.com/Microsoft/ApplicationInsights-Home) 或在 GitHub 存储库页面之一上要求官方声明。
我刚刚与 Azure 支持人员进行了交谈，他们也无法提供任何明确的指导。所以我想明确的 try-catch 是一种方法。