当代理服务closures时，停止zabbix-proxy下的节点的Zabbix通知

一种方法是监视Zabbix代理是否可访问。 这是使用zabbix[proxy,<name>,lastaccess]内部项目完成的。 在关于内部项目的文档中 ，然后build议使用fuzzytime()触发器函数来检查代理的可用性：

 {<zabbix>:zabbix[proxy,<name>,lastaccess].fuzzytime(2m)}=0 

之后，您可以使您的“主机无法访问”触发器依赖于此触发器，这将阻止它在代理无法访问时被激活（请参阅关于触发器相关性的文档以获取更多信息）。

asaveljevs的答案是好的。 关于潜在问题的一些说明。

代理将被检测为丢失，并且依赖关系将按预期工作。 但是我们假设一个代理服务器在很长的一段时间内是不可达的 – 30分钟或更长时间。 让我们假设它继续收集数据。 一旦连接恢复，它将发送值。在这一点上，服务器看到代理服务器可用（内部最后访问项目被更新），但代理服务器总是按顺序发送数据（较早的值）。 如果代理收集了大量的值，则需要一些时间才能发送最近的值。 对于代理服务器后面的主机，你可能会有nodata（）触发器的可用性，这些触发器会看到数据丢失 – 并且会触发。

从zabbix 2.2开始，有一个新的内部项目 – zabbix[proxy_history] 。 理论上，它可以用来监视多less个未发送的值zabbix代理已经有一个触发器（吨），如果这个数字很高。 那么将会依赖于来自所有主机可用性触发器的触发器（t），并且触发器（t）依次取决于最后接入触发器。 这样，如果代理突然消失，我们仍然有一个最后访问dep。 如果它回来了，我们会注意到大量的历史积压，并且还没有提醒任何东西…除了内部项目受到相同的代理队列/较老的第一规则的影响。 直到我们获得了有关大代理缓冲区/历史的值，我们已经触发了代理之后的主机触发器。

那么有没有解决scheme？ 也许。

可以从代理数据库中提取关于代理缓冲区的信息。 我们的任务是一旦连接恢复，就尽快把它送到服务器。 我们有两个select：

• 使用直接与服务器通话的代理

zabbix代理将收集缓冲区/历史logging大小，并直接将其推送到服务器，而不通过代理caching/缓冲区。 如果这是一个被动的代理，我们将在停机时间内完全丢失缓冲区值，然后我们将依赖项目间隔来获得连接之后的第一个值。 如果这是一个活跃的代理，那么在停机时间内，我们可以保留一定数量的数据（默认为100或50）。 尽pipe如此，它可能会引入微小的延迟来发送这些值。 默认情况下，代理将尝试每5秒或更频繁地发送这些值。

• 直接使用zabbix_sender到服务器

在这种情况下，我们可以决定是否关心停机时间的价值。 如果我们不那么简单 – 收集这些值并将它们推送到服务器，忽略失败。 如果我们希望尽快获得价值，那么我们可能会推出一些逻辑来每60秒发送一次值，但是如果失败的话，每5秒钟左右一次。 如果我们关心停机期间的值，我们将不得不实施逻辑来每间隔秒存储这些值。 如果发送失败，则始终先用旧值重试，但继续收集值（旧值必须先发送，以防止触发此事件的事件不会全部混乱）。 相比于丢弃价值，这可能会引入一个微小的延迟，以获得服务器的最新价值。

在所有这些情况下，可能都有一个非常小的竞态条件窗口，可以通过触发器周围的一些巧妙的技巧来消除（也许通过要求lastaccess是最近的，并确保它的最后3个值都是不同的或者是在这个方向上的东西）。

哦，以及一个潜在的查询来获取代理数据库的历史/缓冲区大小（可能不适用于所有支持的数据库，根据需要进行调整）：

select（（从proxy_historyselectmax（proxy_history.id））-nextid）从其中field_name ='history_lastid'的ID;