snmp.meraki.com best practices and constraints?

[Prodrick]

What best practices might exist for software developers who want to use snmp.meraki.com for Meraki MS interface monitoring, rather than the Dashboard API, to mitigate risk of hitting rate limits?

For example, what is the most practical polling frequency, i.e. 1 minute, 5 minutes, 10 minutes?

When should one use snmp.meraki.com rather than the Meraki MS local SNMP?  For example, might there be a delay in the Cloud Controller-reported SNMP data as compared to what one can fetch from the local device?  If so, how much lag is typical?

What scaling constraints might be known to limit the effectiveness of snmp.meraki.com in environments with hundreds or thousands of sites and devices?

Does snmp.meraki.com support interface monitoring in switch stacks?

Basically, I'm looking for clear guidance on when it's appropriate/supported to use snmp.meraki.com vs the Dashboard API vs local SNMP (specific to network interface statistics monitoring).

Thanks.

[PhilipDAth]

The best practice would be not to use the SNMP API - it is only there for integration with SNMP only monitoring systems.

New systems should be using the native API.

[Prodrick]

Thanks. We make extensive use of the Dashboard API, however monitoring Meraki MS interface statistics is related to hitting API rate limits in larger environments. To mitigate this we use local SNMP for MS interface statistics, but I have my team evaluating if snmp.meraki.con is a performant, scalable, and reliable alternative.

I am looking for Cisco Meraki documented constraints or best practices related to use of the Cloud Controller’s snmp.