Cisco Meraki

Plugin: go.d.plugin Module: meraki

Overview

Monitor device availability, switch port traffic and uplink traffic in a Cisco Meraki organization, with each device shown as its own Netdata node.

• Device availability: the status Meraki Dashboard reports for each device: online, alerting, offline or dormant.
• Inventory: how many devices are assigned to the organization's networks, and which ones.
• Switch ports (two opt-in options): sent and received kilobits/s, and packets/s, of every switch port, on the switch's node.
• Uplink traffic (opt-in): sent and received kilobits/s of each WAN and cellular uplink of every MX security appliance and Z teleworker gateway network.
• Fleet filtering: device nodes and charts carry organization, network, model and product type labels, so a large fleet can be grouped and filtered.

Every device type Meraki reports availability for is covered, including security appliances (MX), switches (MS), wireless access points (MR), cameras (MV), sensors (MT) and cellular gateways (MG).

The collector sends read-only HTTPS requests to the Meraki Dashboard API in the cloud, authenticated with an API key. It never connects to the devices: the Agent needs outbound HTTPS (port 443) to the regional API host and to the Meraki shard hosts the API redirects to, such as n123.meraki.com.

Every collection (every 5 minutes by default) reads these API operations completely, page by page:

Operation	Used for	Read
getOrganizations	The name of the configured organization	Always
getOrganizationNetworks	Network names for the labels	Always
getOrganizationDevices	The devices assigned to networks, one node each	Always
getOrganizationDevicesAvailabilities	The status of each device	Always
getOrganizationSwitchPortsUsageHistoryByDeviceByInterval	Switch port traffic	With collect_switch_port_traffic
getDeviceSwitchPortsStatusesPackets	Switch port packet rates, one request per switch	With collect_switch_port_packets
getOrganizationApplianceUplinksUsageByNetwork	Uplink traffic	With collect_appliance_uplink_traffic

Whatever update_every is, switch port traffic is looked up in the last 15 minutes, uplink traffic is read for the 5 minutes that ended 5 minutes ago, and packet rates for the last 5 minutes.

When a job starts, one small getOrganizationDevices request checks that the API key can reach the organization.

This collector is supported on all platforms.

This collector supports collecting metrics from multiple instances of this integration.

The collector needs an API key whose owner has at least read-only access to the organization. A Meraki API key acts with the permissions of the Dashboard administrator who created it; the collector only reads.

Default Behavior

Auto-Detection

Nothing is detected automatically: each job monitors the one organization set in organization_id, with the API key you configure. Within that organization, every collection finds all assigned devices and adds a node for each new one.

Limits

• Five-minute data. Meraki refreshes device availability every 5 minutes without a sample time, and traffic values are averages over at least 5 minutes, so an update_every below 300 seconds adds requests, not detail. Above 300 seconds, each traffic value still covers only one Meraki window, usually 5 minutes, not the whole collection interval.
• Traffic lags behind. Meraki publishes traffic some minutes after it happens. Switch port traffic is the latest interval Meraki has reported within the last 15 minutes, so it can be up to 15 minutes old; the interval age chart shows how old it is, and the chart has a gap when Meraki has reported no usable interval in that time. Uplink traffic covers the 5 minutes that ended 5 minutes earlier, to give Meraki time to count the bytes. Packet rates cover the last 5 minutes, which Meraki may not have finished reporting. Missed collections are not backfilled.
• Uplinks belong to the network. When more than one appliance of a network was active, such as a warm spare pair, Meraki adds up their bytes per interface. Uplink charts are therefore per network and interface, on the job's node or its virtual node, not on an appliance's node.
• Shared API budget. Meraki allows 10 requests per second per organization and 100 per source IP address, shared with every other application using them. The collector sends at most 10 requests per second per job, and after a 429 Too Many Requests answer it sends nothing until the Retry-After wait Meraki requested has passed. See Meraki API rate limits.

Performance Impact

Collecting costs the Agent little CPU; the nodes and charts it creates, counted below, use Agent memory and disk like any others. On the Meraki side, each operation costs one request per page, plus one for each redirect Meraki answers with:

Operation	Page size
getOrganizations	9,000 organizations visible to the API key
getOrganizationNetworks	1,000 networks
getOrganizationDevices	1,000 assigned devices
getOrganizationDevicesAvailabilities	1,000 devices

An organization with 2,500 devices in 40 networks takes 1 + 1 + 3 + 3 = 8 requests per collection. Increase update_every to make fewer requests; increase timeout if a very large organization cannot finish within it.

Each traffic option adds requests to every collection:

Option	Requests	Charts
collect_switch_port_traffic	1 per 50 switches Meraki lists for the organization	2 per switch port
collect_switch_port_packets	1 per assigned switch	1 per switch port
collect_appliance_uplink_traffic	1	1 per uplink

Requests are paced at 10 per second, so packet rates for 1,000 switches add about 100 seconds to every collection, more than the default timeout of 60 seconds. A collection that runs past timeout updates no chart, availability included. For a large fleet, raise timeout with collect_switch_port_packets, or leave it off.

Every assigned device becomes a Netdata node: an organization with 2,000 devices adds 2,000 nodes.

Setup

You can configure the meraki collector in two ways:

Method	Best for	How to
UI	Fast setup without editing files	Go to Nodes → Configure this node → Collectors → Jobs, search for meraki, then click + to add a job.
File	If you prefer configuring via file, or need to automate deployments (e.g., with Ansible)	Edit go.d/meraki.conf and add a job.

important

UI configuration requires paid Netdata Cloud plan.

Prerequisites

Enable Dashboard API access for the organization

API requests are rejected until the organization allows them. In Meraki Dashboard, open Organization > Settings and enable Dashboard API access. See How to use the Meraki Dashboard API.

Create an API key for a read-only administrator

A Meraki API key has the permissions of the administrator who creates it. Use a Dashboard administrator account with read-only access to the organization, and generate an API key from that account's My profile page. Keep the key out of the configuration file: put it in an environment variable of the Netdata service or in a file readable by the netdata user.

To verify the key, list the organizations it can see with the command shown for the organization_id option.

Allow the Agent's address if the organization restricts API access by IP

This applies only when the organization limits Dashboard API access to specific source addresses. Add the public IP address the Agent's requests leave from; otherwise organization requests fail with HTTP 403.

Configuration

Options

Configure one organization per job. The following options can be defined globally: update_every, autodetection_retry.

Config options

Group	Option	Description	Default	Required
Target	url	URL of the Meraki Dashboard API endpoint.	https://api.meraki.com/api/v1	no
	organization_id	Meraki organization ID to monitor.		yes
Authentication	api_key	Meraki API key. Set either this or bearer_token_file.		no
	bearer_token_file	Path to a file containing the Meraki API key, reread for every request. Set either this or api_key.		no
Traffic	collect_switch_port_traffic	Collect the average traffic of every switch port, shown on its switch's node.	no	no
	collect_switch_port_packets	Collect the packet rates of every switch port, at one API request per switch per collection.	no	no
	collect_appliance_uplink_traffic	Collect the average traffic of each uplink of every MX and Z network, shown on the job's node or its virtual node.	no	no
Collection	update_every	Data collection interval, in seconds.	300	no
	autodetection_retry	How often to retry the initial connection when the job fails to start, in seconds. Zero disables retries.	0	no
	timeout	Complete collection or connection-check timeout, in seconds, including all pages and request pacing.	60	no
	vnode	Associates the organization and appliance uplink charts with a Virtual Node. Device nodes are created separately.		no
Transport	proxy_url	HTTP proxy URL. Empty value uses environment proxy variables.		no
	tls_ca	Path to a CA certificate file used to verify the server certificate.		no
	tls_cert	Path to a client certificate file. Requires tls_key.		no
	tls_key	Path to the client certificate key file. Requires tls_cert.		no
	tls_skip_verify	Skip verification of the server certificate and hostname.	no	no

url

Use the API endpoint of the region that hosts the organization:

Region	URL
Global (default)	https://api.meraki.com/api/v1
Canada	https://api.meraki.ca/api/v1
China	https://api.meraki.cn/api/v1
India	https://api.meraki.in/api/v1
United States FedRAMP	https://api.gov-meraki.com/api/v1

The URL must use HTTPS with the path exactly /api/v1 (a prefix such as /meraki/api/v1 is not accepted), without credentials, query or fragment.

A private endpoint or reverse proxy in front of the API also works, with one condition. Meraki's redirects and next-page links point at Meraki hosts, and with a custom endpoint the collector follows them only within that endpoint. The proxy must therefore rewrite the Location and Link headers to its own address; otherwise every list longer than one page fails with invalid pagination target.

organization_id

The ID of the organization, not its name. The organizations an API key can see, with their IDs, are listed by the command below; for an organization in another region, replace the host with the one in url.

curl -s -H "Authorization: Bearer $MERAKI_API_KEY" https://api.meraki.com/api/v1/organizations

bearer_token_file

Use this when a secret manager rotates the key in place: the next request uses the new key without a restart. The file must be readable by the netdata user.

collect_switch_port_traffic

Adds two charts per port to each switch's node: sent and received kilobits/s from the latest interval Meraki has reported within the last 15 minutes, usually 5 minutes long, or a gap when it has reported none, and how old that interval is.

collect_switch_port_packets

Adds a chart of the sent and received packets/s of each port, counting every packet type, to each switch's node. Because it costs a request per switch, it is the option that decides timeout on large fleets; see Performance Impact.

collect_appliance_uplink_traffic

Adds a chart per network and uplink interface (for example wan1, wan2 or cellular) with the sent and received kilobits/s of the 5 minutes that ended 5 minutes earlier, on the job's node or vnode.

proxy_url

If the proxy URL contains credentials, use a secret reference such as ${env:MERAKI_PROXY_URL} instead of entering the authenticated URL directly into the form.

via UI

Configure the meraki collector from the Netdata web interface:

1. Go to Nodes.
2. Select the node where you want the meraki data-collection job to run and click the ⚙ (Configure this node). That node will run the data collection.
3. The Collectors → Jobs view opens by default.
4. In the Search box, type meraki (or scroll the list) to locate the meraki collector.
5. Click the + next to the meraki collector to add a new job.
6. Fill in the job fields, then click Test to verify the configuration and Submit to save.
   • Test validates the provided settings and checks the collector's startup prerequisites. Successful validation does not guarantee that every metric will be available during collection.
   • If it fails, an error message appears with details (for example, connection refused, timeout, or command execution errors), so you can adjust and retest.

via File

The configuration file name for this integration is go.d/meraki.conf.

The file format is YAML. Generally, the structure is:

update_every: 1
autodetection_retry: 0
jobs:
  - name: some_name1
  - name: some_name2

You can edit the configuration file using the edit-config script from the Netdata config directory.

cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata
sudo ./edit-config go.d/meraki.conf

Examples

Basic

Monitor one organization, with the API key read from an environment variable.

Config

jobs:
  - name: meraki
    organization_id: "123456"
    api_key: ${env:MERAKI_API_KEY}

Switch port and uplink traffic

Also collect the traffic of every switch port and MX or Z uplink.

Config

jobs:
  - name: meraki
    organization_id: "123456"
    api_key: ${env:MERAKI_API_KEY}
    collect_switch_port_traffic: yes
    collect_appliance_uplink_traffic: yes

Switch port packets on a large fleet

Also collect packet rates, which cost one request per switch. The longer timeout leaves room for about 1,500 switches.

Config

jobs:
  - name: meraki
    organization_id: "123456"
    api_key: ${env:MERAKI_API_KEY}
    collect_switch_port_packets: yes
    timeout: 180

API key in a rotated file

Read the key from a file that a secret manager rotates. The file is read again for every request.

Config

jobs:
  - name: meraki
    organization_id: "123456"
    bearer_token_file: /run/secrets/meraki_api_key

Regional API endpoint

Monitor an organization hosted outside the global region, here Canada.

Config

jobs:
  - name: meraki-canada
    url: https://api.meraki.ca/api/v1
    organization_id: "123456"
    api_key: ${env:MERAKI_API_KEY}

Through an HTTP proxy

Reach the API through an outbound proxy.

Config

jobs:
  - name: meraki
    organization_id: "123456"
    api_key: ${env:MERAKI_API_KEY}
    proxy_url: http://proxy.example.com:3128

Several organizations

One job per organization. Each organization has its own API budget; the jobs share the per-IP budget.

Config

jobs:
  - name: meraki-hq
    organization_id: "123456"
    api_key: ${env:MERAKI_API_KEY}

  - name: meraki-retail
    organization_id: "654321"
    api_key: ${env:MERAKI_API_KEY}

Alerts

There are no alerts configured by default for this integration.

Metrics

Metrics grouped by scope.

The scope defines the instance that the metric belongs to. An instance is uniquely identified by a set of labels.

• Where charts appear. The organization and uplink charts are on the node that runs the job, or on its virtual node when vnode is set. Device charts, switch port charts included, are on each device's own node, named after the device; meraki- followed by the serial when the device has no name; or meraki- followed by a generated ID when the name contains an apostrophe, backslash or line break.
• Gaps, not offline or zero. A device whose status is missing, unknown or reported for another network has no availability value for that collection; it is never reported offline because of missing data. Its inventory chart stays at 1 while the device is assigned. Likewise, a traffic value Meraki leaves out, or reports twice with different values, is a gap, not a zero.
• Failed collections. A failed inventory request, a timeout or a cancellation updates no chart. A failed traffic request leaves gaps only in its own charts, except an HTTP 429, after which no more traffic is requested in that collection.
• Removed devices. When a device leaves the inventory, its charts stop updating and become obsolete. Netdata keeps the node and its history.

Per organization

The configured Meraki organization.

Labels:

Label	Description
organization_id	Meraki organization ID, for example 123456.
organization_name	Meraki organization name.

Metrics:

Metric	Description	Dimensions	Unit
meraki.organization_assigned_devices	Meraki Assigned Devices	assigned	devices

Per device

One device assigned to a network of the organization, shown as its own node.

Labels:

Label	Description
organization_id	Meraki organization ID.
organization_name	Meraki organization name.
serial	Device serial number, for example Q2XX-XXXX-XXXX.
device_name	Device name in Dashboard; empty when unnamed.
model	Device model, for example MS120-8.
product_type	Meraki product type, for example appliance, switch, wireless, camera, sensor or cellularGateway.
network_id	ID of the network the device is assigned to.
network_name	Name of the network the device is assigned to.

Metrics:

Metric	Description	Dimensions	Unit
meraki.device_assigned	Meraki Device Inventory Membership	assigned	devices
meraki.device_availability	Meraki Device Availability	alerting, dormant, offline, online	status

Per switch port

One port of an assigned switch, on the switch's node, when collect_switch_port_traffic or collect_switch_port_packets is enabled.

Labels:

Label	Description
organization_id	Meraki organization ID.
organization_name	Meraki organization name.
serial	Device serial number, for example Q2XX-XXXX-XXXX.
device_name	Device name in Dashboard; empty when unnamed.
model	Device model, for example MS120-8.
product_type	Meraki product type, for example appliance, switch, wireless, camera, sensor or cellularGateway.
network_id	ID of the network the device is assigned to.
network_name	Name of the network the device is assigned to.
port_id	Port ID as Meraki reports it, usually the port number such as 1; ports on a module also carry the slot and module type.

Metrics:

Metric	Description	Dimensions	Unit
meraki.switch_port_traffic	Meraki Switch Port Traffic	received, sent	kilobits/s
meraki.switch_port_traffic_interval_age	Meraki Switch Port Traffic Interval Age	age	seconds
meraki.switch_port_packets	Meraki Switch Port Packets	received, sent	packets/s

Per appliance uplink

One uplink interface of an MX or Z network, on the job's node or its virtual node, when collect_appliance_uplink_traffic is enabled.

Labels:

Label	Description
organization_id	Meraki organization ID.
organization_name	Meraki organization name.
network_id	ID of the MX or Z network.
network_name	Name of the MX or Z network.
interface	Uplink interface, for example wan1, wan2 or cellular.

Metrics:

Metric	Description	Dimensions	Unit
meraki.appliance_uplink_traffic	Meraki Appliance Uplink Traffic	received, sent	kilobits/s

Troubleshooting

Diagnostics

Debug Mode

Important: Debug mode is not supported for data collection jobs created via the UI using the Dyncfg feature.

To troubleshoot issues with the meraki collector, run the go.d.plugin with the debug option enabled. The output should give you clues as to why the collector isn't working.

• Navigate to the plugins.d directory, usually at /usr/libexec/netdata/plugins.d/. If that's not the case on your system, open netdata.conf and look for the plugins setting under [directories].

  cd /usr/libexec/netdata/plugins.d/

• Switch to the netdata user.

  sudo -u netdata -s

• Run the go.d.plugin to debug the collector:

  ./go.d.plugin -d -m meraki

  To debug a specific job:

  ./go.d.plugin -d -m meraki -j jobName

Getting Logs

If you're encountering problems with the meraki collector, follow these steps to retrieve logs and identify potential issues:

• Run the command specific to your system (systemd, non-systemd, or Docker container).
• Examine the output for any warnings or error messages that might indicate issues. These messages should provide clues about the root cause of the problem.

System with systemd

Use the following command to view logs generated since the last Netdata service restart:

journalctl _SYSTEMD_INVOCATION_ID="$(systemctl show --value --property=InvocationID netdata)" --namespace=netdata --grep meraki

System without systemd

Locate the collector log file, typically at /var/log/netdata/collector.log, and use grep to filter for collector's name:

grep meraki /var/log/netdata/collector.log

Note: This method shows logs from all restarts. Focus on the latest entries for troubleshooting current issues.

Docker Container

If your Netdata runs in a Docker container named "netdata" (replace if different), use this command:

docker logs netdata 2>&1 | grep meraki

Known Errors

operation: HTTP status 401

Cause

Meraki rejected the API key. It is mistyped, revoked, or belongs to a deleted administrator account.

Fix

Generate a new API key and update api_key and restart the job, or replace the contents of the file named by bearer_token_file, which is read again on the next request.

operation: HTTP status 403

Cause

The API key's owner lacks permission for the request, or the organization restricts API access by source IP and the Agent's address is not allowed.

Fix

Grant the key's owner read-only access to the organization and, if it restricts API access by IP, allow the Agent's public address. See the prerequisites.

operation: HTTP status 404

Cause

Meraki answers 404 when the API key cannot reach the organization at all. The organization ID is wrong, the key's owner has no access to it, or Dashboard API access is disabled for it.

Fix

Check organization_id against the organizations the key can see (see the organization_id option), grant the key's owner read-only access, and enable Dashboard API access for the organization.

configured organization_id is not visible to the Meraki credential

Cause

The API key works, but the organization in organization_id is not among the organizations it can see.

Fix

Check organization_id against the organizations the key can see (see the organization_id option), or use an API key of an administrator of that organization.

operation: HTTP status 429

Cause

Meraki rate-limited the request. The budgets of 10 requests per second per organization and 100 per source IP address are shared with every other application and job using them.

Fix

The collector sends nothing until the Retry-After delay Meraki requested has passed. If this happens when the job starts, the job retries after that delay only when autodetection_retry is set.

If it happens regularly, reduce the organization's other API usage, move other API clients off the Agent's address, or increase update_every.

Meraki API Retry-After delay has not elapsed

Cause

An earlier request was rate-limited and the wait Meraki requested is still running, so the collector skipped this collection without contacting the API.

Fix

No action is needed; collection resumes when the wait ends. If it recurs, see the HTTP status 429 entry.

operation: HTTP status 5xx

Cause

The Meraki API had a temporary failure, or a proxy in between could not reach it.

Fix

Usually none; the next collection tries again. If it persists, check Meraki's service status and, when proxy_url is set, the proxy.

operation: HTTP request failed: reason

Cause

The request got no HTTP answer. The end of the message says why; for context deadline exceeded, see that entry.

Fix

Reason contains	Check
no such host	DNS resolution of the API host on the Agent
connection refused, i/o timeout, connection reset	Firewall rules for outbound HTTPS (port 443) to the API host and the Meraki shard hosts
proxyconnect	proxy_url, or the proxy environment variables when proxy_url is empty
x509: or tls:	Certificate trust: set tls_ca when a proxy or private endpoint uses its own CA
Meraki redirect	The API or a proxy redirected the request to a host the collector does not trust; see the url option

To test the same path from the Agent host, preferably as the netdata user (replace the host with the one in url for another region):

curl -sS -o /dev/null -w '%{http_code}\n' -H "Authorization: Bearer $MERAKI_API_KEY" https://api.meraki.com/api/v1/organizations

context deadline exceeded

Cause

A collection or the startup check took longer than timeout. Every page counts toward it, and the collector sends at most 10 requests per second, so a very large organization or a slow network can run out of time.

Fix

Check connectivity to the API endpoint. If requests succeed but the organization cannot finish in time, increase timeout. With collect_switch_port_packets, every switch adds a request; raise timeout with the number of switches, or disable the option.

operation: invalid pagination target

Cause

A next-page link pointed outside the endpoint in url. This happens when url is a proxy or private endpoint that passes Meraki's Link headers through unchanged, and only for lists longer than one page.

Fix

Configure the proxy to rewrite Location and Link headers to its own address, or set url to the Meraki API endpoint of the organization's region.

operation: cannot prepare authenticated request

When

bearer_token_file is set.

Cause

The key file is missing, empty or not readable by the netdata user.

Fix

Check the path in bearer_token_file, that the file contains the API key, and that the netdata user can read it.

operation: invalid JSON array response

Cause

The endpoint answered with something other than Meraki API data, typically because url points to another service or a proxy answered with its own page.

Fix

Set url to a Meraki API endpoint with the path /api/v1 (see the url option), and check proxy_url.

Meraki requires exactly one API key or bearer token file

Cause

Both authentication options are empty, both are set, or api_key contains a line break.

Fix

Set either api_key or bearer_token_file and clear the other. Make sure the key is on one line.

Meraki base URL must be an HTTPS /api/v1 URL without credentials, query or fragment

Cause

url is not an HTTPS URL with the path /api/v1, or it contains a user name, password, query or fragment.

Fix

Use one of the regional endpoints listed for the url option, or your endpoint's HTTPS URL with the path /api/v1.

organization_id must be a nonempty organization ID without surrounding whitespace

Cause

organization_id is empty, has leading or trailing spaces, or is . or ...

Fix

Set organization_id to the organization's ID, quoted as a string in YAML ("123456").

cannot initialize Meraki HTTP transport; check proxy and TLS configuration

Cause

proxy_url is not a valid URL, or a TLS file in tls_ca, tls_cert or tls_key cannot be read or parsed.

Fix

Check proxy_url, and that the TLS files exist, are readable by the netdata user and contain PEM data.

tls_cert and tls_key must be configured together

Cause

Only one of the client certificate options is set.

Fix

Set both tls_cert and tls_key, or neither.

Meraki assigned device has no serial

Cause

The assigned-device list from Meraki contained an entry without a serial number. The whole collection is dropped rather than shown with a device missing.

Fix

Usually temporary; the next collection reads the list again. If it persists, report it to Cisco Meraki support with the time of the error.

conflicting Meraki assigned-device records

Cause

The assigned-device list listed the same serial twice with different details, typically because a device was renamed or moved while the pages were read. The whole collection is dropped.

Fix

Usually temporary; the next collection reads the list again. If it persists, report it to Cisco Meraki support.

conflicting Meraki network records

Cause

The network list listed the same network ID twice with different names, typically because a network was renamed while the pages were read. The whole collection is dropped.

Fix

Usually temporary; the next collection reads the list again. If it persists, report it to Cisco Meraki support.

conflicting Meraki organization records

Cause

The organization list listed the configured organization ID twice with different details. The whole collection is dropped.

Fix

Usually temporary; the next collection reads the list again. If it persists, report it to Cisco Meraki support.

Meraki network belongs to a different organization

Cause

The network list for the configured organization contained a network of another organization. The whole collection is dropped.

Fix

Usually temporary; the next collection reads the list again. If it persists, report it to Cisco Meraki support.

Device node shows inventory but no availability chart

Cause

Meraki did not report a usable status for the device in the last collection. Availability can lag a new assignment or a network move by one refresh.

Fix

Check the device's status in Dashboard and wait for the next 5-minute refresh. Run the collector in debug mode (see Diagnostics) to see how many devices had no usable status.

Meraki traffic unavailable: error

Cause

A switch port traffic, switch port packets or appliance uplink traffic request failed. That traffic has gaps for this collection (for packets, only the ports of that switch); inventory, availability and the other traffic options still update. After an HTTP 429, no more traffic requests are sent in this collection. The warning is logged at most once an hour per kind of traffic.

Fix

Most messages continue with another error on this page, such as getDeviceSwitchPortsStatusesPackets: HTTP status 403; follow that entry. Inventory worked in the same collection, so an HTTP 403 or 404 here is about that traffic data, not about organization_id: check in Meraki Dashboard that the API key's administrator can see the switch or network and that it reports this data.

Switch port or uplink traffic charts are missing

Cause

The traffic option is off, the organization has no switches or no MX or Z networks, or Meraki reported no usable value. Switch port traffic also has gaps while Meraki has reported no interval that ended in the last 15 minutes.

Fix

Enable collect_switch_port_traffic, collect_switch_port_packets or collect_appliance_uplink_traffic. If they are on, look for the traffic warning above in the logs, and compare with the traffic Meraki Dashboard shows for the switch or network.