Azure Site VPN 监控：把隧穿状态与真实探测配起来

每块看板都是绿的，隧道已经上来了十一天，可分支机构就是打不开内部应用。这个设计存在的理由就是这类症状，而它不是监控的缺陷。隧道状态回答的是协商层面的问题，用户问的却是一个请求如何穿过四道路由决策和一层策略。两个信号都要，而且要分开保存，还要有办法在凌晨三点把二者区分开。

从出问题的症状入手，而不是从隧道入手

已建立的安全关联只说明双方谈成了一个提议并装好了密钥。它并不说明选择器覆盖了用户需要的子网，也不说明对端有回程路由，更不说明防火墙在解密后放行端口。流量也可能在隧道的分支机构一侧失败，那时 Azure 什么都看不到，报出的却是完美健康。隧道指标是必要的，但从来不够。

必须能区分三种状态：隧道断开、隧道正常而服务失败、以及监控源本身不可用。

把探测放在用户所在的位置

对于分支机构访问 Azure 的应用，要在分支机构工作负载网络的某台主机上运行合成测试，并指向用户真正访问的私有 HTTPS 入口。从网关发起的探测使用不同的源地址，往往也走不同的策略路径，所以它可能通过而每个用户都在失败。Azure Connection Monitor 支持带测试组和阈值的 TCP、ICMP 与 HTTP 检查，其本地源对代理的要求与 Azure 一侧不同。请核对当前支持的配置，不要照抄博客里已经退役的经典监控配方。

让探测保持狭窄而无聊：一个目的地、一个端口、与运行要求相符的频率，以及为那个源写明的放行规则。

选择与服务相匹配的检查方式

对服务端口做 TCP 连接只证明穿过隧道的传输可达，对 TLS 和应用一无所知。HTTP 检查增加状态码预期，能抓住那种接受连接却无法服务的监听者，这正是更换证书或后端之后更常见的故障。除非测试真的做了身份验证，否则两者都不是经过认证的业务事务，所以不要在看板上那样标注。要选的是在用户投诉发生时确实会失败的那种检查。

ICMP 是三者中最弱的选择，因为许多协议栈会按策略丢弃它，一次失败的 ping 证明不了什么。

把两个信号接入 Elastic，而不是凭空编造

VPN 网关会发出平台指标，例如隧道的出入字节数和丢包计数，也可以按类别发送诊断日志，其中包含隧道与 IKE 事件。Connection Monitor 的结果一路经 Azure Monitor 成为指标，一路经 Log Analytics 工作区成为日志记录。这些本身都不会自动出现在 Elastic 索引里。为指标和日志各选一条受支持的管道，通常是 Azure Event Hub 输入或 Azure Monitor 集成，并且在信任索引模式之前，先核实装好的集成实际收取了什么。

保留能让运维把两份数据关联起来的标签：探测一侧的来源端点、目的地、协议和端口，网关一侧的隧道标识和对端地址。

用一个受控事件验证管道，然后到 Elastic 里把它搜出来，核对其时间戳和资源标签。时间戳错误的文档比缺失的文档更糟，因为它让过期数据看起来是新的。

按差异告警，而不是按颜色告警

保留两个信号的意义在于组合。隧道断开应该叫醒网络负责人；隧道正常但探测失败叫醒应用负责人；探测结果缺失则叫醒监控代理的负责人。把三者合并成一块红色面板，等于保证这则告警在一个月内被静音。要针对带持续窗口的持续失败告警，而不是针对单个采样，并且为采集管道自身的健康单独加一项检查。

一块满是昨天成功采样的看板，不该在今天被读成一条健康的路径。

写下来，契约很小：隧道指标说明网关完成了协商，探测说明从用户所在的位置路径可用，管道健康则说明这两个答案是否还新鲜。看板上其余一切都是注释。