基于Zabbix + Docker开发的监控系统

背景

团队所开发的持续监测网站/APP的产品,需要有一项监控功能,具体来说就是,对URL/域名进行周期性(小于1分钟)监测,并且能对异常事件进行实时告警。在最近这几个月,我一直将大部分时间和精力花在了设计开发这套系统上面,一共经历了两个大版本。下文就对这套监控系统进行介绍,分享给大家。

自己之前没有这类系统的开发设计经验,于是问了下周围同事。和同事讨论的结果是:既然现在人手不够(就我一个人),我之前也没开发过这类系统,时间又比较紧迫(领导给的排期是“越快越好”……),那么找一个已有的开源监控系统进行二次开发,应该是一个不错的选择。那么,选择哪种开源监控系统呢?根据同事以往的经验,可以考虑zabbix,自己也调研过一段时间zabbix,它的优点有如下几条:

  • 架构简单、清晰
  • 文档丰富,代码注释十分详细
  • agent/server部署方便
  • 包含整套监控流程:包括采集、触发、告警
  • agent支持用户自定义监控项
  • 触发器表达式丰富
  • 暴露了一套HTTP + JSON的接口

另外,除了以上这样,还有一个比较重要的一个原因:团队中的同事之前也调研过zabbix。在人手不足、时间又紧的情况下,这一个因素的权重就显得相对较高。所以,最终选择了在zabbix基础上进行二次开发。

至于使用docker,是考虑到监控的对象,会因为用户的增长、以及用户的操作,有动态的变化。作为设计者,自然希望有一种机制,能够可编程地、动态地控制zabbix agent的数量。我们既不让某一个agent(具体应该是agent的端口)有过多的监控项,导致监控项无法在一个周期内完成数据采集;又不想有生成过多的agent,造成系统资源的浪费。目前势头正劲的docker,怎能不进入我的视野?社区活跃、文档完善、相对其他虚拟化技术又很轻,都成为了我选择docker的原因。

需求

这个监控系统的设计目标是:希望能够提供秒级时间粒度的监控服务,实时监控用户网页的可用性指标,做到快速反馈。
具体的需求为:当用户在我们的产品中创建持续监测任务,对于用户输入的URL进行两种类型的监控,即HTTP返回码以及PING返回时间。当某一类监控的采样数据异常时——例如HTTP返回500、PING超时——就会在用户界面上返回告警事件,用以提醒用户;采样数据正常时,再返回告警事件的状态。

第一个版本

架构

第一个版本中,系统的设计特点为:

  • 一台物理服务器对应一个zabbix的host
  • 监控项使用被动采集方式
  • 每个zabbix agent处于一个docker container内,每生成一个container,就在物理机上面开放一个端口,并生成一个对应的zabbix agent interface
  • 对于上游的每个监控任务,会在每个IDC节点各生成了一组zabbix采集监控任务,具体对应关系为:(groupid, hostid, interfaceid, itemid, triggerid)
  • 告警事件的生成,采用了轮询trigger状态的方式,当上游监控任务对应的处于PROBLEM状态的节点数大于总节点数时,产生告警事件;当所有节点均为OK状态时,产生告警恢复事件

第一个版本的架构,如下图所示:

Monitor Web模块,作为后端的接口供前端来调用,主要提供监测任务添加、修改、删除,告警事件列表返回、告警事件删除等功能。
Monitor Syncer模块,用于定期检查每个监测任务对应的zabbix trigger的状态,根据trigger的状态,来生成告警事件以及告警恢复事件。
Zabbix ServerZabbix Agent就构成了监控系统的核心服务。其中,一台物理机器中,包含了多个Docker container,每个container中运行这一个zabbix agent。

流程

以创建监控任务为例,当前端发出创建监测任务时,Monitor Web模块接收到该请求,进行如下操作:

  1. 在每一个IDC(对于zabbix中的group)中,各创建一个container,在container中启动zabbix agent,记录其对外开放的端口
  2. 根据得到的端口,在zabbix host中,创建zabbix interface(和agent的端口一一对应)
  3. 根据得到的interface,创建HTTP和PING两种类型的zabbix item和trigger,分别监控URL的HTTP返回码,以及host的PING返回值。zabbix server开始进行数据采集和监控
  4. 在业务数据库表中添加该条监测任务记录

Monitor Syncer每隔一个周期(30s),扫描一遍目前所有监测任务,再从zabbix数据库中查找到对应trigger的状态。如果trigger状态为PROBLEM的超过了半数,那么该监控任务就处于了告警状态,最后再根据该任务目前是否处于告警状态,来决定是否需要添加告警事件;那么对应的,如果trigger状态均为OK,并且目前任务处于告警状态,那么则需要为告警事件添加对应的恢复状态。

这样,就完成了添加任务 -> 告警 -> 恢复的整个监控系统的典型流程。

性能

对第一个版本进行了性能测试,得到了以下性能指标:

(3台服务器,1台部署Zabbix Server,2台部署Docker + Zabbix Agent。服务器配置:Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz X 24,128G 内存,千兆网卡)

  • 样本采集项:1111 item
  • 样本采集频率:60s
  • 最大入口流量: 68 kbps
  • 最大出口流量: 270 kbps
  • 每秒下发采集请求: ~19 qps

存在的不足

因为开发时间所限,以及对于新技术的调研不够深入,第一个版本有不少不足,主要体现如下:

  • zabbix agent采用的是被动模式,每次采集数据zabbix server都需要向zabbix agent查询监控项,网络出口数据量较大
  • 由于数据采集都是进行需要发起网络操作,而每个采集数据的频率又较高,因此会出现数据采集不完整、无法连续采集的现象
  • 采用轮询方式探测故障事件,效率较低,实时性不高,同时也有单点问题
  • 任务请求没有进行持久化,如果因为模块问题而丢失或操作失败,无法回滚

第二个版本

升级点

针对第一版本发现的问题,在设计上做了一些升级,具体升级点和设计上面的特点如下:

  • 不再采用物理机器和Zabbix Host一一对应的关系,而是采用Docker container和Zabbix Host一一对应(这里的Zabbix Host就是一个虚拟Host的概念)
  • 采用etcd进行分布式状态管理,动态自主注册Zabbix Host
  • 采集项使用Agent自主上传方式
  • Zabbix Host和监控项之间的比例可配置,即配置每个Zabbix Host上最多进行的监控项数量
  • 监控项自动转移,如果一个Zabbix Host出现异常,系统可以将上面的监控项迁移至其他健康的Zabbix Host
  • 借助Zabbix Action,将异常状态的改变实时传递给系统,而不是由系统进行轮询
  • 任何请求将进行持久化,方便查看以及请求的回滚

第二版的架构变成了这样:

上图中,Monitor Web一方面接收前端的请求,它收到请求做的唯一的事情就是将请求数据写入数据库进行持久化;另一方面,它还会接收来自Zabbix Server的事件请求,这里的事件表示trigger状态的改变。

Monitor Admin有两个职责:1)定期检测未完成的请求(添加/删除监控任务),拿到请求之后通过Zabbix API在对应的Zabbix Agent中添加/删除监控项(item + trigger);2)侦听ETCD中的key状态变化,进行相应地Zabbix Host创建/删除,以及监控项的迁移。

每当启动一个Docker container,就会将物理机的IDC、ETCD Server地址、Zabbix Server地址等参数传递至container,然后在内部启动zabbix_agentd,并且定期检查zabbix_agentd是否存活,如果存活的话,则生成一个唯一的key,向ETCD发起key创建/更新请求;如果不存活,则key会自然的过期。这样,Monitor Admin就通过ETCD得知了各个zabbix_agentd的健康状况,并且在内存中存储一份agent的拓扑结构。

启动了多个container,在Zabbix Server中就对应了多个Zabbix Host,如下图所示:

其他方面调优

除了整体架构的升级,还在了许多方面(主要是Zabbix)进行了调优,比如:

尽量增加agent的超时时间

因为我们的监控采集项,都是需要对URL或者域名进行网络操作,这些操作往往都会比较耗时,而且这是正常的现象。因此,我们需要增加在Zabbix agent的采集超时,避免正常的网络操作还没完成,就被判断为超时,影响Server的数据获取。

### Option: Timeout
#       Spend no more than Timeout seconds on processing
#
# Mandatory: no
# Range: 1-30
# Default:
# Timeout=3
Timeout=30

不要在采集脚本中加上超时

既然Zabbix agent中已经配置了采集超时时间,就不需要在采集脚本中添加超时了。一方面增加了维护成本,另一方面如果配置不当,还会造成Zabbix agent中的超时配置失效。(之前在脚本中使用了timeout命令,由于设置不正确,导致采集项总是不连续,调试了好久才查明原因。)

增加Zabbix Server的Poller实例

默认情况,用于接收Zabbix agent采集数据的Poller实例只有5个。对于周期在1分钟内、数量会达到千级别的采集项来说,Poller实例显然是不够的,需要增大实例数,充分利用好服务器资源。例如:

### Option: StartPollers
#       Number of pre-forked instances of pollers.
#
# Mandatory: no
# Range: 0-1000
# Default:
# StartPollers=5
StartPollers=100

利用好Zabbix trigger expression

如果只把trigger expression理解为“判断某个item value大于/小于某个阈值”,那就太低估Zabbix的trigger expression了,它其实可以支持很多复杂的逻辑。比如,为了防止网络抖动,需要当最近的连续两个采集项异常时,才改变trigger的状态,表达式可以写成:(假设item_key<0为异常)

{host:item_key.last(#1)}<0&{host:item_key.last(#2)}<0

再举个例子,同样是为了防止采集的服务不稳定,我们可以规定,当目前trigger的状态为PROBLEM,并且最近5分钟的采集数据均正常的时候,才可以将trigger状态改为OK,表达式可以这样写:

({TRIGGER.VALUE}=0&{host:item_key.last(#1)}<0&{host:item_key.last(#2)}<0) | ({TRIGGER.VALUE}=1&{host:item_key.min(5m)}<0)

具体可以参考Trigger expression

性能

测试环境:

3台服务器,硬件参数与之前保持一致

  • Zabbix Server * 1
  • 监控服务器 * 1
  • ETCD Server * 1
  • Docker container * 500 (在1台物理机中)

性能指标:

  • 样本采集项:7100
  • 样本采集频率:60s
  • Zabbix Server每秒处理监控项: 130 个监控项 / 秒 (第一版为~19 qps)
  • 平均入口流量:454.25 kbps
  • 最大入口流量:916.12 kbps (第一版为68 kbps)
  • 平均出口流量:366.65 kbps
  • 最大出口流量:1.68 Mbps (第一版为270 kbps)

    部分性能指标的监测图如下:

Zabbix Server每秒处理监控项数目

Zabbix Server网卡入口流量

Zabbix Server网卡出口流量

可以看出,跟第一版相比,最大可采集的数据量是原来的近7倍,Zabbix Server的进出口流量有明显的提升,监控项的处理吞吐率也和采集项数量有了一致的提高,是原来的6.8倍,并且没有出现监控项在一个周期内无法采集到的情况(如果再增加监控项,则会不定期出现采样不连续的情况),性能提升还是比较明显的。

系统截屏

故障事件列表

短信报警

总结

本文从架构上介绍了如果基于Zabbix以及Docker,构建一个监控系统。

(广告时间,感兴趣的朋友可以登录我们的官网进行注册,使用我们的评测/监测/加速等服务,并且通过添加PC持续监测任务来对网站进行实时监控。)

当然,目前的版本仍然不够完美,目前“抗住”了,然后需要考虑“优化”,年后预计会有较大改动,架构上以及技术上,自己已经在考量中。

(又是广告时间,团队急需后端小伙伴,可以通过我们的官网了解到我们的产品,也过年了,年终奖也发了,感兴趣的、有想法的朋友,欢迎将简历发送至[email protected],谢谢!)

-- EOF --

你可能感兴趣的:(监控与安全,性能,zabbix,docker,监控)