OpenStack与监控系统现状

问题导读：
1、怎么构建一个强壮的云系统环境？
2、云系统监控，需要监控哪些服务？
3、OpenStack如何实现强大的监控系统？






数据监控和展示是云平台中重要的部分，随着节点数目和所需监控对象的数量的增加，一个强大、健全、可扩展的监控系统才能满足各类用户的需求。它是一个云平台非常重要的特性，也是评估一个IAAS的可运维程度的参考。

首先我们需要看看目前众多云平台的监控现状。


第一类监控服务: 基本数据监控服务
阿里云在这方面的工作跟盛大云、Google Cloud Engine类似，主要覆盖了三个基本指标分别是VM的CPU，存储带宽和网络流量。但是目前而言，历史功能都不是太丰富，这些都是基本不可能让SA依赖这些功能去运维的。









第二类监控服务: 多维度数据监控服务
AWS一直是将服务可运维作为一个重要目的，如果AWS在EC2，EBS的努力一样，数据监控和报警在AWS的CloudWatch上体现。

AWS的CloudWatch API设计是作者比较推崇的，它将任意维度、类型的监控指标都可以通过一个简单的模型来集中管理。对CloudWatch不太了解的可以去官方文档一探究竟Amazon CloudWatch Getting Started Guide 。

从下图可以发现CloudWatch的三个重要概念，在Viewing栏是Namspace，在表格栏是Metric，它可以通过不同的dimension来定位。最后是一个Metric在时间维度和统计方法、不同时间粒度的展现。在这里我们可以发现AWS支持的数据监控和展示优点有: 1.数据监控和报表的基本功能覆盖，如时间维度，统计粒度。2. 增加服务或者监控项目非常方便。




上面提到的仅仅是数据收集的方式，CloudWatch的API无疑是非常好的设计。但在显示上CloudWatch无疑还有更多工作，AWS在自己的CloudWatch上并没有太多工作是为了将显示交给用户。这给很多用户带来的不便，提供一个类型多样的显示模板或许能做的更好。


第三类监控服务: 特定类型数据监控服务
ScaleIO是一家致力于与Amazon EBS竞争的存储Startup，同样是寄希望于打破传统存储厂商的壁垒和绑定，ScaleIO提供了软件层面的块存储，并且对SSD，HDD，Network做到了不可知。

不过，现在我们主要关注ScaleIO提供的非常酷炫的监控Dashboard。





通过对存储服务的定制化展示来达到惊艳的效果，把监控当做一个系统的重要亮点。不过，显而易见的是，这类展示是需要额外工作的，在用户方面很难复用这类展示。





在OpenStack如何实现强大的监控系统
从以上不同类型甚至不同产品的监控展示系统上我们可以理出一个对IAAS平台的思路。在IAAS平台上，数据监控从架构角度分为三层，物理机、虚拟机和应用。然后从用户角度可以分为三类需求，普通用户，定制用户和高级用户。普通用户希望直接能使用默认监控项，并且能大部分满足需求。定制用户会适当修改默认监控项显示或者位置。高级用户希望自定义输入，输出，组合监控项。

在数据收集方面，利用OpenStack现有项目Ceilometer的工作，它提供了OpenStack所有Core Project的支持并且具备一个与CloudWatch类似的存储设计和API支持。但是由于Ceilometer目前的局限和CloudWatch API的良好设计上，我们可以结合两者，为Ceilometer同样实现CloudWatch API，这样可以大大增加了Ceilometer的兼容性，带来了CloudWatch社区的广大福利(众多第三方库和数据收集脚本)。目前这个计划已经在社区的bp中。

在数据显示方面，需要补强AWS CloudWatch在这方面的脆弱点，大大加强数据显示上的选择和使用。相对于AWS CloudWatch简单的折线图和ScaleIO的定制化Dashboard做一个折中，设计类似于源数据->显示单元的前端解析框架，可以为同样的数据套上不同的显示单元。通过这一方式，我们将收集和显示完全解耦，将显示单元也同样暴露给用户可视化复用。



举一个例子，用户在OpenStack上建立一个Redis集群并且希望监控给集群，通过CloudWatch社区对于Redis信息收集脚本的支持，用户可以快速在VM上部署脚本然后发送到Ceilometer上。在数据显示上，类似于CloudWatch的查询页面来定制化显示单元，可以为内存使用做成饼图，IOPS做成折线图，容量做成桶图(见ScaleIO的设计)。用户可以发现自定义用户级程序监控会变得极其简单。同理，无论是复杂的集群状态监控还是局部的基础服务健康都可以通过该方式得到，做到了任何展示都是可定义的。

目前监控数据中心存储依赖于Ceilometer的后端存储支持，而Ceilometer现在支持的MongoDB是最完善的，SQLALchemy和HBase支持都不是社区重点推荐。而CloudWatch这类数据模型的存储相较于传统的监控数据存储会带来更多的查询条件和复杂性，支持这些功能都会给数据存储后端带来极大挑战，在监控前端建立一个缓存代理是现在稳妥的选择。