关于OpenStack计量、计费与监控的开发与运维实践
本文是UnitedStack平台开发部PTL索广宇在ITA互联网技术联盟开放日上的技术分享。
OpenStack中有很多组件与计量有关，本文主要介绍Ceilometer、Gnocchi、Aodh这几个子项目的架构原理和实践。
针对一个计量和监控系统需要考虑到的问题，可能都有哪些，打算上这样一个系统的时候，主要有三个问题需要考虑，一个是数据收集的问题，计量和监控，收集很多可能各种各样数据；另外一个是存储的问题，这么大量的数据收集过来怎么存储，怎么有效的查询；第三个问题是报警，我收集过来这些数据之后，用这些数据做一些事情，比如报警，能够及时地通知到管理员。Telemetry这三个项目分别就是解决这三个问题的。
这是架构图，这部分是Ceilometer在OpenStack里的一个位置，可以看到和keystone进行集成，和其他各个项目进行交互，把其他整个东西计量起来。Telemetry分三个部分。这是一个消息组件，这是一个数据存储的组建，这边是报警，这是TA的架构图。
Ceilometer是比较早期的项目，后来发现他收集的数据越来越多，能做很多事情。到2013年的时候扩展了，可以做各种各样的东西，可以做自动伸缩这样的。图中绿色的是Ceilometer里的组件，整个图里面有三个Agent，一个API。Agent有四种收集数据的方式。
左边这部分全都是收集数据来用的，在这样一个系统里面可以想象需要考虑哪些问题？然后看一下这个Ceilometer怎么处理这些问题的？首先是如何收集数据的，然后是如何处理这个数据，收集完如何存储的，存储完以后如何访问的，这是这套系统需要考虑的问题。
接下来看一下每部分怎么来解决，首先看一下收集数据，收集数据看到两种Agent，一种是Notification Agent，一种是Polling Agent。
Gathering the Data有一些组件，每一个组件在做一些操作时，都会发出他们的一些操作事件，Agent可以检测这些事件。
Polling Agent有一个循环的周期，会调各个服务的API，可以获取一些监控的数据。通过这样的方式已经收集了很多很多这样的数据。
每一个组件以插件的形式来收集的，我们可以选择性的收集某些组件的事件。这是主动的接收消息的一个组件。另外一种方式是刚才看到Polling Agent，我们去主动拉数据，这些另外一种收集数据的方式。收集到的数据都会把它放到队列里面去做进一步的处理。收集到数据如何处理，又可以分为两个部分。
Transformer做一些什么？做一些转换和处理，或者是做一些延伸的工作，在这个地方我们收集到的虚拟机的CPU的使用时间，过一段时间收集一下。我们想得到的是CPU的使用率，就是Transformer做的事情，根据他们的时间差来算出一个CPU时间一个比值，得到CPU使用率。就像Transformer做这样的事情，和这些原始的数据做一些衍生的工作，Transformer有很多种，可以对自己的数据做一些转换。然后转换数据之后，把这个数据由Publisher发出去了。Sample有很多种发数据的方式，一种是通过消息队列的方式，一种是用UDP的方式，它效率更高一点。
存储数据Sample都有两种数据，一种跟事件相关的一些数据，一种是跟时间序列有关的一些数据。Ceilometer支持把这两种数据存到不同的数据库里面。目前支持Mongo，还支持Hbase，等等。
访问数据通过API访问，从数据库中读出数据。刚刚看到一个图，在这个地方回过头来看一下这个图，这边组件能够以第一种数据方式，搜集事件来把第一种数据收集下来，交给这个Publisher去处理，Compude的Agent收集虚拟机的一些数据。API可以通过API往这里塞数据，这个也是挺有用的。可以让外部的系统，应用程序系统使用。
把你的数据存到这套监控系统里面，给我后期的跟其他组件能够利用起来的监控数据。这是External，这边有监控有报警，报警通过API拿到这些值，根据阈值做一些报警操作。这是Ceilometer的一个架构。针对刚刚提的几个问题有一个解决方案。
这个是目前收集到的一些数据，涉及到计算的数据还有物理的数据，还有IPMI的数据，这几个全都是服务的数据。
Gnocchi的原理和实践
Gnocchi的提出是为了解决Ceilometer性能问题，Ceilometer早期的时候数据模型设计的不是特别好，导致针对这几个数据库的性能都不太好。
Ceilometer因为当初提出得很早，又做过很多转变，导致他数据很灵活。但是性能有些下降。所以专门做了Gnocchi这样一个项目解决他这个问题。这个是Gnocchi对解决问题的一个抽象，抽象出了Resource和Metric两个概念。刚刚提到Ceilometer是两种数据，一个是Resource，一个是时间序列的数据，即Metric，Gnocchi主要就是来存储这些数据的，而Resource是索引，是Resoruce到Metric的索引，这边是随着时间增长，对这些时间数据的索引，就是有哪些资源在Metric做这个事情。
对应的有两种，这种数据库的模型，这边Storage存在时间数据，这边Indexer是Metric的引用。这边的数据库用关系的数据库来存储这些数据。
这是Gnocchi的一个架构图，之所以有这样的组件，可以考虑一个问题，在对这样的数据量很大的监控系统里面，对这个数据库的要求有哪些，其中一个要求就是对它的存储量有很大的要求，数量很大，每时每刻不断的有数据往系统里面塞。对数据库的吞吐能力要求很高，然后就是对查询性能要求很高。
查询数量很大的时候一分钟给反馈结果，是不行的。时间一久规模稍微大一点，有一个月左右的时间，数据基本上查不出来了，给两分钟太慢了。所以查询性能很重要。针对这两个情况，它的设计可以用一句话概括，就是异步的方式处理数据，直接调API写数据，写完之后就不管了，然后有Metricd这个组件，异步地将原始数据做一些分析工作，然后存储下来。
这个Carbonara是时间存储引擎，一个API写完数据的时候，先写到这个目录下面，这上面的一串字就是针对某一个资源某一个指标的索引。每一个数据，这前面是一串，这后面是一个时间说。API写完之后可以返回来，可以由不断的写入，每一次写都打上一个时时间戳，有上面的这个组件Metricd去进一步去处理这些数据。处理这些数据怎么处理呢，就是可以去定义你想要什么样的数据，我想针对我这些原始数据，想要把它找出来最大值，最小值，或者是百分比。这都是自己可以定义，原始数据在这里，你想怎么样处理它就怎样处理。
这是一个对数据分析的Pandas库，对这个原始数据做数据的延伸，可以算出来平均值，最小值，最大值。以及其他类型的数据，所以这个Measure做数据，这个Max是以300秒间隔的数据，把你时间间隔按这种文件分开存储了，这里面每些数据都是按你的时间说进行存储的。查询的时候直接找到某一个指标的某一个数据的某一段时间的数据。
在这边Measure数据用完之后就清除掉了，none数据会做一个存储，对原始数据的保留，以后还会对它继续做延伸工作。你能做哪些延伸也是你可以来决定，大小都是可以自己来定义的。所以看到这个是通过那几个介绍，这是设计的重点原则，水平可以扩展。
这几个图片都是可以属于拓展，API和Metricd都可以无限的扩展，这个可以不断的增加节点，增加数据处理的能力。索引类的数据库可以有很多作用，非结构化的数据实际上有本地的存储。可以做一个延伸的方法，还有是直接跟（Keystone）做集成的。
这是Gnocchi的架构、原理和压测。可以看到它的表现是相当优秀的，这个是5K的数据，可以达到十二五千这样的吞吐量，这个是很不错的性能，这个是SQL作为driver的数据，可以看到你推了4.3M的数据，可以达到175秒的时间，Mongo的强一点。所以对性能提升是非常有帮助的。 这是一个性能差距的压测，基本上是一个常量的值。
Aodh架构
这是Aodh的架构图。这两个如何进行协作的一个东西，叫Tooz，对一个协作的抽象，他后面是协作的组件。Evaluator通过TOOZ来做协作。他达到一个Log，可以做一个Web Hook，可以实现自己发短信，发邮件这样的事情。
目前实现了两种报警，一种是阈值的报警，一种是组合报警。是阈值报警的一个组合，对多个阈值组合起来组成一个报警。
关于作者：
索广宇：现任UnitedStack平台开发部负责人，从事OpenStack相关的工作已有3年的时间，经历了从UOS 1.0到UOS 2.0变革，OpenStack社区活跃开发者，热爱开源，在开放平台、应用开发、企业级服务交付领域有丰富经验。