VPN 登录告警：到底该由哪个事件触发

认证成功、隧道建立和 RADIUS accounting Start 是三种不同的断定，登录邮件只有在你选定其中一种之后才有意义。大多数 VPN 告警设计把三者混在一起，产出一个没人信任的收件箱。决定取决于谁读这封告警，以及他在接下来五分钟里能做什么。一旦选错，告警就会变成噪声，把你真正需要的那一个事件藏起来。

三个问题决定触发条件

先问谁收、他会做什么、动作必须多快发生。盯着凭据滥用的安全团队要的是同一账户在几分钟内先失败后成功的模式。盯着容量的运维团队要的是会话时长和断开原因，而不是登录。服务台要的是会话身份，好让它对上工单。

这些答案指向不同事件，没有一条规则能同时满足三者。如果收件人的动作是「给用户打电话」，认证就够了。如果动作是「释放一个许可证」或「确认隧道确实承载了流量」，那只有建立或 accounting Start 才行。如果动作是「按时间计费」，你需要的是 Stop 记录，而不是一次登录。

在配置任何东西之前，先把答案写成一句话。这封邮件告诉值班工程师：账户 X 在 Z 时刻从网络 Y 打开了一条隧道，以便他核查维护窗口是否被使用。如果每一格都填不满，触发条件就还没有选定。

让事件对上你要做的断定

表里藏着一个依赖：每一行只有在网关可靠发出、且你的采集器保留所需字段时才可信。请按你实际运行的那个版本去读事件定义，因为「会话建立」这个名字在各版本之间会变，而含义变得比名字更频繁。定义含糊时，去要一次会话抓包，不要靠标签猜。

把 Access-Accept 当成其后一切完成的标志，是最常见的错误。它是对凭据的裁定，不是会话。镜像的错误是：把策略命中读成授权证明，而规则可以命中、下一步仍可能失败。

一个会话，一条通知

一个账户、多台设备、重传与重连：每个事件发一封邮件一定两头都错，一边把同一会话重复，一边把另一会话拆开。通知的键应当取网关加会话标识，账户名只当属性，不当键。带着笔记本和手机的用户可以同时握有两条隧道，两者都该有各自的一行。

重传的计费记录是常态，所以渲染消息之前先按会话 id 和时间戳去重。同一设备的连续会话应当分开，维护窗口中的重连应当保持可见，而不是并进上一条。如果你的采集器在入库时重写时间戳，去重要用原始记录字段，不要用存储后的字段。

缺少 Stop 记录意味着不确定，而不是永久会话。网关重启、采集器中断和 UDP 丢包都会留下空洞，所以告警需要一条对账路径：在任何人断定隧道仍然在线之前，先查询活动会话表。

把审计和通知分开

审计流和告警流承担不同职责。保留原始记录，包括账户、网关、会话 id、时间戳和终止原因，即便日常邮件被归并、抑制或只发给一个小值班名单。严重级别阈值是投递过滤器，不是你选择要宣告的那个生命周期事件。

只发收件人找到受保护记录所需的最小上下文。账户名、内网地址和会话细节都是敏感信息，而一封方便转发的邮件就是一封方便泄露的邮件。

然后端到端验证。跑一次正常登录与登出、一次重连、两个并发会话，以及一次强制投递失败，并把一个事件从网关经采集器一路追到投递出去的消息。如果邮件到了却没有会话 id，契约就不完整。如果两封邮件描述同一个会话，关联就是坏的。当你只测「邮件能送达」时，这两个问题都不会暴露。