盛大云如何监控 OpenStack

如何监控 OpenStack

第一类监控服务: 基本数据监控服务 阿里云在这方面的工作跟盛大云、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做一个折中，设计类似于源数据->显示单元的前端解析框架，可以为同样的数据套上不同的显示单元。

通过这一方式，我们将收集和显示完全解耦，将显示单元也同样暴露给用户可视化复用。