Risks, Limitations and Assumptions
- The integration can manage critical/recovery failure alerts for the following two scenarios when the user activates App Failure Notifications in the settings:Connectivity Exception.
- Authentication Exception
- Cisco Meraki will not send any duplicate/repeat failure alert notification until the already existing critical alert is recovered.
- Use metrics for monitoring the resources and generating alerts when the threshold values are breached.
- Administrative endpoint paths and accessibility can vary based on broker and web-console configuration.
- Supported target versions are not explicitly declared in the scanned SDK app artifacts.
Cisco Meraki API rate limits
Every limitation in this section originates in the Cisco Meraki Dashboard API itself, not in the OpsRamp application. Meraki enforces two independent limits:
| Limit | Scope | What it means |
|---|---|---|
| 10 requests per second | Per organization | Applies to the organization as a whole, regardless of how many applications interact with it. The budget is shared by every API client authenticating against that organization — OpsRamp, customer scripts, and any third-party tool draw from the same 10 requests/second. |
| 100 requests per second | Per source IP address | Applies to the originating IP, regardless of how many API clients use that address. All organizations polled from a single egress IP share this budget. |
For more details, refer to API Call Budgets.
There are two separate limits: 10 requests per second per organization and 100 requests per second per IP address. An organization can be throttled if it exceeds its own 10 requests/second limit, or if the shared IP address reaches the 100 requests/second limit. In the latter case, all organizations using that IP may be throttled, even if they stay within their own limit.
Resulting limitations of the SDK application
- Metric collection may be delayed on large organizations.Organizations with more than 1,000 resources can experience delayed metric collection, but only when per-resource metrics are enabled. Most metrics are collected through organization-wide or network-wide sweeps — one API call serves every resource, so their cost does not grow with the size of the estate. A small number of metrics have no bulk equivalent in the Meraki API and require one API call per resource; on a large estate these are issued sequentially within the organization’s 10 requests/second budget, so the collection cycle lengthens in proportion to the resource count. They are isolated onto dedicated monitors, so a default installation does not incur this cost:
| Monitor | Metrics | API cost per polling cycle |
|---|---|---|
| Cisco Meraki Uplink Jitter Monitor | cisco_meraki_uplink_Jitter | One call per uplink |
| Cisco Meraki Firewall Performance Monitor | cisco_meraki_firewall_PerformanceScore | One call per firewall |
| Cisco Meraki Switch Usage Monitor | cisco_meraki_switch_TotalTrafficKbps, cisco_meraki_switch_PoePowerUsage | One call per switch |
| Cisco Meraki Switch Port Usage Monitor | Switch port usage and traffic metrics (6) | One call per switch |
Most metrics, such as device availability, device counts, VPN quality, wireless statistics, switch port status, uplink health (loss, latency, status, and bandwidth), memory, and CPU usage, are collected using shared bulk API calls.If Single Resource API metric collection is enabled, it can affect overall metric collection performance in large organizations.
Use a dedicated API key, and avoid other API consumers on the same organization.Create a separate Meraki API key for the OpsRamp application rather than reusing one shared with other tools. Note that because the 10 requests/second limit is enforced per organization rather than per key or per application, a dedicated key does not grant additional budget: any other integration, script or automation polling the same organization consumes the same allowance and can cause the application’s calls to be rejected. Where possible, avoid running other API-based tooling against a monitored organization, and coordinate polling schedules where it cannot be avoided.
Keep per-resource monitors at 15 minutes or longer.Monitors that make one API call per resource must be left at the 15-minute default frequency, and 30 minutes is recommended on organizations with very large resource counts. Shortening the frequency on these monitors multiplies the per-cycle call volume by the number of resources and will produce significantly delayed metric collection, and eventually rate-limit rejections, across the whole integration — including metrics that are otherwise inexpensive. Bulk-collected monitors are not affected by this constraint and can remain at the default.
Gateway Public IP must be unique within a tenant. Shared public IPs (though uncommon) will cause aggregated traffic to exceed the 100 req/sec rate limit, resulting in throttled monitoring data.
Migration from the Meraki SaaS (Cloud) Application
There is no migration path from the Meraki cloud application to the SDK application. The two must be treated as separate, independent integrations:
They use different native types and different OpsRamp resource types, so resources discovered by one are not recognised by the other.
Existing resources, templates, thresholds and alert definitions do not carry over and must be recreated against the SDK application’s resource model.
Metric names differ (
meraki_*in the cloud application,cisco_meraki_*in the SDK application), so dashboards and alert definitions require a one-time update.Metric coverage is not a concern: the SDK application supports every metric provided by the SaaS-based Meraki application, and adds a substantial number beyond it.
Recommended approach: install and validate the SDK application alongside the existing integration, migrate dashboards and alert definitions, then decommission the cloud application. Avoid running both against the same organization for an extended period, since the two integrations share the organization’s 10 requests/second budget.
Installation requirement
When installing the SDK application, select the Bypass resource reconciliation option. Without it, resources discovered by the SDK application may be reconciled against those created by the cloud application, which uses a different resource model.