感谢本文译者赵静—宏时数据技术工程师！
Zabbix proxy是整个Zabbix架构的主要组件。因此很多时候，当其中一个proxy出现故障，会对所有监控配置造成严重的后果，引起一连串事件与问题。
目录
I. 安装 II. 为什么队列递增？
- 配置错误
- Proxy连接不到Agent
- Proxy连接不到Server
- Proxy发送数据不够快
- Proxy没有足够的进程
- Server跟不上数据
- 有太多未发送数值
本文讲解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数据库的数据，重新开始。虽然会丢失这个时间段里未发送的数据历史，但至少能重新回到监控。
需要：
- 停止运行Zabbix proxy
systemctl stop zabbix-proxy
- 打开数据库
mysql
- Tuncate两个图表——proxy历史查询和IDs
truncate proxy_history；
truncate ids;
代码片段：可切换语言，无法单独设置文字格式
- 退出数据库，打开Zabbix proxy
systemctl start zabbix-prox
降低proxy backlog
- 重启
zabbix_server -R config_cache_reload
- 打开数据库
mysql
- 使用Zabbix proxy
use zabbix-proxy;
这样在查询中，看不到backlog了
Proxy backlog已下降 注意不要忘记truncate IDs图表。如果只truncate proxy历史图表，无法解决问题。
如果有太多未发送数值，且proxy队列正在堆积，则需要降低backlog。
