神荼

神荼是中国民间传说中能制伏恶鬼的神人。最开始出现在上古神话中。传说神荼和郁垒同为魑魅魍魉之首，归于蚩尤，在涿鹿之战中被擒，降于黄帝轩辕氏。一般位于左边门扇上，身着斑斓战甲，面容威严，姿态神武，手执金色战戢。故中国民间称他为门神。表达了古代人民一种消灾免祸、趋吉避凶的美好愿望。

作为互联网企业，我们也需要自己的神荼，于是我们的监控系统就借用了这个名字，期望着这套系统能够如神荼一般守护公司的平台架构和业务产品！

部署策略

监控系统是整个运维环节，乃至整个产品生命周期中最重要的一环，要求事前能及时预警发现故障，事后能提供详细的数据用于追查定位问题，这也是对于想构建一套监控系统的基本要求。

稳：要求平台架构设计成熟；

准：要求能准确及时预警，准确定位故障；

狠：要求满足多业务多维度，大数据监控对象数据采集性能；

选择一款开源的监控系统，是一个省时省力，效率最高的方案。监控系统业界有很多杰出的开源监控系统，小伙伴们最容易想到的就是大名鼎鼎的zabbix, 不过随着业务的快速发展，以及互联网公司特有的一些需，如针对docker容器的监控。zabbix监控系统在性能、扩展性和用户的使用效率方面，已经无法支撑了。

为了满足大型企业多维度监控需求选择自行开发一套监控系统是一种很好的方法。但是自行开发在人力、时间成本投入过大很容易让产品夭折。站在前人的肩膀上，利用优秀的开源项目快速构建现代化监控系统才是合理的选择。于是，我们尝试了，获得了一些经验和体会，在此分享给大家。

我们需要的监控系统

基本的监控系统系统组件：

采集器

存储数据

显示数据

报警通知

依照监控系统功需求划分为：

系统基础监控

应用服务监控

业务状态监控

日志分析监控

根据业务的需求，慎重比较和选择开源项目后，我们定义出下面的系统架构：

基于Zabbix构建报警平台

Zabbix 无疑是开源项目中最成熟的监控解决方案。是一个可高自由度定制，可视化的报警监控系统。 功能十分的强大，可轻松实现探针的自动化注册，也支持基于角色的监控对象自动发现。可定制各种模板（template），通过SNMP、SSH、Telnet、IPMI、JMX监控，可自由定制可视化的屏幕（screen）等等。

在多维度的生产应用环境中单台主机监控采集器需要完成约400多项监控指标，这些指标包括以下几个方面：

CPU info

Disk info

IO

System uptime

Memory info

Network info

端口存活、进程存活

单个进程资源消耗（nginx 、tomcat、mysql）

TCP/UDP （established、time_close 、time_waite ）相关统计

服务器硬件相关IPMI(温度、电源、风扇转速、raid)

内核配置参数

zabbix使用关系型数据库mysql作为数据存储。不过随着业务的发展及复杂度的增加Zabbix探针在监控对象上运行的脚本也会变多，需要更多的进程，可能会对正常业务产生影响。

cAdvisor 监控docker

Google的cAdvisor（Container Advisor）“为容器用户提供了了解运行时容器资源使用和性能特征的方法”。cAdvisor的容器抽象基于Google的lmctfy容器栈，因此原生支持Docker容器并能够“开箱即用”地支持其他的容器类型。cAdvisor部署为一个运行中的daemon，它会收集、聚集、处理并导出运行中容器的信息。这些信息能够包含容器级别的资源隔离参数、资源的历史使用状况、反映资源使用和网络统计数据完整历史状况的柱状图。选择使用cadvisor 是因为前期监控docker。 使用zabbix 自定义python脚本方式调用docker API ,发现当单台宿主机Container数量超过200个实例。Zabbix性能将急剧下降。Cadvisor可分装为container配合Influxdb 时间序列数据库可轻松突破监控性能的限制。

一句命令就可以启动cAdvisor容器，访问8080端口即可看到性能指标数据。cAdvisor可以通过storage_driver参数将数据存到influxdb

sudo docker run \

--volume=/:/rootfs:ro \

--volume=/var/run:/var/run:rw \

--volume=/sys:/sys:ro \

--volume=/var/lib/docker/:/var/lib/docker:ro \

--publish=8080:8080 \

--detach=true \

--name=cadvisor \

google/cadvisor

Grafanan应用

Javascript 开发的前端工具，支持多数据库实例访问 InfluxDB、Graphite、Elasticsearch、CloudWatch、OpenTSDB、KairosDB、Prometheus。自定义报表函数、多格式图表显示（柱状图、曲线图、饼图、块状图）。想在你的Boss面前炫耀一把grafana绝对能满足你。

官方在线演示地址：http://play.grafana.org/

如何有效处理报警信息

在监控系统应用之中最烦恼的就是每天会受到监控系统发送来的上百封告警邮件。特别是在业务应用高峰时期，由于系统的波动将在单一时间多次触发监控系统的告警伐值。这样的情况会给Devops 管理造成一种新的困难。 如何有效filter告警信息，将是判定监控系统有效应用的核心之处。

我们建议分级别、分类型发送告警。

告警级别分类：

Waring：

Error：

告警方式类型：

邮件告警

电话告警

告警策略

类似系统CPU、 load avage 、网络、磁盘IO等在业务系统高峰期易产生波动的监控项设置为waring级别告警，告警方式采用邮件发送。同时应针对当日所发送的告警邮件综合采样分析并且能自动发送每日、每周、每月Top报表，报表包含以下几项：

消耗系统资源TOP10主机

智能排列统计(TOP10)CPU使用率、CPU负载、内存使用率、系统进程数

业务访问效率TOP10

智能排列统计项目平均可用率、总平均响应时间。

可用性统计

智能排列统计各个节点

响应时间统计

智能统计单个项目不同地区、不同线路响应时间

故障策略

系统磁盘空间、进程存活状态，能直接影响用户功能使用及业务健康状态的监控项应设置error告警。同时采用电话语音方式告警。要求能快速准确的告警故障原因，并且能让Devops人员做到第一时间快速解决系统故障。

最新告警消息(TOP10) ：

存储应用

对于监控系统来讲，历史数据的存储和高效率查询，永远是个很难的问题！

数据量大

目前我们监控系统，每个周期，大概有2000万次数据上报（上报周期为1分钟和5分钟两种，各占50%），一天24小时里，从来不会有业务低峰，不管是白天和黑夜，每个周期，总会有那么多的数据要更新。

写操作多

一般的业务系统，通常都是读多写少，可以方便的使用各种缓存技术，再者各类数据库，对于查询操作的处理效率远远高于写操作。而监控系统恰恰相反，写操作远远高于读。每个周期几千万次的更新操作，对于常用数据库（MySQL、postgresql、mongodb）都是无法完成的。

高效率的查

我们说监控系统读操作少，是说相对写入来讲。监控系统本身对于读的要求很高，用户经常会有查询上百个meitric，在过去一天、一周、一月、一年的数据。如何在1秒内返回给用户并绘图，这是一个不小的挑战。

综合以上几点的监控系统对存储系统的要求，我们更推荐使用Influxdb、Elasticsearch类似的时间序列数据库系统。公开的资料显示，influxdb可每秒完成50万写请求。

Influxdb VS Elasticsearch

以下是influxdb 与Elasticsearch读写性能及数据压缩比的对比测试性能报表，可以很明确的得知时间序列数据库influxdb 更为适合作为监控系统的存储系统应用。

后记

神荼已经诞生，他已经拥有了力量去守护我们的产品和服务。正如每一个新生儿一样，他成长的道路仍然漫长。我们期待着他的神力完全发挥的一天，也相信这一天会到来。也许，他的力量可以帮助的不仅仅是我们，也有千千万万跟我们相似的互联网公司！

本文作者：胡毅（点融黑帮），红帽RHCA架构师 ，2016年5月加入点融Devops 团队参与监控系统的研发与维护。多年互联网公司从业经验，熟悉DDOS、CC 网络攻击防御及业务应用系统优化。