zabbix proxy队列数量增长 zabbix队列积压

Zabbix proxy是整个Zabbix架构的主要组件。因此很多时候，当其中一个proxy出现故障，会对所有监控配置造成严重的后果，引起一连串事件与问题。
 

目录

I. 安装
II. 为什么队列递增？

1. 配置错误
2. Proxy连接不到Agent
3. Proxy连接不到Server
4. Proxy发送数据不够快
5. Proxy没有足够的进程
6. Server跟不上数据
7. 有太多未发送数值

本文讲解proxy故障诊断中最常见的例子，让你快速了解出现故障时，应检查哪里。
 

安装

安装（通过安装包安装）
Zabbix 5.01
CentOS 8
Zabbix Proxy与Zabbix Server在同一部设备上
Zabbix Server数据库和Zabbix Proxy数据库在MariaDB数据库引擎上
有三个Zabbix Server Host(已复制)在配置>Hosts
‘training proxy’—是主动（Active）模式的Proxy，没有加密，压缩状态开启—已添加在管理>Proxies

在管理>队列中，队列数值在增加。但根据监控项的数量，没有接收到host上所有监控项的数据。

Queue overview 队列概况

 

在生产实例中，这会导致一些问题。这个情况下，所有没有数据的trigger 不能触发函数，造成许多问题。
 

为什么队列递增？

Zabbix Proxy正在监控 Zabbix agent，监控检查与类型可为被动或主动。主动检查意味着Agent连接Proxy以请求配置，这个配置包含信息说明应该收集什么数据，在host上获得数据并发送给proxy。Agent被动检查则与之相反。Proxy连接Agent，轮询收集的数值。Proxy可以以主动或被动的模式运行，两种都是相同的连接方式。

 

配置错误

如果Proxy出现问题，一定要查看proxy日志。这意味着可能需要SSH连接proxy server。

tail -f /var/log/zabbix/zabbix_proxy.log

‘无法发送proxy数据至server’消息滥发
 

在本地主机IP地址上出现无法发送proxy数据至server的消息，因为未找到“Training proxy”只会在一种情况下出现——当Zabbix proxy配置文件里的主机名称参数无法匹配 Zabbix前端对应的proxy名称。
 

 

当Training proxy正在运行，在前端，在管理 > Proxies，training proxy是小写字母。这导致proxy停止向server发送数据，并在日志中写下错误。

Different proxy name spelling不同的proxy名称拼写
 

所以我们需要修改proxy名称并点击“更新”。

Updating the proxy name 更新proxy名称
 

然后，为了节省时间，可以在Zabbix Server上强制重新加载配置缓存，执行如下命令：

zabbix_server -R config_cache_reload

还要检查proxy日志。你会发现消息已经停止滥发，Server默认每分钟自动更新其配置缓存。

 

在 管理 > 队列里，没有延迟的数值，所有数据都能正常被处理。

 

Proxy queue overview Proxy队列概况
 

所以，出现配置错误的情况下，你需要：
a) 检查proxy日志，多数情况足够解决问题
b) 遇到特殊情况，要检查server日志
 

Proxy连接不到Agent

如果proxy不能从agent处获取数据，并不是proxy-server通信或server自身出现问题。需要检查proxy和agent的日志文件，看看是否有问题信息提示。

首先，需检查proxy。最可能的情况，在日志中出现‘网络错误’、‘host不可用’、‘连接超时’、‘TCP连接问题’或其他类似错误信息。如果出现如下错误信息，如连接失败，无法连接agent 1，但其他正常运行，那么问题很可能与网络有关。可能是网络发生变化阻止proxy从agent处收集数据。可以用agent的IP从proxy上运行zabbix_get，尝试对其进行故障诊断，或简单测试连通性。

 
如果没有问题，agent需要日志报告返回正常。如果agent日志返回正常，但在前端仍看不到任何数据，那可能是出现别的问题。例如，proxy负责这种监控类型没有足够的进程。

Agent可能只是停止、死机或被删除，这种情况下，在运行 zabbix_get时能看到错误信息。

 

 

如果收到这个错误消息，表明proxy收不到数值，那么可能是在proxy与agent间的某处连接或agent自身出现问题。这种情况下，需要检查正在监控的host——agent是否运行，或监听端口，或是否有防火墙规则阻断proxy与agent的连接。可能只是agent配置上的Server=IP地址不同于Proxy的IP地址。
 

所以，如果proxy连接不到agent，需要：
a) 检查proxy日志
b) 检查agent日志
c) 隔离无法运行的agent。如果所有agent都无法运行，那就是网络的问题
d) 运用zabbix_get或snmpget (snmp problems) 测试proxy与host间的连通性
 

Proxy连接不到Server

当proxy连接不到server，在server日志里查看不到任何东西，因为连接中断，server将收不到任何数据。可以通过检查proxy日志，查看错误信息，例如‘无法连接到server’或‘无法发送proxy数据到server’。

如果proxy连接不到server，需要：
a) 检查proxy日志
 

Proxy发送数据不够快

如果proxy上出现队列，但有数据正在传输，表明proxy能够连接到server和agent，因为可以接收和发送数据，尽管也会出现延迟的情况。延迟表明proxy跟不上数据流，proxy上数据堆积的速度比发送的速度快。在最新数据处可以查看这个问题，图表中出现间断和点。
 

检查这个问题，可以在Zabbix proxy host上执行命令
ps ax | grep sender
 

只有一个进程——Zabbix proxy上的data sender，它不在server上，是负责发送数据到server的唯一进程。如果对sender到底做了什么感兴趣，可以反复执行上面的命令，相关日志的变化会告诉我们答案。

存在问题时，查看每秒发送多少数值是不够的。data sender的迭代需要几百秒甚至更多。这种情况下，可以通过数据库并运行查询语句：

select max(id)-(select nextid from ids where table_name + "proxy_history" limit l) from proxy_history;

这个查询会告诉我们proxy数据库上剩下多少数值还没发到Zabbix server。基本上，这是proxy上的backlog队列。

在上面的例子，一切运行正常，队列也没有堆积。

如果能观察到，data sender要花几百秒的时间发送数值给server，最可能出现的查询结果不会是零。多次运行查询会显示proxy上的backlog不断增加。

造成这些问题的原因很多，其中一个是Zabbix proxy与server之间的网络连接慢。这种情况下，通常ping值不足以反映网络状况的好坏。如果所有进程都不繁忙，但是data sender 难以发送数据，那可能需要咨询网络团队。可能是Zabbix server出现问题。data sender 是一个单进程，发送数据到server，但在server上，只有trapper负责接收数据。所以要确保server上有足够的trapper，且不是全部都处于繁忙状态。

所以，如果Proxy发送数据不够快，需要：
a) 检查data sender
b) 检查proxy数据库上的队列
c) 检查网络连接速度
 

Proxy没有足够的进程

假设，有一个Zabbix server正常运行，Zabbix前端以及大部分环境都通过Zabbix server进行监控。

在管理 > Proxies里，看到Training proxy只添加了三个host。

这三个host正接收数据，没有丢失的队列和数据。假设，一个月内需要在proxy上部署网络发现或agent主动注册，并添加更多host进行监控。最终可能大约有30000个host，这时会出现问题：proxy上的间断或队列正在增加。

如果检查server日志，可能没发现什么错误——没有问题、没有查询慢。还可以在监控> Hosts查看，例如会显示‘内部进程繁忙’的图表。

那么问题可能在proxy上。因为添加了30000个新的host，proxy上的进程数量可能不足以让proxy处理当前数据。

proxy上的运行进程
 

部署了30000个host之后，之前的进程数量不够支撑当前设置。这个问题不会显示在server日志或server图表。这种情况下，需要监控proxy。在配置 > Hosts处创建一个host，添加到组别，指明这个host由proxy监控，还有proxy自身，点击添加。

添加host

 

注意 用户通常指定agent接口为proxy的外部地址，这并不是完全正确的。

使用在配置 > 模板里的模板Template App Zabbix Proxy监控proxy。这个proxy有内部监控项，这个监控项不使用Zabbix agent接口指定的IP地址。

Proxy上的内部监控项
 

如果在 配置 > Hosts里，不配置这个host由proxy监控，那么在性能图表上还会看到数据，但是这些数据是来自Zabbix server，你可能会被监控 > Hosts里的图表、数据收集器进程和内部进程误导。所以，会看到来自server的数据，显示并不繁忙，但是proxy出现问题。这种情况下，你只需要增加更多进程，例如poller、trapper等。

如果Proxy没有足够的进程，需要确保正确监控proxy，并检查proxy的性能图表：
a) 数据收集进程繁忙
b) 内部进程繁忙，以及
c) 自由缓存的百分比
 

Server跟不上数据

如果数据通过proxy无缝地从agent开始传输，传输到server，那么在server上可能出现问题。可以在server日志上发现这个问题，可能会看到一些查询慢或超时。更重要的是，在监控 > Hosts的性能图表里也能看到相同的信息。

例如这里，需要检查‘数据收集进程繁忙’。

性能图表的‘数据收集进程繁忙’
 

更具体一点，我们所感兴趣的trapper，只是在主动模式的proxy上操作的trapper，正如这个例子提到的那样。

所以如果trapper完全繁忙，可能唯一需要做的是增加trapper的数量。

如果trapper繁忙，但在‘Zabbix内部进程繁忙%’的图表中，housekeeper和history sinker以及大部分图表都加载运行100%，在图表中有一些点和间断，这表明Zabbix server上有严重的性能问题。99%的情况下，这是因为数据库性能问题和Zabbix设置问题。

所以如果Server跟不上数据，需要：
a) 检查server日志
b) 检查server性能图表
c) 检查日志里的查询慢，如果在历史图表发现插入数据的查询慢，那就是数据库跟不上。
 

有太多未发送数值

有时，上述的任何一个问题都会导致proxy收集backlog，在问题修复之后队列不下降或下降很慢时。这种情况下，可以运行查询，检查proxy数据库上的backlog。

例如，当看到百万个数值，proxy在某些时段停止运行，在数据库有巨大的backlog，队列仍在堆积。这种情况下，唯一能做到是降低backlog——删除所有储存在proxy数据库的数据，重新开始。虽然会丢失这个时间段里未发送的数据历史，但至少能重新回到监控。

需要：

1. 停止运行Zabbix proxy

systemctl stop zabbix-proxy

2. 打开数据库

mysql

3. Tuncate两个图表——proxy历史查询和IDs

truncate proxy_history；
truncate ids;

代码片段：可切换语言，无法单独设置文字格式

4. 退出数据库，打开Zabbix proxy

systemctl start zabbix-prox

降低proxy backlog

5. 重启

zabbix_server -R config_cache_reload

6. 打开数据库

mysql

7. 使用Zabbix proxy

use zabbix-proxy;

这样在查询中，看不到backlog了

 

Proxy backlog已下降
 
注意不要忘记truncate IDs图表。如果只truncate proxy历史图表，无法解决问题。

如果有太多未发送数值，且proxy队列正在堆积，则需要降低backlog。