Azure App见解采样(ItemCount) [英] Azure App Insights Sampling (ItemCount)

问题描述

我对Azure App Insights采样有疑问. 如果一个日志项目的itemCount字段大于1，是否表示确实有一个SAME请求并且已被采样?

I have a question about Azure App Insights Sampling. If itemCount field is greater than 1 for a log item, does it mean that there was an exactly the SAME request and it was sampled?

我的日志有一个请求，该请求以itemCount = 2发送此消息.该请求以OptimisticConcurrencyException结尾，因此我的事务已回滚.在此交易中，我向第三方服务发送了一条消息. 最有趣的是，他们告诉我他们从我的服务中收到2条消息，并且我的数据库已更新(因此事务已提交). 所有内容都变得很清楚，如果有2个请求，其中一个返回200个代码，另一个返回500个.但是，应用程序洞察日志项abot OptimisticConcurrencyException的值itemCount = 2，这意味着两次抛出该异常(对于两个请求) . 此外，除此之外，我看不到其他任何可能更改数据的请求，该请求正在更改.

My logs have one request that sends this message with itemCount = 2. And this request has ended with OptimisticConcurrencyException, so my transaction has been roll-backed. In this transaction I send a message to 3rd party service. The most interesting is that they told me they've got 2 messages from my service and my database has been updated (so transaction has been committed). All of it became clear, if there were 2 requests and one of them returned 200 code, and another returned 500. But app insights log item abot OptimisticConcurrencyException has value itemCount = 2, which means that this exception was thrown twice (for both requests). Furthermore Beside this I don't see any other requests, that could change data, that request was changing.

所以有人可以向我解释应用洞察力如何采样请求和错误吗?

So could anybody explain me how app insights samples requests and errors?

推荐答案

这实际上取决于采样的方式/位置，因为采样可能在3个不同的地方进行，具体取决于您配置应用的方式.

This really depends on how/where your sampling occurred, as sampling could have occurred at 3 different places depending on how you have your app configured.

有一个有关各层的大量文档，但假设是:

采样算法决定要丢弃的遥测项以及要保留的遥测项(无论是在SDK中还是在Application Insights服务中).采样决策基于旨在保持所有相关数据点完整的几条规则，即使在减少数据集的情况下，也可以在Application Insights中保持可行且可靠的诊断经验.例如，如果对于失败的请求，您的应用发送了其他遥测项目(例如，异常和从该请求记录的跟踪)，则采样不会拆分该请求和其他遥测.它可以将它们放在一起或放在一起.因此，当您在Application Insights中查看请求详细信息时，始终可以看到该请求及其关联的遥测项目.

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.

更新: 我从团队中进行采样的人员那里获得了更多详细信息，它的工作方式如下:

Update: I got some more details from people on the team that do the sampling, and it works like this:

1. 采样率取决于应用中每秒发生的事件数
2. 当请求开始时，AI SDK 随机选择要采样的请求(因此，未知失败还是成功)
3. AI SDK分配itemCount=<sampling ratio>

1. Sampling ratio is determined by the number of events per second occurring in the app
2. The AI SDK randomly selects requests to be sampled when the request begins (so, it is not known whether it will fail or succeed)
3. AI SDK assigns itemCount=<sampling ratio>

这将解释您看到的行为，当两个请求(成功+失败)被计为两个失败时:失败的请求被采样为中"，因此在遥测中，您将有2个失败的请求(一个itemCount = 2的请求)，而不是失败和成功的请求，因为成功的请求被采样了.

This would then explain the behavior you are seeing, when two requests (success + failure) were counted as two failures: the failed request was sampled "in", and so in telemetry, you'd have 2 failed requests (one request with itemCount=2) instead of a failed and a successful, because the successful one got sampled away.

这篇关于Azure App见解采样(ItemCount)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！