先定义 VPN 对象，再选择 SNMP 或 API

在传输之前有三个决定：告警描述的是哪个对象、覆盖哪个方向与范围，以及读数需要多新。SNMP、HTTPS API 和应用探针都能报告关于 VPN 的某些情况，但它们报告的不是同一件事。不先解决这三点就更换协议，只会改变混乱被收集的位置。对象与告警的含义才是设计；协议只是投递。

把四种不同观测变成一个绿色图标的仪表盘，早已把这个决定做错了。

告警究竟应该意味着什么？

它可能意味着某个对等端无法通过认证、不存在受保护的数据状态、某条路由指向错误的位置，或某个应用无法完成工作。每一种都有各自的责任人、各自的第一项检查和各自的误报率。无法通过认证的对等端是身份问题，缺失的安全关联是协议状态问题，路由是配置问题，而应用故障可能都不是。在挑选采集器之前，先决定告警针对哪一种。

把它写成当班工程师可以据以行动的一句话。如果这句话需要两个对象，那就是两条告警，而不是一条半对的告警。

TCP 表描述的是 TCP

RFC 4022 规定了 tcpConnectionTable，其行描述已建立的 TCP 连接，以两端的地址类型、地址和端口为键。连接关闭时行会消失，监听套接字出现在另一张表中。在同一台机器上运行 VPN 并不会把 TCP 表变成 IPsec 安全关联清单。它可能描述管理会话、应用流，或承载在 TCP 之上的隧道，而这一行本身不会告诉你是哪一种。

接口计数器在更粗的层面上带有同样的含糊：接口上的字节把使用它的每个对等端和每条流汇总在一起。

建立一份小小的观测契约

对每个指标，记录所支持的对象或 API 字段、所属设备与软件版本、对等端或服务标识、方向、采集时间以及预期的刷新行为。然后，协议状态使用网关文档化的关联或会话视图，路径状态使用路由表，应用状态使用范围很窄的获准请求。一个能工作的管理端点只能证明管理端点能工作，对背后的应用一无所知。

如果已安装的代理缺少所需对象，就选择另一个明确支持的只读接口。编造 OID、把通用 TCP 计数当作隧道计数来读，或指望旧厂商 API 在同类产品中原样存活，都是死路。

过期数据不是隧道故障

采集超时、凭证过期或 API 路径改变会产生缺失的遥测。这是监控故障，与隧道中断是不同的事件。记录哪项观测何时变旧，好让操作员得到有意义的第一项检查，而不是重置隧道。把每次超时都当作 VPN 中断，会让人同时忽略两者。

采集权限也要保持狭窄。能更改配置或清除会话的接口带有监控任务不应继承的权限边界，只读账户通常就足够。

有用的设计会指出对象、含义和新鲜度要求。协议选择由此而来，而不是反过来。