我有一个 zabbix-proxy 和该代理中的 12 个节点。现在，每当代理服务发生故障时，它都会向所有 12 个节点发送无法到达的邮件。我只想为 zabbix 代理发送邮件，而不是为该代理下的节点发送邮件
更新：现在我正在尝试使用一个触发器，我想检查两个条件，例如 1-检查 zabbix-host 在过去 x 分钟内是否不可访问。2-检查主机是否没有向代理提供任何数据（主机已关闭）。
触发器不应该只在代理正在运行且节点已关闭的情况下才开始发出警报。我尝试了以下方法，但对我不起作用。有人能帮我解决这个问题吗？
({ip-10-4-1-17.ec2.internal:agent.ping.nodata(2m)}=1) & ({ip-10-4-1- 17.ec2.internal:zabbix[proxy,zabbixproxy.dev-test.com,lastaccess].fuzzytime(120)}=1)
答案1
实现此目的的一种方法是监视 Zabbix 代理是否可访问。这是使用zabbix[proxy,<name>,lastaccess]内部项目完成的。在内部项目文件然后它建议使用fuzzytime()触发函数来检查代理的可用性：
{<zabbix>:zabbix[proxy,<name>,lastaccess].fuzzytime(2m)}=0
之后，您可以使“主机不可达”触发器依赖于此触发器，这将阻止它们在代理不可达时被激活（请参阅触发器依赖关系的文档了解更多信息）。
答案2
asaveljevs 的回答很好。关于潜在问题的一些说明。
代理将被检测为缺失，并且依赖项将按预期工作。但让我们假设代理在较长时间内无法访问 - 30 分钟或更长时间。让我们假设它继续收集数据。一旦连接恢复，它会发送值。此时，服务器看到代理可用（内部 lastaccess 项已更新），但代理始终按顺序发送数据（先发送较旧的值）。如果代理收集了大量的值，则需要一些时间来发送最近的值。对于代理后面的主机，您将在其可用性上使用 nodata() 触发器，并且这些触发器将看到数据丢失 - 然后它们就会触发。
从 zabbix 2.2 开始，有一个新的内部项目 - zabbix[proxy_history]。理论上，它可用于监视 zabbix 代理有多少未发送的值，如果该数字很高，则有一个触发器 (t)。然后，所有主机可用性触发器都会依赖于该触发器 (t)，而触发器 (t) 又依赖于 lastaccess 触发器。这样，如果代理突然消失，我们仍然依赖于 lastaccess。如果它回来，我们会注意到大量的历史积压，但仍然不会发出任何警报……除了内部项目受相同的代理队列/较旧的第一规则约束。直到我们获得有关大型代理缓冲区/历史记录的值，我们才会触发有关代理后面的主机的触发器。
那么有解决方案吗？也许吧。
可以从代理数据库中提取有关代理缓冲区的信息。我们的任务是在连接恢复后尽快将其发送到服务器。我们有两个选择：
- 使用直接与服务器对话的代理
zabbix 代理将收集缓冲区/历史记录大小并将其直接推送到服务器，而无需通过代理缓存/缓冲区。如果这是一个被动代理，我们将在停机期间完全丢失缓冲区值，然后我们将依靠项目间隔在连接恢复后获取第一个值。如果这是一个主动代理，我们将能够在停机期间保留一定量的数据（默认为 100 或 50）。不过，发送这些值可能会引入微小的延迟。默认情况下，代理会尝试每 5 秒或更频繁地发送这些值。
- 直接使用 zabbix_sender 到服务器
在这种情况下，我们可以决定是否在停机期间关心值。如果我们不关心，那很简单 - 收集值并将它们推送到服务器，忽略失败。如果我们想尽快获得值 i，我们可能会引入一些逻辑来每 60 秒发送一次值，但如果失败，则每 5 秒左右发送一次。如果我们在停机期间关心值，我们必须实现逻辑来每隔几秒存储这些值。如果发送失败，总是先使用旧值重试，但继续收集值（必须首先发送旧值，以便针对此项的触发器的事件不会全部混乱）。与丢弃值相比，这可能会引入一个微小的延迟来将最新值发送到服务器。
在所有这些情况下，竞争条件的窗口可能非常小，可以通过一些巧妙的触发器技巧来消除（也许通过要求 lastaccess 是最近的，并确保它的最后 3 个值都不同或类似的）。
哦，还有一个潜在的查询来获取代理数据库上的历史记录/缓冲区大小（可能不适用于所有支持的数据库，请根据需要进行调整）：
从 ids 中选择（（从 proxy_history 中选择 max（proxy_history.id）-nextid），其中 field_name='history_lastid'；