Meraki Network Performance Monitoring and Alerts

Meraki Network Monitor

Automatically monitors latency and packet loss for Cisco Meraki networks, sends alerts via Teams when performance exceeds thresholds, and uses Redis to prevent duplicate notifications.

23 NodesIndustry VerticalNetwork MonitoringPerformance AlertsMeraki

Workflow Overview

This n8n workflow is a Cisco Meraki Network Monitoring and Alerting System designed to automatically monitor network performance metrics (latency and packet loss) and send alert notifications when issues are detected. The workflow retrieves organization, network, and uplink statistics via the Meraki API, calculates average performance metrics, filters problematic sites, sends alerts through Microsoft Teams, and uses a Redis database to prevent duplicate alerts.

Workflow Structure

1. Trigger Nodes

Node Names:

  • When clicking "Execute Workflow" (Manual Trigger)
  • Schedule Trigger (Scheduled Trigger)

Functionality: This workflow supports two triggering methods:

  • Manual execution: triggered by clicking the "Execute Workflow" button
  • Scheduled execution: runs automatically based on a predefined schedule (for continuous monitoring)

2. Data Collection Phase

2.1 Retrieve Meraki Organization Information

Node Name: Get Meraki Organizations

Functionality:

  • Makes an HTTP request to the Meraki API (https://api.meraki.com/api/v1/organizations)
  • Uses header-based authentication requiring a configured Meraki API key
  • Retrieves a list of all organizations accessible to the account

Technical Details:

  • Request Type: GET
  • Authentication Method: HTTP Header Auth
  • Required Headers:
    • Authorization: for authentication
    • Accept: application/json: specifies JSON response format

2.2 Organize Organization Data

Node Name: Get Org Name & ID

Functionality:

  • Uses a Set node to extract and rename key fields
  • Extracts from raw data:
    • CompanyName: Organization name
    • OrgID: Organization ID

2.3 Retrieve Network IDs

Node Name: Get Network IDs

Functionality:

  • For each organization ID, calls the API to retrieve all associated networks
  • Uses dynamic URL: https://api.meraki.com/api/v1/organizations/{{ $json.OrgID }}/networks
  • Provides a network list for subsequent monitoring

2.4 Format Network Variables

Node Name: Sets Network Variables

Functionality:

  • Extracts and formats network information
  • Includes key fields such as network name, network ID, and network URL

2.5 Retrieve Uplink Statistics

Node Name: Get Uplink Loss and Latency

Functionality:

  • Retrieves uplink performance statistics for network devices
  • Includes:
    • Packet loss percentage (Loss Percent)
    • Latency in milliseconds (Latency Ms)
    • Time-series data (latest 5 data points)

3. Data Processing and Analysis Phase

3.1 Data Merging

Node Name: Combine latency to its respective Network

Functionality:

  • Uses a Merge node to combine network information with performance statistics
  • Matching fields: NetworkID and networkId
  • Merge mode: enrichInput1 (enriches data from input 1)

3.2 Data Restructuring

Node Name: Makes Latency and Loss Filterable

Functionality:

  • Restructures data to make latency and loss easier to filter and analyze
  • Extracts 5 time-series data points:
    • TS0-Loss to TS4-Loss: packet loss percentages at 5 time points
    • TS0-Latency to TS4-Latency: latencies at 5 time points
  • Retains metadata such as network name, serial number, and URL

3.3 Calculate Averages

Node Name: Average Latency & Loss over 5m

Functionality:

  • Uses JavaScript code to calculate averages across the latest 5 time points
  • Computes two key metrics:
    • AverageLoss: average packet loss percentage
    • AverageLatency: average latency (in milliseconds)
  • These averages enable more accurate identification of performance issues

Code Logic:

// Sum packet loss and latency across 5 time points
// Divide by 5 to get averages
// Add results to data items

3.4 Filter Problematic Sites

Node Name: Filters Problematic sites

Functionality:

  • Uses JavaScript code to filter sites exceeding thresholds
  • Threshold criteria:
    • Average latency > 300 ms
    • OR average packet loss > 2%
  • Only sites meeting either condition proceed to the next step

Filtering Logic:

// If AverageLatency > 300 or AverageLoss > 2
// Mark site as problematic

4. Alert Deduplication and Notification Phase

4.1 Check if Alert Already Exists

Node Name: Check if Alert Exists

Functionality:

  • Queries Redis database to check if an alert has already been sent for this network
  • Uses network name as the key
  • If the key exists, an alert was already sent (within TTL period)

4.2 Create Response Data

Node Name: Create Response

Functionality:

  • Uses JavaScript to process Redis query results
  • Converts results into usable boolean values or flags
  • Determines whether a new alert should be sent

4.3 Merge for Deduplication

Node Name: Merge

Functionality:

  • Merges problematic sites with existing alert data
  • Matching field: NetworkName
  • Merge mode: keeps all non-matching items
  • Key Logic: If network names match, the alert already exists and won't be resent; only unmatched (new issues) proceed

4.4 Send Teams Message

Node Name: Message Techs

Functionality:

  • Sends alert messages via Microsoft Teams Webhook
  • Message content includes:
    • Network name
    • Average latency and packet loss data
    • Network URL (as a clickable hyperlink to directly access the problematic site)
  • Notifies technical teams that a site has exceeded performance thresholds

4.5 Log the Alert

Node Name: Log the Alert

Functionality:

  • Records the alert in Redis database
  • Sets TTL (time-to-live) to 3 hours
  • Deduplication Logic: If the same site's issue remains unresolved within 3 hours, another alert will be sent after the TTL expires

5. Auxiliary Notes

The workflow includes multiple Sticky Note nodes providing detailed usage instructions:

  • Sticky Note3: Explains how to configure Meraki API authentication
  • Sticky Note4: Describes data merging and statistical calculation logic
  • Sticky Note5: Details alert deduplication mechanism and notification flow
  • Sticky Note6: Suggests additional use cases (e.g., integrating with PSA tools to create tickets)

Workflow Diagram

[Trigger] → [Get Organizations] → [Organize Org Data] → [Get Network IDs] → [Format Network Data]
                ↓                                                    ↓
          [Get Uplink Stats] ----------------------------------------→ [Merge Data]
                                                                        ↓
                                                        [Restructure Latency/Loss Data]
                                                                        ↓
                                                           [Calculate 5-Minute Averages]
                                                                        ↓
                                                          [Filter Problematic Sites]
                                                                        ↓
                                            [Check if Alert Exists] ← → [Deduplication Merge]
                                                    ↓                   ↓
                                            [Create Response] ----------------→ [Send Teams Message]
                                                                        ↓
                                                                 [Log the Alert]

Key Technical Points

1. API Authentication

2. Performance Thresholds

  • Latency Threshold: 300 ms
  • Packet Loss Threshold: 2%
  • These thresholds can be adjusted based on actual requirements

3. Alert Deduplication Mechanism

  • Uses Redis to store sent alerts
  • TTL set to 3 hours
  • Prevents duplicate alerts for the same site within the TTL period

4. Data Processing Approach

  • Collects data from the latest 5 time points
  • Calculates averages to reduce impact of transient fluctuations
  • Uses JavaScript Code nodes for complex data processing and filtering

Use Cases

  1. Network Performance Monitoring: Continuously monitors Meraki network latency and packet loss
  2. Proactive Alerting: Automatically notifies technical teams when performance degrades
  3. Troubleshooting: Provides direct network URL links for rapid issue localization
  4. Alert Management: Prevents alert flooding by sending only one alert per site every 3 hours

Extension Suggestions

As noted in Sticky Note6, the following extensions are possible:

  1. PSA System Integration: Replace the Teams message node with a PSA tool node (e.g., ConnectWise Manage) to automatically create tickets instead of just sending messages
  2. Multi-channel Notifications: Add email, Slack, or other notification channels in addition to Teams
  3. Custom Thresholds: Set different performance thresholds for different networks
  4. Historical Data Storage: Store monitoring data in a database for long-term analysis and trend prediction

Summary

This is a complete automated network monitoring workflow that fully leverages n8n's capabilities:

  • HTTP requests to integrate external APIs
  • Data transformation and processing (Set and Code nodes)
  • Data merging (Merge nodes)
  • Conditional filtering and logical evaluation
  • External notifications (Teams Webhook)
  • Data persistence (Redis)

Through automated monitoring and intelligent alerting, it significantly improves network operations efficiency and reduces manual inspection workload.