我有两个生产网络（我们叫它们ZoneA和ZoneB），它们通过专用服务器（ipsecA1，{{ 1}}和ipsecA2，ipsecB1），由 keepalived 管理每个区域的浮动公共IP和私有IP。
所有这些都由 Zabbix 服务器监视（您可能已经猜到了：ipsecB2和ZabbixA）。
ZabbixB此外，ZabbixA ZabbixB
╔═════════════╗ ╔═════════════╗
║ ┌───────┐ ║ ║ ┌───────┐ ║
║┌─┤ipsecA1│──╫─────────╫──┤ipsecB1├─┐║
║│ └───┬───┘ ║ ║ └───┬───┘ │║
║│ keepalived ║ ║ keepalived │║
║│ ┌───┴───┐ ║ ║ ┌───┴───┐ │║
║└─┤ipsecA2│ ║ ║ │ipsecB2├─┘║
║ └───────┘ ║ ║ └───────┘ ║
╚═════════════╝ ╚═════════════╝
是“主”（由于缺乏更好的描述）：它是发起重新认证的人。
未达到以下几点时，我们希望在每个区域弹出警报：
ipsecA1 x ipsec）：
1 x ipsec）：
总结：如果每台计算机上的所有3个检查值都不相同，则说明存在问题。
通过脚本检查IPsec隧道，如果该脚本已建立，则返回2（1上grep的{{1}}），如果ESTABLISHED不是。
公共和私有浮动IP的检查方式相同。
脚本和ipsec status文件已正确配置，并且已在两个 Zabbix 服务器上创建了相关的模板/应用程序/项目：项目确实显示了正确的状态。
两个区域上的触发器均已配置
0在.conf上，还存在一个仅用于检查隧道状态({ipsec_server:ipsec.status.last(3m)}<>{ipsec_server:keepalived.vip.private.last(3m)})
or ({ipsec_server:ipsec.status.last(3m)}<>{ipsec_server:keepalived.vip.public.last(3m)})
or ({ipsec_server:keepalived.vip.private.last(3m)}<>{ipsec_server:keepalived.vip.public.last(3m)})
的触发器，但仅在解决主要问题之前存在。
PS：我不确定这里是否有意义，但是ipsecA1是v2.4.7，而ipsec.status.last(3m)是v3.4.11。
PPS：在每一侧，ZabbixA（v2.4.7）和ZabbixB（v3.4.11）参数分别未设置和设置为单个，因为我真的不知道它们是如何工作的。
每隔一段时间，在Multiple PROBLEM events generation上，两个触发器都会触发警报，并在几秒钟内发布恢复。 PROBLEM event generation mode上没有任何触发。
在大多数情况下，日志中没有任何东西可以区分触发警报的重新认证与未触发警报的重新认证。
ipsecA1已被更改，希望能够查明正在发生的事情，但无济于事：
ZabbixB每个触发函数为loglevels的原因是因为我认为/希望Zabbix将检查所有三个项目的状态（ /var/log/charon.log {
time_format = %b %e %T
append = yes
default = 1
}
stderr {
ike = 2
knl = 3
net = 2
dmn = 2
mgr = 2
job = 2
ike_name = yes
}
，.last(3m)和ipsec.status），以及如果其中任何一个在最近3分钟内偏离了预期状态，触发器就会熄灭。
原来是it was not the best idea ...
关于keepalived.vip.public被滥用，然后由keepalived.vip.private，.last(x)或类似的词取代，已经有很多问题，但是我发现的所有示例都是关于如何处理类比数字。
我找不到太多关于二进制/布尔结果的信息，因此我不确定类似数字的答案是否适用于此...
即使解决了主要问题，我的触发条件也不是最好的，而且很有可能得到改善。
我正在考虑在隧道的另一端添加ping作为触发器的附加条件，以确保即使.avg()说有问题，我们也会尝试到达隧道的另一端，确定。
再一次，我不确定如何实现。
我愿意接受任何聪明的主意。