我对 Azure App Insights 采样有疑问。 如果日志项的 itemCount 字段大于 1，是否意味着存在完全相同的请求并且已对其进行采样？
我的日志有一个请求发送此消息，其中 itemCount = 2。此请求已以 OptimisticConcurrencyException 结束，因此我的事务已回滚。在此交易中，我向第三方服务发送一条消息。 最有趣的是，他们告诉我他们从我的服务收到了 2 条消息，并且我的数据库已更新(因此事务已提交)。 所有这些都变得很清楚，如果有 2 个请求，其中一个返回 200 代码，另一个返回 500。但是应用程序洞察日志 item abot OptimisticConcurrencyException 的值 itemCount = 2，这意味着该异常被抛出两次(对于两个请求) 。 此外，除此之外，我没有看到任何其他可能更改数据的请求，该请求正在更改。
那么有人可以向我解释一下应用洞察如何对请求和错误进行采样吗？
最佳答案
这实际上取决于采样发生的方式/位置，因为采样可能发生在 3 个不同的位置，具体取决于您的应用配置方式。
有一个fair amount of documentation about the various layers of sampling ，但假设:
The sampling algorithm decides which telemetry items to drop, and which ones to keep (whether it's in the SDK or in the Application Insights service). The sampling decision is based on several rules that aim to preserve all interrelated data points intact, maintaining a diagnostic experience in Application Insights that is actionable and reliable even with a reduced data set. For example, if for a failed request your app sends additional telemetry items (such as exception and traces logged from this request), sampling will not split this request and other telemetry. It either keeps or drops them all together. As a result, when you look at the request details in Application Insights, you can always see the request along with its associated telemetry items.
更新: 我从进行采样的团队人员那里获得了更多详细信息，其工作原理如下:
- 采样率由应用中每秒发生的事件数决定
- AI SDK 在请求开始时随机选择要采样的请求(因此，不知道是否会失败或成功)
- AI SDK 分配
itemCount=<sampling ratio>
这将解释您所看到的行为，当两个请求(成功 + 失败)被计为两个失败时:失败的请求被“in”采样，因此在遥测中，您将有 2 个失败的请求(一个itemCount=2 的请求)而不是失败和成功，因为成功的请求被采样掉了。
关于Azure 应用程序见解采样 (ItemCount)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43262046/