统计活跃的 FTD 站点 VPN：你指的是哪个数字？

在编写 Ansible 任务之前，先回答一个更小的问题：到底在数什么？已配置对端、IKE 会话、IPsec 安全联盟和受监控的隧道状态记录是四种不同的单位，而密钥重协商或多条受保护网络会让它们的总数彼此偏离。如果仪表盘和 playbook 对不上，通常是因为它们在数不同的东西，而不是其中一方错了。

人们称为“活跃”的四样东西

已配置对端是拓扑对象：它存在是因为有人定义了它。IKE 会话是控制面关系，可以在没有流量时保持建立状态。IPsec SA 是面向特定选择器对的数据面关联，一条隧道可以承载多条。受监控的隧道状态是平台自身的运行判定，通常最接近运维人员说“隧道是通的”时所指的含义。

只有最后一种才是运行计数的合理依据。第一种是配置清单，把它当作活跃来上报，正是仪表盘为周二就已宕机的对端显示绿色的原因。先确定数字的使用者需要哪种单位，再把这个单位写进指标自己的名字里。

第一个决定：用哪个管理平面？

如果设备由 FDM 管理，相关接口是 FTD REST API。如果由 FMC 管理，那个 API 并不是可互换的替代品，对象位于 FMC 自己的 API 之后。在写下第一条请求之前先确认这一点，因为错的平面会返回一个看起来像权限问题的、貌似合理的错误。

对于设备群，答案还决定了计数归属：通过 FDM 按设备计，还是通过 FMC 按域计。这是两种不同的范围，对同一设备群会给出不同的数字。

第二个决定：哪个资源能回答？

举一个与版本绑定的例子：FMC 7.3 API 对象参考在 health 路径下列出了 GET 资源：

/api/fmc_config/v1/domain/{domainUUID}/health/tunnelstatuses
/api/fmc_config/v1/domain/{domainUUID}/health/tunnelsummaries

隧道状态资源支持设备和状态过滤，包括 TUNNEL_UP。这给了你一个针对该版本可检查的真实运行资源，而不是猜测某个字段名。

在实现解析器之前，请先在已部署 FMC 的 API Explorer 中确认可用性、权限、请求参数和响应结构。某个版本的文档只是起点，并不是你正在运行的版本的契约。

写下计数的契约

用一句话说明指标：面向某一既定设备和域、报告状态为 TUNNEL_UP 的唯一运行隧道记录。然后记录冗余设备和同一逻辑站点的多条记录如何表示，因为这两种情况决定了你的数字能否与会上那个数字对上。

不要悄悄把单位从隧道记录改成远端站点。如果业务方要的是站点，就显式地把记录映射到站点，并公开这个映射。一个悄悄重新定义自己的计数比没有计数更糟，因为没人说得清它是什么时候变的。

只有在确认汇总资源到底汇总了什么之后，才能把它当作便利手段。它可能正好聚合了你需要的东西，也可能回答的是一个微妙不同的问题。把它读一遍、写下差异，如果汇总解释不清就改用状态资源。你理解不了的汇总，是你在评审中无法辩护的数字。

让流程保留不确定性

使用经过批准的 HTTPS API，校验证书，把令牌留在任务输出之外，并用该版本支持的过滤和分页取回范围。然后在做任何计算之前校验结构。

fetch intended domain/device runtime records
validate response, completeness and freshness
deduplicate by the documented tunnel identity
count records matching the approved up-state definition
report count with scope, timestamp and metric unit

这是流程伪代码，不是经过测试的 playbook。请从已安装的 API 中取真实字段名，而不是发明一个叫 active 的 JSON 键。

重要的规则是失败时的行为：授权错误、不支持的资源、过期的样本或不完整的页面集合必须产出 unknown 或 error，绝不能是成功的零。表示“我没能问”的零，是代价最高的一类错误。

对照平台自己的视图做校验

把第一个结果与该版本针对同一设备、同一时刻的 VPN 监控视图对比。当两者不一致时，先弄清各自用的是哪种单位，再改 playbook。

每次运行都保留非机密上下文：范围、时间戳、指标单位和记录数。FMC 7.3 API 对象参考是上述资源路径的来源，而你自己部署上的 API Explorer 是其他一切的来源。