zabbix server 中 poller/trapper/history syncer/alerter 等进程类型及其任务

进程类型

poller（轮询器）	被动类型监控数据采集
trapper（捕捉器）	主动类型监控数据接收
http/ipmi/java/proxy poller	其他被动类型监控数据采集
unreachable poller	处理被标记为不可访问的主机
snmp trapper	SNMP类型的数据接收
preprocessing worker	执行数据预处理操作，包括数据清洗、格式转换、数据过滤、数据聚合等
history syncer	负责将数据写入数据库和计算监控数据并生成事件
alerter	发送告警通知
discoverer	在网络上进行主机发现
escalator	负责处理事件所触发的action序列
housekeeper	负责清理过期数据和维护数据库的线程
timer（定时器）	用于执行定时任务的线程。它触发和执行计划任务，如数据收集、数据处理和报警等
configuration syncer	负责数据库与缓存之间的配置信息同步
preprocessing/ipmi/alert/task manager（任务管理器）	负责管理和调度一些后台任务

数据流

参考：Zabbix server多进程协作式数据流处理过程及负载分析

1. poller/trapper获取数据输入，然后将数据传递给preprocessing;

2. 预处理完成之后，监控数据会分流到不同的进程

   ==> LLD: 根据监控数据生成配置信息（监控项、触发器等），所生成的信息最后写入共享内存和数据库。
   ==> history syncer: 它一方面负责将监控数据本身写入到数据库中，另一方面还负责计算监控数据，并根据计算结果生成事件和问题（problem），以及为事件和问题生成响应计划。事件、问题以及对事件的响应计划也写入到数据库中。

3. escalator进程和alerter进程负责跟进（follow up）并完成history syncer进程所生成的响应计划，它们会从数据库读取所需要的计划信息，并遵照计划进行跟进。

工作负载

• poller/trapper

  poller/trapper进程接受大量的连接，并从socket读取数据，这些数据是原始的监控数据。poller/trapper进程的工作量大小可以用nvps值（new values per second）来衡量。

  如果poller/trapper进程处理数据的速度赶不上数据流入的速度，就会发生拥堵排队，此时我们往往会观察到zabbix[queue]监控值的升高。

  由于poller/trapper是整个数据流的源头，如果下游的进程发生拥堵，最终也会传导到该进程（在数据库之后的一些进程例外，因为数据库相当于一个极大的缓冲池，会截断向上游的传导）。

• preprocessing

  预处理进程的职责是按照用户设置对原始监控数据进行各种加工。这些加工既有简单的数值加减也有复杂的文本处理（正则表达式、JSON Path等），甚至可以自定义处理函数（JavaScript脚本）。

  预处理进程的工作量取决于每一种加工步骤所处理的数据量。显然，对一个5000字符长度的字符串执行复杂的正则运算要远比两个整数的减法运算工作量大（读者可以在网上找到正则表达式拒绝服务攻击——ReDoS的例子）。

  一般来说，并非所有的监控数据都需要进行预处理。如果某些监控项没有配置预处理，那么这些监控项的数据就不需要进行这一步的加工。当预处理进程的处理能力不能满足要求时同样会发生拥堵，所造成的结果就是流向下游的数据量减少，而上游的进程则无法向下传递数据。

• ldd

  lld进程的职责是解析预处理之后的监控数据（JSON串），并按照规则创建或者修改监控项和触发器等。

  lld规则所采集到的数据是特定格式的JSON串，其中包含了自动发现的对象信息，lld进程根据这些新发现的对象创建或者修改监控项、触发器、主机等。显然，当自动发现的对象数量很多时，就意味着需要创建或者修改大量的监控项、触发器等（对于重复发现的对象则不需要创建）。

  lld进程的下游是数据库和共享内存，当数据库出现问题时，lld进程也会受到影响。如果lld进程发生拥堵，那么上游的预处理进程也无法幸免。

• history syncer

  history syncer 进程既需要进行大量的计算又需要完成大量的IO。

  计算工作主要是根据监控数据和触发器表达式进行运算，以决定是否生成事件和问题（problem）。IO工作主要是将所有监控数据以及事件信息写入数据库中。显然，监控值和触发器的数量共同决定了计算量，而IO的工作量则主要取决于监控值的数量和类型以及事件的多少。

  当数据量很大时，IO往往首先成为瓶颈，进而导致history syncer的处理能力下降，继而发生拥堵。但是IO能力受限于数据库的性能，所以即使增加history syncer进程的数量也无助于提高其处理能力。

• 数据库

  数据库相当于一个巨大的缓冲池，可以隔绝上游和下游的拥堵传递。当数据库下游的进程发生拥堵时，数据库中的事件数据不能得到及时处理，但是如果写库的速度没有受到影响，那么位于数据库上游的进程（例如history syncer、lld进程）仍然可以正常工作，继续向数据库写入数据。

• escalator/alerter

  在数据库的下游有escalator和alerter进程，两者都是从数据库中消费数据的。escalator进程主要消费escalations表中的数据并将生产的数据写入alerts表中，alert进程则消费alerts表中的数据。显然两个进程的工作量取决于所消费的表中尚未处理的数据的量。

  一般来说，当监控数据触发了大量事件和问题时，就会导致escalations表数据增速上升，进而导致alerts数据增速上升。换句话说，这两个进程的压力与被监控对象的整体健康程度有关。在拥堵传导方面，因为两者中间有alerts表作为缓冲，下游的拥堵不会传导至上游。

工作模式

• 主动式脉冲

主动式脉冲是指进程每次处理一小批数据，如此循环往复，只要有待处理的数据就持续循环，当所有待处理数据都处理完毕时调用sleep函数，主动休眠一定时长。

history syncer进程就属于主动式脉冲，其繁忙脉冲时长不固定，但是每次休眠的时长是固定的（每次1秒）。

poller进程和escalator进程也属于主动式脉冲，其繁忙时长不固定，而且休眠时长也不固定（因为他们的任务都是定点的，要求在准确的时间点醒来）。

• IO阻塞式脉冲

IO阻塞式脉冲是指进程不会主动休眠，而是被动IO阻塞。这些进程每次循环会首先读取数据，当没有数据可消费时被迫阻塞，直到有新数据到来。

trapper进程、preprocessing进程、lld进程和alert进程都属于IO阻塞式，其中trapper进程阻塞于TCP套接字，另外3种进程则阻塞于Unix域套接字。