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）
通过自动化监控和智能告警，显著提高了网络运维效率，减少了手动检查的工作量。