0
votes

I'm trying to use application insights to keep track of a counter of number of active streams in my application. I have 2 goals to achieve:

  • Show the current (or at least recent) number of active streams in a dashboard
  • Activate a kind of warning if the number exceeds a certain limit.

These streams can be quite long lived, and sometimes brief. So the number can sometimes change say 100 times a second, and sometimes remain unchanged for many hours.

I have been trying to track this active streams count as an application insights metric. I'm incrementing a counter in my application when a new stream opens, and decrementing when one closes. On each change I use the telemetry client something like this

var myMetric = myTelemetryClient.GetMetric("Metricname");
myMetric.TrackValue(myCount);

When I query my metric values with Kusto, I see that because of these clusters of activity within a 10 sec period, my metric values get aggregated. For the purposes of my alarm, I can live with that, as I can look at the max value of the aggregate. But I can't present a dashboard of the number of active streams, as I have no way of knowing the number of active streams between my measurement points. I know the min value, max and average, but I don't know the last value of the aggregate period, and since it can be somewhere between 0 and 1000, its no help.

So the solution I have doesn't serve my needs, I thought of a couple of changes:

  • Adding a scheduled pump to my counter component, which will send the current counter value, once every say 5 minutes. But I don't like that I then have to add a thread for each of these counters.
  • Adding a timer to send the current value once, 5 minutes after the last change. Countdown gets reset each time the counter changes. This has the same problem as above, and does an excessive amount of work to reset the counter when it could be changing thousands of times a second.

In the end, I don't think my needs are all that exotic, so I wonder if I'm using app insights incorrectly.

Is there some way I can change the metric's behavior to suit my purposes? I appreciate that it's pre-aggregating before sending data in order to reduce ingest costs, but it's preventing me from solving a simple problem. Is a metric even the right way to do this? Are there alternative approaches within app insights?

1

1 Answers

0
votes

You can use TrackMetric instead of the GetMetric ceremony to track individual values withouth aggregation. From the docs:

Microsoft.ApplicationInsights.TelemetryClient.TrackMetric is not the preferred method for sending metrics. Metrics should always be pre-aggregated across a time period before being sent. Use one of the GetMetric(..) overloads to get a metric object for accessing SDK pre-aggregation capabilities. If you are implementing your own pre-aggregation logic, you can use the TrackMetric() method to send the resulting aggregates.

But you can also use events as described next:

If your application requires sending a separate telemetry item at every occasion without aggregation across time, you likely have a use case for event telemetry; see TelemetryClient.TrackEvent (Microsoft.ApplicationInsights.DataContracts.EventTelemetry).