Meraki 網路效能監控與告警
Meraki Network Monitor
自動監測 Cisco Meraki 網路的延遲和封包遺失率，當效能超過閾值時透過 Teams 發送告警，並使用 Redis 防止重複通知
工作流程概述
本 n8n 工作流程是一個 Cisco Meraki 網路監控與告警系統，用於自動監測網路效能指標（延遲和封包遺失率），並在偵測到問題時發送告警通知。該工作流程透過 Meraki API 取得組織、網路和上行鏈路統計資料，計算平均效能指標，篩選出有問題的站點，並透過 Microsoft Teams 發送告警訊息，同時使用 Redis 資料庫防止重複告警。
工作流程結構
1. 觸發器節點
節點名稱：
When clicking "Execute Workflow"（手動觸發器）Schedule Trigger（定時觸發器）
功能說明： 此工作流程支援兩種觸發方式：
- 手動執行：透過點擊「執行工作流程」按鈕手動觸發
- 定時執行：依照預設的時間排程自動執行（用於持續監控）
2. 資料採集階段
2.1 取得 Meraki 組織資訊
節點名稱： Get Meraki Organizations
功能說明：
- 透過 HTTP 請求呼叫 Meraki API (
https://api.meraki.com/api/v1/organizations) - 使用 Header 認證方式，需設定 Meraki API 金鑰
- 取得帳戶有權存取的所有組織清單
技術細節：
- 請求類型：GET
- 認證方式：HTTP Header Auth
- 必需的 Header：
Authorization：用於身份驗證Accept: application/json：指定回傳 JSON 格式資料
2.2 整理組織資料
節點名稱： Get Org Name & ID
功能說明：
- 使用 Set 節點提取並重新命名關鍵欄位
- 從原始資料中提取：
CompanyName：組織名稱OrgID：組織 ID
2.3 取得網路 ID
節點名稱： Get Network IDs
功能說明：
- 針對每個組織 ID，呼叫 API 取得其下的所有網路
- 使用動態 URL：
https://api.meraki.com/api/v1/organizations/{{ $json.OrgID }}/networks - 為後續的網路監控提供網路清單
2.4 整理網路變數
節點名稱： Sets Network Variables
功能說明：
- 提取並格式化網路資訊
- 包含網路名稱、網路 ID、網路 URL 等關鍵欄位
2.5 取得上行鏈路統計資料
節點名稱： Get Uplink Loss and Latency
功能說明：
- 取得網路設備的上行鏈路效能統計
- 包含：
- 封包遺失百分比（Loss Percent）
- 延遲毫秒數（Latency Ms）
- 時間序列資料（最近 5 個時間點的資料）
3. 資料處理與分析階段
3.1 資料合併
節點名稱： Combine latency to its respective Network
功能說明：
- 使用 Merge 節點將網路資訊與效能統計資料合併
- 配對欄位：
NetworkID與networkId - 合併模式：enrichInput1（豐富輸入 1 的資料）
3.2 資料重組
節點名稱： Makes Latency and Loss Filterable
功能說明：
- 重新組織資料結構，使延遲與封包遺失資料更易於篩選與分析
- 提取 5 個時間序列資料點：
TS0-Loss至TS4-Loss：5 個時間點的封包遺失率TS0-Latency至TS4-Latency：5 個時間點的延遲
- 保留網路名稱、序號、URL 等中繼資料
3.3 計算平均值
節點名稱： Average Latency & Loss over 5m
功能說明：
- 使用 JavaScript 程式碼計算最近 5 個時間點的平均值
- 計算兩個關鍵指標：
AverageLoss：平均封包遺失率AverageLatency：平均延遲（毫秒）
- 這些平均值用於更準確地識別效能問題
程式碼邏輯：
// 計算 5 個時間點的總封包遺失率與總延遲
// 除以 5 得到平均值
// 將結果加入資料項目中
3.4 篩選有問題的站點
節點名稱： Filters Problematic sites
功能說明：
- 使用 JavaScript 程式碼篩選超過閾值的站點
- 閾值標準：
- 平均延遲 > 300 毫秒
- 或 平均封包遺失率 > 2%
- 僅符合任一條件的站點會傳遞至下一步
篩選邏輯：
// 如果 AverageLatency > 300 或 AverageLoss > 2
// 則該站點被標記為有問題
4. 告警去重與通知階段
4.1 檢查告警是否已存在
節點名稱： Check if Alert Exists
功能說明：
- 查詢 Redis 資料庫，檢查該網路是否已發送過告警
- 使用網路名稱作為鍵值
- 若鍵存在，表示已在 TTL 時間內發送過告警
4.2 建立回應資料
節點名稱： Create Response
功能說明：
- 使用 JavaScript 處理 Redis 的查詢結果
- 將結果轉換為可用的布林值或識別符
- 判斷是否需要發送新的告警
4.3 合併去重
節點名稱： Merge
功能說明：
- 合併有問題的站點與已存在告警的資料
- 配對欄位：
NetworkName - 合併模式：保留所有不匹配的項目
- 關鍵邏輯：若網路名稱匹配，表示告警已存在，不再發送；僅不匹配者（即新問題）才會繼續
4.4 發送 Teams 訊息
節點名稱： Message Techs
功能說明：
- 透過 Microsoft Teams Webhook 發送告警訊息
- 訊息內容包含：
- 網路名稱
- 平均延遲與封包遺失率資料
- 網路 URL（超連結形式，可直接跳轉至問題站點）
- 通知技術團隊有站點超出效能閾值
4.5 記錄告警日誌
節點名稱： Log the Alert
功能說明：
- 將告警記錄至 Redis 資料庫
- 設定 TTL（存活時間）為 3 小時
- 防重複邏輯：若同一站點的問題在 3 小時內未解決，3 小時後會再次發送告警
5. 輔助說明節點
工作流程中包含多個 Sticky Note（便箋）節點，提供詳細的使用說明：
- Sticky Note3：說明如何設定 Meraki API 認證
- Sticky Note4：說明資料合併與統計計算的邏輯
- Sticky Note5：詳細說明告警去重機制與通知流程
- Sticky Note6：建議其他使用情境（如整合 PSA 工具建立工單）
工作流程圖
[觸發器] → [取得組織] → [整理組織資料] → [取得網路ID] → [整理網路資料]
↓ ↓
[取得上行鏈路資料] ----------------------------------------→ [合併資料]
↓
[重組延遲封包遺失資料]
↓
[計算5分鐘平均值]
↓
[篩選有問題的站點]
↓
[檢查告警是否存在] ← → [去重合併]
↓ ↓
[建立回應] ----------------→ [發送Teams訊息]
↓
[記錄告警日誌]
關鍵技術要點
1. API 認證
- 需在 Meraki Dashboard 產生 API 金鑰
- 參考文件：https://documentation.meraki.com/General_Administration/Other_Topics/Cisco_Meraki_Dashboard_API
- 使用 HTTP Header Authentication
2. 效能閾值
- 延遲閾值：300 毫秒
- 封包遺失閾值：2%
- 此些閾值可依實際需求調整
3. 告警防重複機制
- 使用 Redis 儲存已發送的告警
- TTL 設定為 3 小時
- 在 TTL 期間內不會重複發送相同站點的告警
4. 資料處理方式
- 採集最近 5 個時間點的資料
- 計算平均值以減少瞬時波動的影響
- 使用 JavaScript 程式碼節點進行複雜的資料處理與篩選
使用情境
- 網路效能監控：持續監測 Meraki 網路的延遲與封包遺失狀況
- 主動告警：在效能下降時自動通知技術團隊
- 故障排除：提供網路 URL 直達連結，快速定位問題
- 告警管理：防止告警轟炸，3 小時內僅發送一次告警
擴充建議
根據 Sticky Note6 的說明，可進行以下擴充：
- 整合 PSA 系統：將 Teams 訊息節點替換為 PSA 工具節點（如 ConnectWise Manage），自動建立工單而非僅發送訊息
- 多通道通知：除了 Teams，亦可新增電子郵件、Slack 等通知管道
- 自訂閾值：為不同網路設定不同的效能閾值
- 歷史資料儲存：將監控資料存入資料庫，用於長期分析與趨勢預測
總結
這是一個完整的網路監控自動化工作流程，充分運用 n8n 的以下能力：
- HTTP 請求整合外部 API
- 資料轉換與處理（Set、Code 節點）
- 資料合併（Merge 節點）
- 條件篩選與邏輯判斷
- 外部通知（Teams Webhook）
- 資料持久化（Redis）
透過自動化監控與智慧告警，大幅提升了網路維運效率，減少了手動檢查的工作量。