博文|如何对Zabbix Proxy高队列进行故障诊断
感谢本文译者赵静—宏时数据技术工程师!
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。
- 点赞
- 收藏
- 关注作者
评论(0)