前言

将这个作为云计算系列博文的第一篇是因为平时对数据监控接触比较多。因为是非专业程序员，文中提及的所有想法或者思路可能有误。如果感觉你、你的项目或者你的设计思路被我吐槽了，请不要理会，可以直接x掉这个页面。

正文

关于云监控平台，绕不开 aws 的 cloudwatch。基本上调查下来觉得亚马逊的监控平台做的还是挺靠谱的，比国内盛大的基于snmp的监控不知好多少（我不明白云计算平台怎么会选择用snmp监控，做技术决策的人太没有前瞻性了）。呃 虽然当年我也是坚定的 snmpd 的支持者，但是随着工作时间变长，真的发现在服务器上跑数据收集服务才是王道。

说到云计算，很多人总是专注于云主机什么的。但是从我的角度看，过多的关注云主机最多就是卖vps的命。云计算的具体定义我就不说了，基本上用户买云服务就是为了省钱和省事。云计算的各项基本服务才是关键。当然云主机是所有事情的基础。

设计目标

云计算最大的一个特点是可以很容易的水平扩展和高可用，云监控也不例外。当然在一个成熟的云平台，类似云监控这样的服务基本是构建在云计算其他基础平台上的，比如说：云主机，autoscaling， 消息队列，云存储，RDS等。

一个成功的云监控平台要做到：

1. 可伸缩性
2. 高可用
3. 高可靠
4. 丰富的扩展

设计层次

1. 对外接口，公共API，数据推送入口
2. 稳定的数据传输层
3. 分布式的数据处理节点（计算数据，触发报警等）
4. 稳定的数据存储
5. 用户UI

山寨的设计

metrictools 算是去年下半年业余时间搞的一个玩具（原先的计划是用rocksteady，可惜那玩意用java，而且google那边没有人维护了）。这个项目包含的组件基本上考虑到了以上的情况。

数据入口

项目的数据收集使用了collectd，并且使用自定义的amqp数据导出插件，直接将数据推送到rabbitmq。当然这个rabbitmq要做到高可用，必然需要做集群或者可以换用其他mq消息队列。个人觉得这个部分应该很容易水平扩展，最多对amqp的库做一下自己的封装。或者换用 (nsqd)[https://github.com/bitly/nsq] 和云计算平台自带的高可靠消息队列服务。

数据处理

使用mongodb，可以按照需求进行sharding和备份。需要注意的是在大数据量的情况下，磁盘空间和io会是一个很大的问题。所以数据存多少时间的设置和数据的压缩很关键。数据压缩需要自己额外写程序扫描历史数据，将多个数据合并成一个。数据过期可以考虑使用mongodb自带的数据过期设置。如果有靠谱的RDS的话，也可以尝试。

消息处理

metric_processor 程序会读取rabbitmq里面的数据，然后将数据插入到mongodb和redis。同时会扫描mongodb里面记录的需要计算的报警触发条件或者消息聚合表达式，发现没有被处理，那么就将表达式推送到amqp消息队列。这个部分的处理程序本身是无状态的，即使挂掉也不会导致数据丢失。redis里面所有的数据都是设置过期时间的，基本上只是提供周期内的最新数据和一些临时的中间统计数据。

报警/聚合条件的处理

metric_statistic 读取rabbitmq里面的消息表达式，按照表达式的计算时间定期的触发计算。直接读取redis的当前数据，计算结果会按照表达式的类型，自动推送到报警mq或者插入到数据库。如果某个表达式被程序处理了，那么会定时的刷新mongodb的last modified时间，防止表达式再次被分发处理。呃 当前设计的聚合表达式支持’+-*/()‘，大于小于等额外的逻辑判断是表达式求值完后处理的。

报警消息处理

metric_nofity这个程序负责读取mq里面的报警数据，然后按照用户设置通知。这块应该有更多的插件，而且系统一旦运行后，可能这块改动会比较多。报警消息的退避处理，各种数据输出接口等。

web管理界面

metric_web 主要是负责用户监控数据的请求。监控数据以json格式返回，由用户端的浏览器负责渲染（使用nvd3.js）。除此之外这个程序还负责接受用户以json格式POST过来的设置数据，将设置信息存到mongodb。目前这个只是纯的api接口。静态资源，页面渲染什么的都不考虑。

TODO

这个项目的继续就看心情了。大体的架构定下来了，算是比较符合云计算的要求，也很容易扩展。如果要搞，那么可能会将rabbitmq替换掉，然后加上http的数据推送接口。呃 数据存储端，目前没有什么好的想法。更加深入的话只有自己定制客户端agent（添加collectd插件？）和数据推送库了。