Data latency and PT1M intervals and zero values being returned for no-data

[jdevalk2]

I think I have observed the following behavior and would like to know if this is a bug.

Say I query an azure resource, the number of egress bytes in a Postgres SQL database for instance.
This metric supports PT1M intervals. For the purpose of logging data points I query Azure Monitor every minute with the new value. The default aggregation type is Average.

I give it a range of the past 5 minutes, with data granularity is PT1M. Aggregation type "Average"

Now I get an array (timeseries) with 5 elements
The two elements with the most recent date contain a MetricValue, with Average: 0
Then the third element contains MetricValue with some number: 123
Onwards.

So it looks like Azure Monitor has no values yet for the 2 most recent intervals.
However I would expect intervals to which there is no Average calculated to either not be returned from the query at all.

Or I would expect the Average value of the 2 most recent metrics to be NULL.

Currently they contain 0. Which makes it very hard to distinguish whether this is a real measured data value, or means there is not data.

To make matters worse if I go 2 minutes into the future and query the same time interval again, then the time interval which originally had 0 in it now has a different value.

[hovsepm]

@anirudhcavale could you take a look to this one as well?

[anirudhcavale]

@jdevalk2 so metric data can sometimes see a 2min delay. So, when you query for data you may see 0, or nulls for the most recent 2min if data has not yet landed or been processed. So I recommend setting a 2min offset in your queries. So if it is t10 right now, I recommend querying for metrics from t3-t8.

[jdevalk2]

@anirudhcavale Thanks for the quick answer!
Follow up question:
What are the guarantees regarding that 2 minute delay? I am just wondering if querying after 2 minutes how many of the datapoints would still return 0? And how long should it wait before data is guaranteed to be there?

It would still be nice to have a distinction between a "do not know / not calculated" and a "0"

[jdevalk2]

I think for the purposes I needed this info, the question has been answered so closing this. If there's an addition to the query results whereby one can distinguish not-known aggregate results from known calculated ones I would welcome that as an improvement to the API.