我正在尝试使用应用程序洞察力来跟踪我的应用程序中活动流数量的计数器。我有两个目标要实现：
- 在仪表板中显示当前（或至少最近）的活动流数量
- 如果数量超过某个限制，则激活一种警告。
这些流可以很长，有时很短暂。所以这个数字有时会改变，比如每秒 100 次，有时会保持数小时不变。
我一直在尝试将此活动流计数作为应用程序洞察指标进行跟踪。当一个新流打开时，我在我的应用程序中增加一个计数器，并在一个关闭时减少。在每次更改时，我都会使用类似这样的遥测客户端
var myMetric = myTelemetryClient.GetMetric("Metricname");
myMetric.TrackValue(myCount);
当我使用 Kusto 查询我的指标值时，我发现由于 10 秒内的这些活动集群，我的指标值被聚合。出于警报的目的，我可以忍受这一点，因为我可以查看聚合的最大值。但是我无法提供活动流数量的仪表板，因为我无法知道我的测量点之间的活动流数量。我知道最小值、最大值和平均值，但我不知道聚合周期的最后一个值，因为它可能在 0 到 1000 之间，所以没有帮助。
所以我的解决方案不能满足我的需求，我想到了一些改变：
- 向我的计数器组件添加一个预定的泵，它将发送当前的计数器值，每 5 分钟一次。但我不喜欢这样，我必须为每个计数器添加一个线程。
- 添加一个计时器以在最后一次更改后 5 分钟发送一次当前值。每次计数器更改时都会重置倒计时。这与上面有相同的问题，并且当计数器可能每秒更改数千次时，它会做大量的工作来重置计数器。
最后，我认为我的需求并不那么奇特，所以我想知道我是否错误地使用了应用程序洞察力。
有什么方法可以改变指标的行为以满足我的目的吗？我很欣赏它在发送数据之前进行预聚合以降低摄取成本，但这使我无法解决一个简单的问题。度量甚至是正确的方法吗？应用洞察中是否有替代方法？