Delay in Perfscore value from "Get Device Appliance Performance"

[Frank-NL]

Hi,

Does anyone know if there is any documentation on the calculation and timepan/resolution of the Perf Score "Appliance Performance"?

https://developer.cisco.com/meraki/api-v1/#!get-device-appliance-performance

With "getDeviceAppliancePerformance" there is no option to specify the timespan like with the usage history.

I'm seeing what seems to be a delay of 1h+ on the returned "perfScore" value.

Below a good example when comparing usage history (graph lines with y axis left side) with the perfScore (yellow and y axis right side). The usage history I confirmed with the graphs in the Dashboard itself:

Cheers

[rhbirkelund]

The MX Performance Score, is an expression of Device load, ranging from 1 to 100. It's an average calculated every 60s.

https://documentation.meraki.com/MX/Monitoring_and_Reporting/Device_Utilization#Reading_Device_Utili...

[Frank-NL]

Thanks for the information. Unfortunately no documentation on the timepan/resolution (t0-t1).

Any idea why we are seeing delays?

[rhbirkelund]

Could the Usage History be off due to difference in timezone?

[Frank-NL]

Thanks, that's a good point and I'll look into that 🙂

[Frank-NL]

The Usage History is shown correctly, I confirmed this on multiple MX with live traffic.

The PerfScore seems to be the device load average of approximately 90 minutes before the query.

[sungod · Accepted solution]

IMHO this metric should have a timestamp in the response to make it more useful, especially to correlate with other info.

Maybe we should try asking for this to be added as an enhancement, it could be a non-breaking change done like this...

{
"perfScore": 10,
"ts": "2018-02-11T00:00:00.090210Z"
}

Or have a new API call to give performance history as an array of 60s samples between t0-t1.

[Frank-NL]

Thanks, I'll set up a request in the API early access group. And I'll create a support case to ask about the delay I'm seeing

[JGill]

I'd agree,  following a standard for time for all the API's when looking at performance data would be a grate feature.   The t0, t1, timespan and ts timestamp like used on client bandwidth would be a good format to follow.  

Having a performance number that shows an average of the previous hour, while interesting, is not handy if you are troubleshooting events, or tying other events to system spikes.   As in this example, your looking in the wrong area, as the system issue was from a previous hour, and if your looking real time, the event / load could already be gone.  

This is really important on HUB devices as you do not see the actual client data flows like you do for a spoke.  Very easy to pick out an issue on a spoke MX.  Hub's on the other hand not so easy.  That could be another request, to make the HUB traffic analysis on par with spoke client views.