Microsoft声明Application Insights的SLA为：
我们保证Application Insights Service的数据延迟不会超过两个小时的99.9％。
https://azure.microsoft.com/en-us/support/legal/sla/application-insights/v1_0/
在SLA之外的0.1％时间内，在我的代码中执行TelemetryClient.TrackEvent（）时，Microsoft是否保证一定会在某个时间（不在2小时之内）发布该事件？还是在那0.1％的时间内丢失了事件？
答案 0 :(得分：3)
不，由于许多原因，仅调用TrackEvent不能保证发布 ：
在过程的任何级别进行采样。请参见https://docs.microsoft.com/en-us/azure/application-insights/app-insights-sampling?toc=/azure/azure-monitor/toc.json，但通常情况下，如果启用了采样功能，则某些事件可能会合并在一起。找到这些事件的方法多种多样，但通常来说，如果您以相同的内容在紧密循环中调用trackMessage 1000次，则SDK可能会采样并发送一个itemCount设置为1000的事件
事件的内容可能无效（对于有效负载而言，字段大小超过阈值，自定义属性过多，自定义指标过多等）
事件的时间可能无效。事件是过去（> 48h？）还是太远了（不确定确切的时间，但是允许将来的一些时间来考虑时钟偏斜/漂移）
上限-您可能超出每月允许发送的数量-请参见https://docs.microsoft.com/en-us/azure/application-insights/app-insights-pricing，在回答此问题时指出：
除非您为高流量应用程序请求更高的最大值，否则最大上限为1,000 GB /天。
节流-您可能超过每秒允许的事件数/等-参见https://docs.microsoft.com/en-us/azure/application-insights/app-insights-pricing，在回答此问题时，声明为：
节流将数据速率限制为每秒32,000个事件，每个仪表键平均1分钟以上。
网络问题等。各种sdks上的调用跟踪不能保证数据被接受或重试。有些sdk尝试重试，有些则不尝试。
在调用track到创建/完成与应用程序见解的实际连接之间，您的应用程序可能会关闭/崩溃。
其他随机问题，服务问题，其他相关服务的停机时间等，占丢失数据的0.1％。我不确定是否有任何APM /遥测服务可以保证它将接受并处理您发送的100％事件。 （100％-99.9％不是0.01％，而是0.1％。两者之间相差10倍。）
答案 1 :(得分：0)
我已将此问题上报给应用洞察团队。如果有任何反馈，我会及时更新。
据我了解，对于SLA之外的其他0.01％时间，如果有一些停机时间，数据将会丢失。在任何其他情况下，它将在2小时后发布。
希望有帮助。