隧道监控看三个维度
隧道上线只是开始，长期可用性要靠持续监控。三个维度缺一不可：可用性看 IKE 与 IPsec 会话状态是否为正常，活性看两个方向的加解密计数是否都在增长，事件看重协商频率与失败原因。其中活性最容易被忽略——会话状态正常但计数长时间不增长，说明流量根本没走隧道，或者只有单向流量在走，这类隐性故障靠状态查询发现不了。把「计数零增长」和「状态非正常」都设为告警条件，比单纯监控会话状态有效得多。
基本信息
| 可用性指标 | IKE 会话状态、IPsec 会话状态与剩余生存期 |
|---|---|
| 活性指标 | 两个方向的加解密字节与包计数增量 |
| 事件指标 | 重协商次数、失败原因分布、SA 删除原因 |
| 告警条件 | 状态异常或计数长时间不增长 |
| 采样方式 | 定时采样并保存历史，便于做增量与趋势对比 |
典型使用场景
- 关键业务隧道：把可用性与活性指标同时纳入监控
- 批量分支隧道：用统一脚本定时采样，异常时集中告警
- 故障回溯：通过历史计数确认中断起止时间
- 巡检核对：定期对比两端计数，发现单向异常
- 容量评估：结合流量趋势判断带宽是否需要调整
巡检骨架
巡检骨架
# Cisco：查看会话状态与计数
show crypto ikev2 sa | include READY
show crypto ipsec sa | include pkts|remaining
# 间隔一段时间再采一次，对比计数增量是否都在增长
# Linux 侧 strongSwan
swanctl --list-sas | grep -E 'INSTALLED|bytes'
# 建议把输出留档，用于趋势与回溯指标与判断
| 指标 | 正常表现 | 异常含义 |
|---|---|---|
| 会话状态 | 处于已建立状态 | 长期非正常说明协商持续失败 |
| 入方向计数 | 随业务增长 | 零增长说明没有流量进入隧道 |
| 出方向计数 | 随业务增长 | 单方向为零即为单向故障 |
| 重协商频率 | 与配置周期一致 | 异常频繁说明参数不一致或存在抖动 |
只有一端做监控时容易漏掉单向问题：两端计数对照才能判断是流量没进来，还是进来了但没出去。
重协商频率值得单独设阈值。频繁重协商通常不是正常现象，多半指向两端定时器、算法或链路稳定性问题。