That was my initial idea too but I was trying to find a better one 😕   Since I already have an nginx that is acting as cache in between my exporter and the Meraki Cloud I will also check if I can intercept the 429 reply and remove the Retry-After header on the nginx, I don't like this idea but it may work.   Thanks 🙂 ... View more

Hi PhilipDAth and thanks for the reply,   Yes I have looked into those endpoints and I believe we are currently using the first one you mentioned to monitor the general status of the devices (I'm not 100% sure as it's a different script doing that and I have not worked on it for a couple of years now).   The one I'm currently using are more device focused as we need some metrics that are not available from an organization wide API like: https://developer.cisco.com/meraki/api-v1/get-network-wireless-client-count-history/ https://developer.cisco.com/meraki/api-v1/get-organization-wireless-devices-channel-utilization-by-device/ https://developer.cisco.com/meraki/api-v1/get-organization-appliance-vpn-statuses/ And many other like these   We currently have 35 organizations of various sizes, most of them have a few hundred devices, some even less than 100 and a couple goes as high as 1500-2000 devices. As the rate limit is as per organization, I do not have any issue with small organizations but I am testing the worst case scenario with the bigger organization. I have already reduced the frequency of Prometheus scraping and added a nginx proxy to cache results for a few minutes to reduce the number of calls actually going trough to Meraki Cloud.   The nginx proxy also caches 429 replies so that a specific request that got rate limited will not get to the Cloud again for a few minutes, the issue is that the script waits on rate limit even if it's trying it only one time and thus it could directly give up and raise the APIError, thus Prometheus is going into timeout and discarding all data anyway.   Regarding the asyncio or standard blocking io, that is a bit over my understanding to be honest so I could be wrong but I'm using uvicorn to expose the http port on which the exporter is served to Prometheus and it can manage multiple request for multiple devices at the same time; the execution of API calls for a given device instead are blocking as I only do one at a time and in order. I hope this gives some more details.   Thanks, Gianluca ... View more

Hi sungod and thanks for the reply,   I have tried that but I will always get a None response. Running some debugging I saw that the maximum_retries is not used for actual retry but for all tries, even the first one so setting is to 0 will actually skip everything and do nothing: Class RestSession, def request (rest_session.py)   I have tried setting it to 1 to just try one time and it works but still wait the Retry-After between the first (and only) try and the APIError exception that I'm waiting for. I do believe that the wait_on_rate_limit variable was added to the code and the DashboardAPI class but not properly implemented and used. ... View more

Hi Belensays and thanks for the reply. It would normally make sense to respect the header but in this specific case it would make more sense to respect the API client configuration and do not wait on rate limit, especially if there will not be a second try after that.   I still do not see the variable wait_on_rate_limit actually used anywhere in the library code, maybe it was never properly implemented? Do you have any idea on how I could check that? ... View more