TelemetryClient produces inconsistent results in Application Insights

Question

I tried tracking custom metrics with and without flushing it. However, the metrics only intermittently shows up in Application Insights under the "Custom" section. First question: Is it required to run "flush()" after every single "TrackMetric(metric)" call in order for the telemetry to be sent to Application Insights? Second: Why is there this intermittent behavior? I'm only writing one metric at a time, so it's not as if I'm overloading Application Insights with thousands of separate calls. Here is my code (This is from a simple Console App):

    public class Program
{
    public static void Main(string[] args)
    {
        var telemetryClient = new TelemetryClient()
        {
            Context = { InstrumentationKey = "{{hidden instrumentation key}}" }
        };
        var metric = new MetricTelemetry
        {
            Name = "ImsWithContextMetric2",
            Sum = 42.0
        };
        telemetryClient.TrackMetric(metric);
        telemetryClient.Flush();
    }
}

I'm also getting this strange behavior in Application Insights in which the custom metric I add shows up under a "Unavailable/deprecated Metrics" section. And a metric that I didn't even add called "Process CPU (all cores)" pops up under the "Custom" section. Any ideas why this strange behavior would occur?:

degant degant · Accepted Answer · 2017-05-04T21:23:24

Is it required to run "flush()" after every single "TrackMetric(metric)" call in order for the telemetry to be sent to Application Insights?

Since you are using a Console Application to send events to Application Insights, which might be short-lived, it is definitely a good practice to call .Flush() every once in a while. The SDK uses the InMemoryChannel to send telemetry and sends it in batches using from an in-memory queue. So it is very important to call the .Flush() so that the data is forcefully pushed. A good practice might be to add a bit of wait after the event:

telemetryClient.Flush();
Thread.Sleep(1000);

More reading: Flushing data, Ensure you don't lose telemetry

However, the metrics only intermittently shows up in Application Insights under the "Custom" section. Why is there this intermittent behavior? I'm only writing one metric at a time, so it's not as if I'm overloading Application Insights with thousands of separate calls.

Sometimes there is a delay in metrics showing up in the Azure Portal. It can be up to a few minutes too. But if you have set it up correctly, you aren't exceeding the throttling limit, and adaptive sampling is disabled, then there is no reason for which telemetry should be intermittent. However if you still feel something is wrong, start a fiddler trace (make sure you are capturing from non-browser sessions) and check if a call is going out to dc.services.visualstudio.com. Make sure the response is 200 OK and if the items were accepted by the server.

I'm also getting this strange behavior in Application Insights in which the custom metric I add shows up under a "Unavailable/deprecated Metrics" section.

What version of the SDK are you using? I just tried out the same scenario and the custom metrics are showing up correctly.

And a metric that I didn't even add called "Process CPU (all cores)" pops up under the "Custom" section.

"Process CPU" is a performance counter which is used to track CPU utilization. I believe the SDK will only be able to track these counters if the app is running under IIS or on Azure. It probably got added internally when you created your Application Insights resource. You can ignore it since it won't have data to chart.

Hope this helps!

TelemetryClient produces inconsistent results in Application Insights

1 Answers