1. 从被动轮询到主动上报Zabbix数据收集的两种哲学很多人搭Zabbix第一步就是照着文档把Agent装上模板一挂看到绿色图标亮起来就觉得万事大吉。但真到了生产环境尤其是设备数量上去之后你会发现数据要么延迟得厉害要么干脆断流监控面板上大片大片的灰色。这时候再去翻手册才发现数据收集方式的选择从一开始就决定了后面运维的舒适度。Zabbix的数据收集本质上就两条路被动模式Passive和主动模式Active。被动模式是Server端发起连接挨个去问Agent“你那边现在什么情况”主动模式则是Agent自己攒好数据主动推给Server。这两种模式没有绝对的好坏但在不同规模、不同网络环境下表现差异巨大。我见过不少团队几百台机器全用被动模式Server端轮询队列排得老长采集间隔被迫从60秒拉到300秒结果故障发生时告警慢半拍。也见过有人一刀切全改主动结果因为防火墙策略没跟上Agent推数据推不出去监控直接瘫痪。所以这一章的核心不是教你“怎么配”而是帮你搞清楚“什么场景该选什么”。1.1 被动模式的工作链路与瓶颈点被动模式的流程很直观Zabbix Server或者Proxy根据监控项配置的更新间隔定时向Agent的10050端口发起TCP连接发送一个类似system.cpu.load[all,avg1]的key请求Agent收到后执行对应的采集逻辑把结果返回给Server。Server拿到数据后再走预处理、触发器计算、入库这一整套流程。这个链路里Server是绝对的瓶颈。因为每一个监控项的每一次采集都需要Server主动发起一次连接。假设你有500台主机每台主机上有100个监控项更新间隔都是60秒那么Server每分钟需要发起的连接请求就是500×10050000次。这还没算上网络往返的延迟和Agent端的处理时间。实际测试中一台配置中等的Zabbix Server在被动模式下能稳定支撑的监控项采集频率大概在每秒300到500次左右再往上就会出现明显的队列积压。更麻烦的是被动模式对网络质量的敏感度极高。如果Server和Agent之间隔着防火墙或者跨了机房每一次连接建立都要经历TCP三次握手一旦网络抖动采集超时就会频繁发生。Zabbix的默认超时时间是3秒超过这个时间没拿到数据这次采集就算失败面板上就会出现断点。注意被动模式下Agent的StartAgents参数决定了它能同时处理多少个被动请求。默认值是3意味着同一时刻最多只能响应3个Server的连接。如果Server并发请求数超过这个值多出来的请求就会排队等待进一步加剧延迟。1.2 主动模式如何把压力从Server转移到Agent主动模式的逻辑正好反过来Agent端根据Server下发的监控项列表自己维护一个采集队列按照配置的更新间隔定时执行采集然后把一批数据打包通过10051端口推送给Server。Server端只需要被动接收然后处理入库。这个转变带来的好处是立竿见影的。首先Server不再需要维护大量的出站连接CPU和内存的消耗大幅下降。其次Agent可以批量发送数据减少了网络交互的次数。比如100个监控项被动模式需要100次请求-响应主动模式可能只需要1次批量推送。再者主动模式天然适合跨网络域的场景因为Agent是主动往外推只要它能访问到Server的10051端口就行不需要Server能反向访问Agent。但主动模式也不是没有代价。最大的问题是实时性控制变弱了。被动模式下Server想什么时候采集就什么时候采集主动权在自己手里。主动模式下Agent什么时候推数据取决于它自己的调度周期。如果Agent负载很高采集线程被阻塞数据推送就会延迟。而且主动模式下Server无法主动向Agent索取某个特定监控项的即时值所有数据都是Agent“给什么算什么”。还有一个容易被忽略的细节主动模式下Agent需要先从Server获取一次监控项配置列表。这个获取动作是通过active checks请求完成的Agent会定期向Server的10051端口发送一个包含自己hostname的请求Server返回该主机对应的所有主动型监控项。如果hostname配置错了或者Server端没有对应的主机记录Agent就拉不到配置自然也就不会推送任何数据。1.3 混合部署不是非此即彼的选择题实际生产环境中纯被动或纯主动都很少见大多数时候是混合使用。我的经验是核心指标用被动海量指标用主动。什么叫核心指标比如主机的存活状态、关键业务进程的端口监听状态、核心服务的响应时间。这些指标数量不多但对实时性要求极高需要Server能够精确控制采集节奏甚至需要在故障时立即触发重试。这类指标适合被动模式由Server牢牢把控。什么叫海量指标比如CPU的各个核心使用率、磁盘每个分区的inode使用率、网卡每个队列的丢包统计。这些指标数量庞大但实时性要求相对宽松晚个十几秒甚至一分钟都能接受。这类指标就适合主动模式让Agent自己批量采集、批量推送Server只负责接收和存储。在Zabbix的配置层面这种混合模式是通过监控项类型来区分的。创建监控项时类型选择Zabbix agent就是被动模式选择Zabbix agent (active)就是主动模式。同一个主机上两种类型的监控项可以共存互不干扰。2. 主动模式配置的暗坑从hostname到BufferSize主动模式的配置看起来简单无非就是在Agent端把ServerActive指向Server的IP然后在Server端把监控项类型改成主动。但真正踩过坑的人都知道这里面有几个参数一旦配错排查起来能让人怀疑人生。2.1 hostname一致性主动模式的命门主动模式下Agent向Server拉取配置时发送的请求里只带了一个hostname。Server拿到这个hostname去数据库里查对应的主机记录然后把该主机的所有主动型监控项返回给Agent。如果hostname对不上Server就找不到主机返回空列表Agent自然什么也不采集。这个hostname来自哪里来自Agent配置文件里的Hostname参数。如果这个参数没显式配置Agent会调用系统的主机名hostname命令的输出作为默认值。问题就出在这里很多人在Server端添加主机时用的名字是“Web-Server-01”这种自定义名称但Agent所在机器的系统主机名可能是“localhost”或者一串无意义的字符串。两边对不上主动模式就废了。更隐蔽的情况是大小写敏感。Zabbix的hostname匹配是区分大小写的“Web-Server-01”和“web-server-01”在Server看来是两个完全不同的主机。我遇到过好几次同事在Server端建主机时手抖打了个大写字母Agent端配置的是全小写结果排查了半天才发现是大小写的问题。实操建议在Agent的配置文件中显式设置Hostname参数并且确保它和Server端的主机名完全一致包括大小写。如果主机数量多建议用配置管理工具统一生成Agent配置文件避免手工输入出错。2.2 ServerActive的地址解析与多Server配置ServerActive参数告诉Agent把主动数据推送到哪个地址。这个参数可以填IP也可以填域名还可以填多个地址用逗号分隔。但这里有个细节如果填的是域名Agent在启动时会解析一次然后把解析结果缓存起来。如果后续DNS记录变了Agent不会自动重新解析除非重启Agent进程。多Server配置的场景通常出现在Proxy架构中。比如一个Agent需要同时向两个Proxy推送数据可以在ServerActive里写两个地址。但要注意Agent会轮流尝试这些地址如果第一个地址不可达它会尝试第二个但不会自动切回第一个除非Agent重启或者配置重载。还有一个坑是端口。ServerActive的默认端口是10051如果Server端改了监听端口Agent这边必须显式指定格式是IP:端口。很多人只写了IP忘了端口结果Agent一直往10051推Server却在10052上监听数据全丢了。2.3 BufferSize与数据积压的权衡主动模式下Agent采集到的数据不会立即发送而是先写到一个内存缓冲区里等缓冲区满了或者到了发送周期再批量推送给Server。这个缓冲区的大小由BufferSize参数控制默认是100。BufferSize设小了Agent会频繁发送数据网络交互次数多但数据延迟低。设大了批量发送的效率高但一旦Agent崩溃或者网络中断缓冲区里未发送的数据就会丢失。而且如果Server端处理速度跟不上Agent的缓冲区会一直满着新的采集数据写不进去就会触发BufferSend的等待逻辑导致采集延迟。我的经验值是对于监控项数量在100以内的主机BufferSize保持默认的100就行。对于监控项数量在500以上的主机可以适当调到300到500。但不要超过1000否则单次发送的数据包太大容易触发网络层的分片反而降低传输效率。另外BufferSend参数控制的是发送周期默认是5秒。意思是即使缓冲区没满每隔5秒也会强制发送一次。这个值可以根据网络状况调整网络好的话可以调到10秒减少发送频率网络差的话可以调到2秒降低单次发送的数据量。3. 被动模式的超时与并发那些让你半夜起床的告警被动模式虽然逻辑简单但坑一点也不少。尤其是当监控规模上去之后超时和并发问题会像幽灵一样缠着你。3.1 Timeout参数的全局影响Zabbix Server的配置文件里有一个Timeout参数默认是3秒。这个参数控制的是Server等待Agent响应的最长时间。如果Agent在3秒内没返回数据Server就认为这次采集失败记录一个超时错误。3秒听起来不短但在某些场景下真的不够。比如Agent所在主机负载很高CPU被占满Agent进程调度不上去响应自然就慢。又比如采集的key本身执行时间就长像vfs.dir.size这种统计目录大小的监控项在大目录上跑个五六秒很正常。这时候3秒的超时就会导致大量采集失败。把Timeout调大能解决问题但会带来副作用。因为Server是串行处理采集请求的在单个pollers进程内一个请求超时3秒意味着这个poller进程在这3秒内什么都干不了。如果超时调到10秒一个卡住的请求就会阻塞poller 10秒整体采集吞吐量直线下降。所以Timeout的调整需要配合StartPollers参数一起考虑。StartPollers控制的是Server端负责被动采集的进程数量默认是5。如果超时时间调大了就要相应增加StartPollers用更多的并发进程来弥补单个进程的阻塞。3.2 StartAgents与Agent端的并发上限Server端有StartPollersAgent端对应的就是StartAgents。这个参数决定了Agent能同时处理多少个被动请求默认是3。当Server的StartPollers大于Agent的StartAgents时多出来的请求就会在Agent端排队。Zabbix Agent处理请求是单线程轮询的在StartAgents大于1时会fork出多个子进程每个子进程处理一个请求如果请求排队时间过长Server端就会超时。我遇到过最典型的情况是Server端StartPollers设了20Agent端StartAgents还是默认的3。结果Server同时发起20个请求Agent只能同时处理3个剩下17个在排队。排在前面的请求很快处理完排在后面的请求等轮到它时Server早就超时了。表现就是监控数据时有时无断点毫无规律。调整原则Agent端的StartAgents应该大于等于Server端的StartPollers除以该Server监控的主机数量。但StartAgents也不是越大越好每个子进程都会消耗内存和CPU一般建议不超过10。3.3 被动模式下的网络中断重试逻辑被动模式还有一个让人头疼的问题网络中断后的重试。当Server向Agent发起连接失败时比如网络不通、Agent进程挂了Zabbix不会立即重试而是等到下一个采集周期再试。这意味着如果采集间隔是60秒网络中断了1秒但恰好发生在采集的那一瞬间那么这次采集就失败了要等60秒后才会再次尝试。对于核心监控项60秒的数据缺失可能就意味着60秒的监控盲区。解决办法是缩短采集间隔比如改成30秒甚至10秒。但缩短间隔又会加重Server的负担形成恶性循环。一个折中的方案是对核心监控项使用被动模式但把采集间隔设短比如15秒同时配合Zabbix的nodata触发器一旦超过一定时间没收到数据就告警。这样即使采集失败也能快速感知到。4. 数据采集的预处理在入库前把脏数据拦下来数据从Agent采集回来到最终写入数据库中间还有一个预处理阶段。这个阶段在Zabbix 4.0里得到了极大的增强支持正则替换、JSON解析、自定义脚本等多种处理方式。很多人忽略了预处理的价值把所有原始数据一股脑塞进数据库结果数据库膨胀得飞快查询也越来越慢。4.1 预处理链的执行顺序与短路逻辑Zabbix的预处理是按顺序执行的前一个步骤的输出作为后一个步骤的输入。如果某一步执行失败整个预处理链就会中断这个数据点会被丢弃或者标记为不支持。这个特性可以用来做数据过滤。比如你采集了一个JSON格式的返回值里面包含了多个字段但只有其中一个字段是你需要的。你可以先用JSONPath提取出目标字段再用正则表达式做一次格式校验最后用自定义倍数做单位转换。如果JSONPath提取失败比如返回的不是合法JSON后面的步骤就不会执行数据直接被丢弃不会污染数据库。但要注意预处理链的每一步都会消耗CPU。如果监控项数量很大预处理逻辑又很复杂Server端的CPU会成为新的瓶颈。我的建议是能在Agent端做的预处理就不要放到Server端。比如单位转换、简单的正则替换完全可以在Agent的自定义UserParameter里用脚本搞定Server端只负责接收最终结果。4.2 用预处理解决浮点数精度问题Zabbix采集回来的数据很多时候是浮点数。比如CPU负载、内存使用率、磁盘IO等待时间。这些浮点数在入库时Zabbix默认会保留到小数点后四位。但有些场景下四位小数太多了不仅浪费存储空间还会让趋势图看起来毛刺很多。这时候可以用预处理里的自定义倍数功能。比如把采集到的浮点数乘以100然后取整就变成了一个整数百分比。这样存储空间节省了趋势图也平滑了。但要注意乘以100之后触发器的阈值也要相应调整否则会出现误告警。另一个常见的精度问题是科学计数法。有些Agent返回的值是1.23e-5这种格式Zabbix在解析时可能会出错。这时候可以用预处理里的正则表达式把科学计数法转换成普通小数。具体做法是匹配(\d\.\d)e-(\d)然后替换成对应的十进制形式。4.3 预处理与触发器的联动避免误告警预处理不仅影响存储还直接影响触发器的计算。如果预处理把数据改了触发器却还在用原始值的逻辑来判断就会出问题。举个例子你采集的是磁盘剩余空间单位是字节。原始值很大比如107374182400100GB。你在预处理里把它除以1073741824转换成GB变成100。然后触发器里写last(/host/vfs.fs.size[/,free])10意思是剩余空间小于10GB就告警。这个逻辑是对的因为预处理已经把单位转成GB了。但如果你在预处理里做了四舍五入把10.4变成了10触发器里写的是10那么10.4GB的实际剩余空间就不会触发告警因为预处理后变成了10不满足小于10的条件。这种精度丢失导致的漏告警排查起来非常隐蔽。经验预处理里的取整操作要慎重尤其是当触发器阈值是边界值时。要么保留足够的小数位要么把触发器阈值也做相应的调整。5. 采集频率的博弈实时性与系统负载的平衡采集频率是Zabbix运维中最难拿捏的参数之一。设短了Server和Agent都扛不住设长了故障发现不及时。而且不同类型的监控项对频率的敏感度完全不同。5.1 不同监控项类型的推荐采集间隔我把常见的监控项分成三类分别给出推荐的采集间隔监控项类型典型代表推荐间隔理由状态类主机存活、端口监听、进程状态30-60秒需要快速感知故障但变化不频繁性能类CPU使用率、内存使用率、磁盘IO60-120秒变化较快但短时间波动不影响判断容量类磁盘空间、inode使用率、日志大小300-600秒变化缓慢高频采集没有意义这个表格只是参考实际调整时还要考虑主机的角色。比如数据库服务器的性能类指标采集间隔可以缩短到30秒因为数据库的负载波动对业务影响很大。而文件服务器的容量类指标采集间隔可以放宽到1800秒因为磁盘不会瞬间写满。5.2 用自定义间隔应对特殊场景Zabbix支持为单个监控项设置自定义的采集间隔格式是flexible可以指定时间段和对应的间隔。这个功能在应对特殊场景时非常有用。比如某台服务器每天凌晨2点到4点会跑批处理任务这段时间CPU和内存的负载会飙升。如果采集间隔还是默认的60秒可能会错过负载峰值。这时候可以设置一个灵活间隔在2:00-4:00之间采集间隔改为10秒其他时间保持60秒。这样既保证了关键时段的监控精度又不会在平时浪费资源。配置方法是在监控项的Update interval里选择Flexible然后添加时间段和间隔。注意时间段的格式是HH:MM-HH:MM间隔单位是秒。5.3 采集间隔与触发器评估周期的关系很多人不知道的是触发器的评估周期和监控项的采集间隔是独立的。监控项每60秒采集一次但触发器可能每30秒就评估一次。这意味着触发器可能会用同一个数据点评估两次或者在一个采集周期内评估多次。这本身不是问题但如果你在触发器里用了change函数判断值是否变化就会出现误判。因为同一个值被评估两次change函数会认为值没有变化但实际上只是采集间隔还没到。解决办法是让触发器的评估周期和监控项的采集间隔保持一致或者用nodata函数来检测数据缺失而不是依赖change函数。6. 从Proxy到Agent分布式采集的链路优化当监控规模扩展到多个机房、多个网络域时单靠一个Server很难覆盖所有Agent。这时候就需要引入Proxy把采集压力分散到离Agent更近的地方。6.1 Proxy的主动与被动模式选择Proxy本身也有主动和被动两种模式。被动模式下Server主动向Proxy索取数据主动模式下Proxy自己把数据推给Server。和Agent的选择逻辑类似如果Proxy和Server之间的网络质量好但Server的负载已经很高那就用主动模式让Proxy自己推数据减轻Server的负担。如果Proxy和Server之间的网络不稳定或者Server需要精确控制数据收集的节奏那就用被动模式。但Proxy的主动模式有一个额外的坑Proxy需要先从Server获取配置包括主机列表、监控项、触发器然后才能开始采集。这个配置同步是周期性的默认是60秒一次。如果Server端刚添加了一台主机Proxy可能需要等60秒才能感知到然后才开始采集。这个延迟在故障排查时容易被忽略。6.2 Proxy下的数据缓冲与断点续传Proxy的一个核心价值是数据缓冲。当Proxy和Server之间的网络中断时Proxy会把采集到的数据先存在本地等网络恢复后再批量上传。这个缓冲能力由ProxyLocalBuffer和ProxyOfflineBuffer两个参数控制。ProxyLocalBuffer控制的是本地保留数据的时间默认是1小时。ProxyOfflineBuffer控制的是离线状态下保留数据的时间默认也是1小时。如果网络中断超过1小时超出部分的数据就会丢失。对于网络不稳定的环境可以把这两个参数调大比如调到24小时甚至72小时。但要注意Proxy本地的存储空间是有限的如果数据量太大可能会把磁盘写满。所以调大缓冲时间的同时也要监控Proxy的磁盘使用率。6.3 Agent端的数据压缩与传输优化在Agent和Proxy或Server之间传输数据时Zabbix默认是不压缩的。如果监控项很多每次传输的数据量可能达到几百KB甚至几MB。在带宽紧张的环境下这会成为瓶颈。Zabbix 4.0支持在Agent端开启数据压缩通过EnablePersistentBuffer和BufferSize的配合可以减少传输的数据量。但压缩本身也会消耗CPU所以要在带宽和CPU之间做权衡。我的经验是如果Agent和Server之间的带宽低于10Mbps或者监控项数量超过500就值得开启压缩。如果带宽充足CPU又比较紧张那就保持默认的不压缩。7. 采集数据的验证与排错从日志到实际值配置完采集最怕的就是“看起来正常实际上没数据”。Zabbix的面板有时候会骗人绿色图标不代表数据真的在更新。这一节分享几个我常用的验证和排错方法。7.1 用zabbix_get手动验证被动采集被动模式下最直接的验证方法是在Server上手动执行zabbix_get命令模拟Server向Agent发起一次采集请求。命令格式是zabbix_get -s Agent_IP -p 10050 -k system.cpu.load[all,avg1]如果返回了具体的数值说明Agent的被动采集是通的。如果返回ZBX_NOTSUPPORTED说明key不支持或者参数不对。如果连接超时说明网络不通或者Agent没监听10050端口。这个命令的好处是绕过了Zabbix Server的调度逻辑直接测试Agent的响应能力。排查被动模式问题时这是第一步。7.2 主动模式的日志追踪主动模式没有zabbix_get这样的工具只能看日志。Agent的日志里会记录它向Server拉取配置的过程以及推送数据的结果。关键日志行包括active check configuration update from [Server:10051] started to fail说明Agent连不上Server的10051端口。no active checks on server [Server:10051]: host [hostname] not found说明Server端没有找到对应的hostname需要检查主机名配置。sending data to server [Server:10051]说明Agent正在推送数据如果这条日志频繁出现但Server端没收到可能是网络问题。把Agent的DebugLevel调到4可以看到更详细的推送日志包括每次推送了多少个值、Server返回了什么响应。7.3 数据库层面的数据验证如果Agent和Server的日志都正常但面板上就是没数据那问题可能出在数据库层面。可以直接查Zabbix的history表看看对应的监控项有没有数据写入。SELECT * FROM history WHERE itemid itemid ORDER BY clock DESC LIMIT 10;如果history表里有数据但面板上不显示那可能是前端缓存或者权限问题。如果history表里没数据但Agent日志显示推送成功那可能是Server端的预处理或者触发器把数据丢弃了。查history表的时候要注意Zabbix 4.0默认把历史数据按数值类型分表存储history存浮点数history_uint存无符号整数history_str存字符串。查的时候要根据监控项的类型选对表。8. 采集性能的调优实战从参数到架构最后聊一下采集性能的调优。Zabbix的性能问题十有八九出在采集环节。调优的思路不是盲目加大参数而是先找到瓶颈点再针对性地调整。8.1 用Zabbix自带的内部监控项定位瓶颈Zabbix Server自身也提供了一组内部监控项可以用来监控Server的运行状态。关键的有zabbix[queue]当前等待处理的队列长度。如果这个值持续大于0说明Server处理不过来。zabbix[wcache,values]写入缓存的值数量。如果这个值增长很快说明采集频率太高。zabbix[process,poller,avg,busy]poller进程的平均繁忙度。如果接近100%说明poller不够用。把这些内部监控项加到Zabbix里设置合理的触发器就能在性能问题恶化之前收到告警。8.2 StartPollers与StartTrappers的配比StartPollers负责被动采集StartTrappers负责主动采集和Proxy数据接收。这两个参数的配比取决于你的采集模式分布。如果被动模式占主导StartPollers就要设大一些比如20到30。如果主动模式占主导StartTrappers就要设大一些。但要注意每个进程都会消耗内存进程数太多会导致Server内存不足。一般来说StartPollers和StartTrappers的总和不要超过CPU核心数的4倍。8.3 数据库写入优化从Housekeeper到分区表采集到的数据最终要写入数据库。如果数据库写入跟不上采集再快也没用。Zabbix 4.0默认用Housekeeper来清理过期数据但Housekeeper的删除操作很重容易造成数据库锁等待。更好的方案是用数据库分区表按时间分区过期数据直接drop分区比delete快得多。但分区表需要手动配置而且Zabbix的前端对分区表的支持有限需要额外注意。另一个优化点是HistoryStorageDateIndex参数。开启后Zabbix会为历史数据建立日期索引加快查询速度。但索引本身也会占用空间所以要在查询性能和存储空间之间做权衡。调优这件事没有一劳永逸的方案。监控规模在变业务需求在变参数也要跟着变。我自己的做法是每季度做一次性能回顾看看队列长度、进程繁忙度、数据库写入延迟这些指标的趋势然后微调参数。监控系统本身也需要被监控这才是运维的常态。
1. 从被动轮询到主动上报Zabbix数据收集的两种哲学很多人搭Zabbix第一步就是照着文档把Agent装上模板一挂看到绿色图标亮起来就觉得万事大吉。但真到了生产环境尤其是设备数量上去之后你会发现数据要么延迟得厉害要么干脆断流监控面板上大片大片的灰色。这时候再去翻手册才发现数据收集方式的选择从一开始就决定了后面运维的舒适度。Zabbix的数据收集本质上就两条路被动模式Passive和主动模式Active。被动模式是Server端发起连接挨个去问Agent“你那边现在什么情况”主动模式则是Agent自己攒好数据主动推给Server。这两种模式没有绝对的好坏但在不同规模、不同网络环境下表现差异巨大。我见过不少团队几百台机器全用被动模式Server端轮询队列排得老长采集间隔被迫从60秒拉到300秒结果故障发生时告警慢半拍。也见过有人一刀切全改主动结果因为防火墙策略没跟上Agent推数据推不出去监控直接瘫痪。所以这一章的核心不是教你“怎么配”而是帮你搞清楚“什么场景该选什么”。1.1 被动模式的工作链路与瓶颈点被动模式的流程很直观Zabbix Server或者Proxy根据监控项配置的更新间隔定时向Agent的10050端口发起TCP连接发送一个类似system.cpu.load[all,avg1]的key请求Agent收到后执行对应的采集逻辑把结果返回给Server。Server拿到数据后再走预处理、触发器计算、入库这一整套流程。这个链路里Server是绝对的瓶颈。因为每一个监控项的每一次采集都需要Server主动发起一次连接。假设你有500台主机每台主机上有100个监控项更新间隔都是60秒那么Server每分钟需要发起的连接请求就是500×10050000次。这还没算上网络往返的延迟和Agent端的处理时间。实际测试中一台配置中等的Zabbix Server在被动模式下能稳定支撑的监控项采集频率大概在每秒300到500次左右再往上就会出现明显的队列积压。更麻烦的是被动模式对网络质量的敏感度极高。如果Server和Agent之间隔着防火墙或者跨了机房每一次连接建立都要经历TCP三次握手一旦网络抖动采集超时就会频繁发生。Zabbix的默认超时时间是3秒超过这个时间没拿到数据这次采集就算失败面板上就会出现断点。注意被动模式下Agent的StartAgents参数决定了它能同时处理多少个被动请求。默认值是3意味着同一时刻最多只能响应3个Server的连接。如果Server并发请求数超过这个值多出来的请求就会排队等待进一步加剧延迟。1.2 主动模式如何把压力从Server转移到Agent主动模式的逻辑正好反过来Agent端根据Server下发的监控项列表自己维护一个采集队列按照配置的更新间隔定时执行采集然后把一批数据打包通过10051端口推送给Server。Server端只需要被动接收然后处理入库。这个转变带来的好处是立竿见影的。首先Server不再需要维护大量的出站连接CPU和内存的消耗大幅下降。其次Agent可以批量发送数据减少了网络交互的次数。比如100个监控项被动模式需要100次请求-响应主动模式可能只需要1次批量推送。再者主动模式天然适合跨网络域的场景因为Agent是主动往外推只要它能访问到Server的10051端口就行不需要Server能反向访问Agent。但主动模式也不是没有代价。最大的问题是实时性控制变弱了。被动模式下Server想什么时候采集就什么时候采集主动权在自己手里。主动模式下Agent什么时候推数据取决于它自己的调度周期。如果Agent负载很高采集线程被阻塞数据推送就会延迟。而且主动模式下Server无法主动向Agent索取某个特定监控项的即时值所有数据都是Agent“给什么算什么”。还有一个容易被忽略的细节主动模式下Agent需要先从Server获取一次监控项配置列表。这个获取动作是通过active checks请求完成的Agent会定期向Server的10051端口发送一个包含自己hostname的请求Server返回该主机对应的所有主动型监控项。如果hostname配置错了或者Server端没有对应的主机记录Agent就拉不到配置自然也就不会推送任何数据。1.3 混合部署不是非此即彼的选择题实际生产环境中纯被动或纯主动都很少见大多数时候是混合使用。我的经验是核心指标用被动海量指标用主动。什么叫核心指标比如主机的存活状态、关键业务进程的端口监听状态、核心服务的响应时间。这些指标数量不多但对实时性要求极高需要Server能够精确控制采集节奏甚至需要在故障时立即触发重试。这类指标适合被动模式由Server牢牢把控。什么叫海量指标比如CPU的各个核心使用率、磁盘每个分区的inode使用率、网卡每个队列的丢包统计。这些指标数量庞大但实时性要求相对宽松晚个十几秒甚至一分钟都能接受。这类指标就适合主动模式让Agent自己批量采集、批量推送Server只负责接收和存储。在Zabbix的配置层面这种混合模式是通过监控项类型来区分的。创建监控项时类型选择Zabbix agent就是被动模式选择Zabbix agent (active)就是主动模式。同一个主机上两种类型的监控项可以共存互不干扰。2. 主动模式配置的暗坑从hostname到BufferSize主动模式的配置看起来简单无非就是在Agent端把ServerActive指向Server的IP然后在Server端把监控项类型改成主动。但真正踩过坑的人都知道这里面有几个参数一旦配错排查起来能让人怀疑人生。2.1 hostname一致性主动模式的命门主动模式下Agent向Server拉取配置时发送的请求里只带了一个hostname。Server拿到这个hostname去数据库里查对应的主机记录然后把该主机的所有主动型监控项返回给Agent。如果hostname对不上Server就找不到主机返回空列表Agent自然什么也不采集。这个hostname来自哪里来自Agent配置文件里的Hostname参数。如果这个参数没显式配置Agent会调用系统的主机名hostname命令的输出作为默认值。问题就出在这里很多人在Server端添加主机时用的名字是“Web-Server-01”这种自定义名称但Agent所在机器的系统主机名可能是“localhost”或者一串无意义的字符串。两边对不上主动模式就废了。更隐蔽的情况是大小写敏感。Zabbix的hostname匹配是区分大小写的“Web-Server-01”和“web-server-01”在Server看来是两个完全不同的主机。我遇到过好几次同事在Server端建主机时手抖打了个大写字母Agent端配置的是全小写结果排查了半天才发现是大小写的问题。实操建议在Agent的配置文件中显式设置Hostname参数并且确保它和Server端的主机名完全一致包括大小写。如果主机数量多建议用配置管理工具统一生成Agent配置文件避免手工输入出错。2.2 ServerActive的地址解析与多Server配置ServerActive参数告诉Agent把主动数据推送到哪个地址。这个参数可以填IP也可以填域名还可以填多个地址用逗号分隔。但这里有个细节如果填的是域名Agent在启动时会解析一次然后把解析结果缓存起来。如果后续DNS记录变了Agent不会自动重新解析除非重启Agent进程。多Server配置的场景通常出现在Proxy架构中。比如一个Agent需要同时向两个Proxy推送数据可以在ServerActive里写两个地址。但要注意Agent会轮流尝试这些地址如果第一个地址不可达它会尝试第二个但不会自动切回第一个除非Agent重启或者配置重载。还有一个坑是端口。ServerActive的默认端口是10051如果Server端改了监听端口Agent这边必须显式指定格式是IP:端口。很多人只写了IP忘了端口结果Agent一直往10051推Server却在10052上监听数据全丢了。2.3 BufferSize与数据积压的权衡主动模式下Agent采集到的数据不会立即发送而是先写到一个内存缓冲区里等缓冲区满了或者到了发送周期再批量推送给Server。这个缓冲区的大小由BufferSize参数控制默认是100。BufferSize设小了Agent会频繁发送数据网络交互次数多但数据延迟低。设大了批量发送的效率高但一旦Agent崩溃或者网络中断缓冲区里未发送的数据就会丢失。而且如果Server端处理速度跟不上Agent的缓冲区会一直满着新的采集数据写不进去就会触发BufferSend的等待逻辑导致采集延迟。我的经验值是对于监控项数量在100以内的主机BufferSize保持默认的100就行。对于监控项数量在500以上的主机可以适当调到300到500。但不要超过1000否则单次发送的数据包太大容易触发网络层的分片反而降低传输效率。另外BufferSend参数控制的是发送周期默认是5秒。意思是即使缓冲区没满每隔5秒也会强制发送一次。这个值可以根据网络状况调整网络好的话可以调到10秒减少发送频率网络差的话可以调到2秒降低单次发送的数据量。3. 被动模式的超时与并发那些让你半夜起床的告警被动模式虽然逻辑简单但坑一点也不少。尤其是当监控规模上去之后超时和并发问题会像幽灵一样缠着你。3.1 Timeout参数的全局影响Zabbix Server的配置文件里有一个Timeout参数默认是3秒。这个参数控制的是Server等待Agent响应的最长时间。如果Agent在3秒内没返回数据Server就认为这次采集失败记录一个超时错误。3秒听起来不短但在某些场景下真的不够。比如Agent所在主机负载很高CPU被占满Agent进程调度不上去响应自然就慢。又比如采集的key本身执行时间就长像vfs.dir.size这种统计目录大小的监控项在大目录上跑个五六秒很正常。这时候3秒的超时就会导致大量采集失败。把Timeout调大能解决问题但会带来副作用。因为Server是串行处理采集请求的在单个pollers进程内一个请求超时3秒意味着这个poller进程在这3秒内什么都干不了。如果超时调到10秒一个卡住的请求就会阻塞poller 10秒整体采集吞吐量直线下降。所以Timeout的调整需要配合StartPollers参数一起考虑。StartPollers控制的是Server端负责被动采集的进程数量默认是5。如果超时时间调大了就要相应增加StartPollers用更多的并发进程来弥补单个进程的阻塞。3.2 StartAgents与Agent端的并发上限Server端有StartPollersAgent端对应的就是StartAgents。这个参数决定了Agent能同时处理多少个被动请求默认是3。当Server的StartPollers大于Agent的StartAgents时多出来的请求就会在Agent端排队。Zabbix Agent处理请求是单线程轮询的在StartAgents大于1时会fork出多个子进程每个子进程处理一个请求如果请求排队时间过长Server端就会超时。我遇到过最典型的情况是Server端StartPollers设了20Agent端StartAgents还是默认的3。结果Server同时发起20个请求Agent只能同时处理3个剩下17个在排队。排在前面的请求很快处理完排在后面的请求等轮到它时Server早就超时了。表现就是监控数据时有时无断点毫无规律。调整原则Agent端的StartAgents应该大于等于Server端的StartPollers除以该Server监控的主机数量。但StartAgents也不是越大越好每个子进程都会消耗内存和CPU一般建议不超过10。3.3 被动模式下的网络中断重试逻辑被动模式还有一个让人头疼的问题网络中断后的重试。当Server向Agent发起连接失败时比如网络不通、Agent进程挂了Zabbix不会立即重试而是等到下一个采集周期再试。这意味着如果采集间隔是60秒网络中断了1秒但恰好发生在采集的那一瞬间那么这次采集就失败了要等60秒后才会再次尝试。对于核心监控项60秒的数据缺失可能就意味着60秒的监控盲区。解决办法是缩短采集间隔比如改成30秒甚至10秒。但缩短间隔又会加重Server的负担形成恶性循环。一个折中的方案是对核心监控项使用被动模式但把采集间隔设短比如15秒同时配合Zabbix的nodata触发器一旦超过一定时间没收到数据就告警。这样即使采集失败也能快速感知到。4. 数据采集的预处理在入库前把脏数据拦下来数据从Agent采集回来到最终写入数据库中间还有一个预处理阶段。这个阶段在Zabbix 4.0里得到了极大的增强支持正则替换、JSON解析、自定义脚本等多种处理方式。很多人忽略了预处理的价值把所有原始数据一股脑塞进数据库结果数据库膨胀得飞快查询也越来越慢。4.1 预处理链的执行顺序与短路逻辑Zabbix的预处理是按顺序执行的前一个步骤的输出作为后一个步骤的输入。如果某一步执行失败整个预处理链就会中断这个数据点会被丢弃或者标记为不支持。这个特性可以用来做数据过滤。比如你采集了一个JSON格式的返回值里面包含了多个字段但只有其中一个字段是你需要的。你可以先用JSONPath提取出目标字段再用正则表达式做一次格式校验最后用自定义倍数做单位转换。如果JSONPath提取失败比如返回的不是合法JSON后面的步骤就不会执行数据直接被丢弃不会污染数据库。但要注意预处理链的每一步都会消耗CPU。如果监控项数量很大预处理逻辑又很复杂Server端的CPU会成为新的瓶颈。我的建议是能在Agent端做的预处理就不要放到Server端。比如单位转换、简单的正则替换完全可以在Agent的自定义UserParameter里用脚本搞定Server端只负责接收最终结果。4.2 用预处理解决浮点数精度问题Zabbix采集回来的数据很多时候是浮点数。比如CPU负载、内存使用率、磁盘IO等待时间。这些浮点数在入库时Zabbix默认会保留到小数点后四位。但有些场景下四位小数太多了不仅浪费存储空间还会让趋势图看起来毛刺很多。这时候可以用预处理里的自定义倍数功能。比如把采集到的浮点数乘以100然后取整就变成了一个整数百分比。这样存储空间节省了趋势图也平滑了。但要注意乘以100之后触发器的阈值也要相应调整否则会出现误告警。另一个常见的精度问题是科学计数法。有些Agent返回的值是1.23e-5这种格式Zabbix在解析时可能会出错。这时候可以用预处理里的正则表达式把科学计数法转换成普通小数。具体做法是匹配(\d\.\d)e-(\d)然后替换成对应的十进制形式。4.3 预处理与触发器的联动避免误告警预处理不仅影响存储还直接影响触发器的计算。如果预处理把数据改了触发器却还在用原始值的逻辑来判断就会出问题。举个例子你采集的是磁盘剩余空间单位是字节。原始值很大比如107374182400100GB。你在预处理里把它除以1073741824转换成GB变成100。然后触发器里写last(/host/vfs.fs.size[/,free])10意思是剩余空间小于10GB就告警。这个逻辑是对的因为预处理已经把单位转成GB了。但如果你在预处理里做了四舍五入把10.4变成了10触发器里写的是10那么10.4GB的实际剩余空间就不会触发告警因为预处理后变成了10不满足小于10的条件。这种精度丢失导致的漏告警排查起来非常隐蔽。经验预处理里的取整操作要慎重尤其是当触发器阈值是边界值时。要么保留足够的小数位要么把触发器阈值也做相应的调整。5. 采集频率的博弈实时性与系统负载的平衡采集频率是Zabbix运维中最难拿捏的参数之一。设短了Server和Agent都扛不住设长了故障发现不及时。而且不同类型的监控项对频率的敏感度完全不同。5.1 不同监控项类型的推荐采集间隔我把常见的监控项分成三类分别给出推荐的采集间隔监控项类型典型代表推荐间隔理由状态类主机存活、端口监听、进程状态30-60秒需要快速感知故障但变化不频繁性能类CPU使用率、内存使用率、磁盘IO60-120秒变化较快但短时间波动不影响判断容量类磁盘空间、inode使用率、日志大小300-600秒变化缓慢高频采集没有意义这个表格只是参考实际调整时还要考虑主机的角色。比如数据库服务器的性能类指标采集间隔可以缩短到30秒因为数据库的负载波动对业务影响很大。而文件服务器的容量类指标采集间隔可以放宽到1800秒因为磁盘不会瞬间写满。5.2 用自定义间隔应对特殊场景Zabbix支持为单个监控项设置自定义的采集间隔格式是flexible可以指定时间段和对应的间隔。这个功能在应对特殊场景时非常有用。比如某台服务器每天凌晨2点到4点会跑批处理任务这段时间CPU和内存的负载会飙升。如果采集间隔还是默认的60秒可能会错过负载峰值。这时候可以设置一个灵活间隔在2:00-4:00之间采集间隔改为10秒其他时间保持60秒。这样既保证了关键时段的监控精度又不会在平时浪费资源。配置方法是在监控项的Update interval里选择Flexible然后添加时间段和间隔。注意时间段的格式是HH:MM-HH:MM间隔单位是秒。5.3 采集间隔与触发器评估周期的关系很多人不知道的是触发器的评估周期和监控项的采集间隔是独立的。监控项每60秒采集一次但触发器可能每30秒就评估一次。这意味着触发器可能会用同一个数据点评估两次或者在一个采集周期内评估多次。这本身不是问题但如果你在触发器里用了change函数判断值是否变化就会出现误判。因为同一个值被评估两次change函数会认为值没有变化但实际上只是采集间隔还没到。解决办法是让触发器的评估周期和监控项的采集间隔保持一致或者用nodata函数来检测数据缺失而不是依赖change函数。6. 从Proxy到Agent分布式采集的链路优化当监控规模扩展到多个机房、多个网络域时单靠一个Server很难覆盖所有Agent。这时候就需要引入Proxy把采集压力分散到离Agent更近的地方。6.1 Proxy的主动与被动模式选择Proxy本身也有主动和被动两种模式。被动模式下Server主动向Proxy索取数据主动模式下Proxy自己把数据推给Server。和Agent的选择逻辑类似如果Proxy和Server之间的网络质量好但Server的负载已经很高那就用主动模式让Proxy自己推数据减轻Server的负担。如果Proxy和Server之间的网络不稳定或者Server需要精确控制数据收集的节奏那就用被动模式。但Proxy的主动模式有一个额外的坑Proxy需要先从Server获取配置包括主机列表、监控项、触发器然后才能开始采集。这个配置同步是周期性的默认是60秒一次。如果Server端刚添加了一台主机Proxy可能需要等60秒才能感知到然后才开始采集。这个延迟在故障排查时容易被忽略。6.2 Proxy下的数据缓冲与断点续传Proxy的一个核心价值是数据缓冲。当Proxy和Server之间的网络中断时Proxy会把采集到的数据先存在本地等网络恢复后再批量上传。这个缓冲能力由ProxyLocalBuffer和ProxyOfflineBuffer两个参数控制。ProxyLocalBuffer控制的是本地保留数据的时间默认是1小时。ProxyOfflineBuffer控制的是离线状态下保留数据的时间默认也是1小时。如果网络中断超过1小时超出部分的数据就会丢失。对于网络不稳定的环境可以把这两个参数调大比如调到24小时甚至72小时。但要注意Proxy本地的存储空间是有限的如果数据量太大可能会把磁盘写满。所以调大缓冲时间的同时也要监控Proxy的磁盘使用率。6.3 Agent端的数据压缩与传输优化在Agent和Proxy或Server之间传输数据时Zabbix默认是不压缩的。如果监控项很多每次传输的数据量可能达到几百KB甚至几MB。在带宽紧张的环境下这会成为瓶颈。Zabbix 4.0支持在Agent端开启数据压缩通过EnablePersistentBuffer和BufferSize的配合可以减少传输的数据量。但压缩本身也会消耗CPU所以要在带宽和CPU之间做权衡。我的经验是如果Agent和Server之间的带宽低于10Mbps或者监控项数量超过500就值得开启压缩。如果带宽充足CPU又比较紧张那就保持默认的不压缩。7. 采集数据的验证与排错从日志到实际值配置完采集最怕的就是“看起来正常实际上没数据”。Zabbix的面板有时候会骗人绿色图标不代表数据真的在更新。这一节分享几个我常用的验证和排错方法。7.1 用zabbix_get手动验证被动采集被动模式下最直接的验证方法是在Server上手动执行zabbix_get命令模拟Server向Agent发起一次采集请求。命令格式是zabbix_get -s Agent_IP -p 10050 -k system.cpu.load[all,avg1]如果返回了具体的数值说明Agent的被动采集是通的。如果返回ZBX_NOTSUPPORTED说明key不支持或者参数不对。如果连接超时说明网络不通或者Agent没监听10050端口。这个命令的好处是绕过了Zabbix Server的调度逻辑直接测试Agent的响应能力。排查被动模式问题时这是第一步。7.2 主动模式的日志追踪主动模式没有zabbix_get这样的工具只能看日志。Agent的日志里会记录它向Server拉取配置的过程以及推送数据的结果。关键日志行包括active check configuration update from [Server:10051] started to fail说明Agent连不上Server的10051端口。no active checks on server [Server:10051]: host [hostname] not found说明Server端没有找到对应的hostname需要检查主机名配置。sending data to server [Server:10051]说明Agent正在推送数据如果这条日志频繁出现但Server端没收到可能是网络问题。把Agent的DebugLevel调到4可以看到更详细的推送日志包括每次推送了多少个值、Server返回了什么响应。7.3 数据库层面的数据验证如果Agent和Server的日志都正常但面板上就是没数据那问题可能出在数据库层面。可以直接查Zabbix的history表看看对应的监控项有没有数据写入。SELECT * FROM history WHERE itemid itemid ORDER BY clock DESC LIMIT 10;如果history表里有数据但面板上不显示那可能是前端缓存或者权限问题。如果history表里没数据但Agent日志显示推送成功那可能是Server端的预处理或者触发器把数据丢弃了。查history表的时候要注意Zabbix 4.0默认把历史数据按数值类型分表存储history存浮点数history_uint存无符号整数history_str存字符串。查的时候要根据监控项的类型选对表。8. 采集性能的调优实战从参数到架构最后聊一下采集性能的调优。Zabbix的性能问题十有八九出在采集环节。调优的思路不是盲目加大参数而是先找到瓶颈点再针对性地调整。8.1 用Zabbix自带的内部监控项定位瓶颈Zabbix Server自身也提供了一组内部监控项可以用来监控Server的运行状态。关键的有zabbix[queue]当前等待处理的队列长度。如果这个值持续大于0说明Server处理不过来。zabbix[wcache,values]写入缓存的值数量。如果这个值增长很快说明采集频率太高。zabbix[process,poller,avg,busy]poller进程的平均繁忙度。如果接近100%说明poller不够用。把这些内部监控项加到Zabbix里设置合理的触发器就能在性能问题恶化之前收到告警。8.2 StartPollers与StartTrappers的配比StartPollers负责被动采集StartTrappers负责主动采集和Proxy数据接收。这两个参数的配比取决于你的采集模式分布。如果被动模式占主导StartPollers就要设大一些比如20到30。如果主动模式占主导StartTrappers就要设大一些。但要注意每个进程都会消耗内存进程数太多会导致Server内存不足。一般来说StartPollers和StartTrappers的总和不要超过CPU核心数的4倍。8.3 数据库写入优化从Housekeeper到分区表采集到的数据最终要写入数据库。如果数据库写入跟不上采集再快也没用。Zabbix 4.0默认用Housekeeper来清理过期数据但Housekeeper的删除操作很重容易造成数据库锁等待。更好的方案是用数据库分区表按时间分区过期数据直接drop分区比delete快得多。但分区表需要手动配置而且Zabbix的前端对分区表的支持有限需要额外注意。另一个优化点是HistoryStorageDateIndex参数。开启后Zabbix会为历史数据建立日期索引加快查询速度。但索引本身也会占用空间所以要在查询性能和存储空间之间做权衡。调优这件事没有一劳永逸的方案。监控规模在变业务需求在变参数也要跟着变。我自己的做法是每季度做一次性能回顾看看队列长度、进程繁忙度、数据库写入延迟这些指标的趋势然后微调参数。监控系统本身也需要被监控这才是运维的常态。
