(原文地址:https://blog./posts/2015/02/17/ji-yu-zabbix-dockerkai-fa-de-jian-kong-xi-tong/)背景团队所开发的持续监测网站/APP的产品,需要有一项监控功能,具体来说就是,对URL/域名进行周期性(小于1分钟)监测,并且能对异常事件进行实时告警。在最近这几个月,我一直将大部分时间和精力花在了设计开发这套系统上面,一共经历了两个大版本。下文就对这套监控系统进行介绍,分享给大家。 自己之前没有这类系统的开发设计经验,于是问了下周围同事。和同事讨论的结果是:既然现在人手不够(就我一个人),我之前也没开发过这类系统,时间又比较紧迫(领导给的排期是“越快越好”……),那么找一个已有的开源监控系统进行二次开发,应该是一个不错的选择。那么,选择哪种开源监控系统呢?根据同事以往的经验,可以考虑zabbix,自己也调研过一段时间zabbix,它的优点有如下几条:
另外,除了以上这样,还有一个比较重要的一个原因:团队中的同事之前也调研过zabbix。在人手不足、时间又紧的情况下,这一个因素的权重就显得相对较高。所以,最终选择了在zabbix基础上进行二次开发。 至于使用docker,是考虑到监控的对象,会因为用户的增长、以及用户的操作,有动态的变化。作为设计者,自然希望有一种机制,能够可编程地、动态地控制zabbix agent的数量。我们既不让某一个agent(具体应该是agent的端口)有过多的监控项,导致监控项无法在一个周期内完成数据采集;又不想有生成过多的agent,造成系统资源的浪费。目前势头正劲的docker,怎能不进入我的视野?社区活跃、文档完善、相对其他虚拟化技术又很轻,都成为了我选择docker的原因。 需求这个监控系统的设计目标是:希望能够提供秒级时间粒度的监控服务,实时监控用户网页的可用性指标,做到快速反馈。 第一个版本架构第一个版本中,系统的设计特点为:
第一个版本的架构,如下图所示:
流程以创建监控任务为例,当前端发出创建监测任务时,
这样,就完成了添加任务 -> 告警 -> 恢复的整个监控系统的典型流程。 性能对第一个版本进行了性能测试,得到了以下性能指标: (3台服务器,1台部署Zabbix Server,2台部署Docker + Zabbix Agent。服务器配置:Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz X 24,128G 内存,千兆网卡)
存在的不足因为开发时间所限,以及对于新技术的调研不够深入,第一个版本有不少不足,主要体现如下:
第二个版本升级点针对第一版本发现的问题,在设计上做了一些升级,具体升级点和设计上面的特点如下:
第二版的架构变成了这样: 上图中,
每当启动一个Docker container,就会将物理机的IDC、ETCD Server地址、Zabbix Server地址等参数传递至container,然后在内部启动 启动了多个container,在Zabbix Server中就对应了多个Zabbix Host,如下图所示: 其他方面调优除了整体架构的升级,还在了许多方面(主要是Zabbix)进行了调优,比如: 尽量增加agent的超时时间 因为我们的监控采集项,都是需要对URL或者域名进行网络操作,这些操作往往都会比较耗时,而且这是正常的现象。因此,我们需要增加在Zabbix agent的采集超时,避免正常的网络操作还没完成,就被判断为超时,影响Server的数据获取。
不要在采集脚本中加上超时 既然Zabbix agent中已经配置了采集超时时间,就不需要在采集脚本中添加超时了。一方面增加了维护成本,另一方面如果配置不当,还会造成Zabbix agent中的超时配置失效。(之前在脚本中使用了 增加Zabbix Server的Poller实例 默认情况,用于接收Zabbix agent采集数据的Poller实例只有5个。对于周期在1分钟内、数量会达到千级别的采集项来说,Poller实例显然是不够的,需要增大实例数,充分利用好服务器资源。例如:
利用好Zabbix trigger expression 如果只把trigger expression理解为“判断某个item value大于/小于某个阈值”,那就太低估Zabbix的trigger expression了,它其实可以支持很多复杂的逻辑。比如,为了防止网络抖动,需要当最近的连续两个采集项异常时,才改变trigger的状态,表达式可以写成:(假设
再举个例子,同样是为了防止采集的服务不稳定,我们可以规定,当目前trigger的状态为PROBLEM,并且最近5分钟的采集数据均正常的时候,才可以将trigger状态改为OK,表达式可以这样写:
具体可以参考Trigger expression 性能测试环境: 3台服务器,硬件参数与之前保持一致
性能指标:
部分性能指标的监测图如下: Zabbix Server每秒处理监控项数目 Zabbix Server网卡入口流量 Zabbix Server网卡出口流量 可以看出,跟第一版相比,最大可采集的数据量是原来的近7倍,Zabbix Server的进出口流量有明显的提升,监控项的处理吞吐率也和采集项数量有了一致的提高,是原来的6.8倍,并且没有出现监控项在一个周期内无法采集到的情况(如果再增加监控项,则会不定期出现采样不连续的情况),性能提升还是比较明显的。 系统截屏故障事件列表短信报警总结本文从架构上介绍了如果基于Zabbix以及Docker,构建一个监控系统。 (广告时间,感兴趣的朋友可以登录我们的官网进行注册,使用我们的评测/监测/加速等服务,并且通过添加PC持续监测任务来对网站进行实时监控。) 当然,目前的版本仍然不够完美,目前“抗住”了,然后需要考虑“优化”,年后预计会有较大改动,架构上以及技术上,自己已经在考量中。 |
|