OpenStack/Gnocchi简介——时间序列数据聚合操作提前计算并存储起来，先算后取的理念

先看下 http://www.cnblogs.com/bonelee/p/6236962.html 这里对于环形数据库的介绍，便于理解归档这个操作！

转自：http://blog.sina.com.cn/s/blog_6de3aa8a0102wk0y.html

早期的OpenStack监控（遥测）项目ceilometer被一分为四（Ceilometer、Gnocchi、Aodh、Panko），各司其职！其中Ceilometer负责采集计量数据并加工预处理；Gnocchi主要用来提供资源索引和存储时序计量数据；Aodh主要提供预警和计量通知服务；Panko主要提供事件存储服务。促成Ceilometer分裂的主要原因是：早期各类资源的计量数据（即是时间序列数据）（measurement，核心字段是<</span>时间，值>）存储在SQL数据库中的sample表中；随着云环境中需要被监控的资源增多和时间的推移，计量数据的增长变得难以预测；计量数据的使用方面，查询操作首先要从巨大的sample单表中过滤所需条目，然后还会涉及到相关的聚合计算；可想而知，由此带来的性能开销绝对是无法忍受的，并且随着时间的推移这个瓶颈会愈加明显直至奔溃。要解决上述问题方法有很多，比如分表：每个监控指标（Metirc）一张表，那么一个资源可能会有多张表（比如一个instance至少会有cpu，cpu.util，memory，memory.usage，disk.* 等监控指标metrics）；这似乎有点夸张，即使这样都可以接受的话，那么查询时对计量数据的聚合操作也还是个问题。

类似的思想，红帽的Julien Danjou（blog：https://julien.danjou.info/blog/）发起了Gnocchi项目来解决这类问题。其总体思路是：把各个计量指标Metric的计量数据measurement直接写入后端存储中；并在measurement写入之前根据预先设定的归档策略进行聚合操作；查询时直接读取对应的文件即可获得聚合后的监控信息点，显然时间复杂度变为O(1)了；并且提供资源索引，这样能更快的找到每个资源的基础信息metadata和其相关的metrics信息。

OpenStack/Gnocchi简介和架构[附文档翻译]

文档翻译（欢迎雅正）：http://gnocchi.xyz

第一部分：Gnocchi简介 http://gnocchi.xyz/index.html
Gnocchi – Metric as a Service，Gnocchi计量作为一种服务
Gnocchi是一个多租户时间序列，计量和资源数据库。提供了HTTP REST接口来创建和操作数据。Gnocchi设计用于超大规模计量数据的存储，同时向操作者和用户提供对度量和资源信息的访问。
Gnocchi是OpenStack项目的一部分。因此它支持OpenStack，但也能完全独立的工作。
您可以在 http://gnocchi.xyz上阅读完整的在线文档。
Why Gnocchi?为什么使用Gnocchi？
Gnocchi已被创建满足在云计算环境中可用的时间序列数据库的需要：提供存储大量度量数据并且易于扩展的能力。
Gnocchi项目于2014年开始，作为OpenStack Ceilometer项目的分支，以解决Ceilometer在将标准数据库用作计量数据的存储后端时遇到的性能问题。更多信息，请参见Julien的博客Gnocchi。

Use cases，使用案例
Gnocchi旨在用于存储时间序列及其相关联的资源元数据。因此，它有用的例子如：
（1）计费系统的存储；（2）报警触发或监控系统；（3）数据的统计使用。

Key Features，关键特性
HTTP REST接口 水平可扩展性 度量聚合 测量批处理支持 存档策略 计量值搜索
结构化资源 资源历史 可查询资源索引器 多租户支持 Grafana支持 Statsd协议支持

第二部分：Gnocchi的架构 http://gnocchi.xyz/architecture.html
Project Architecture，项目架构
Gnocchi由几个服务组成：一个HTTP REST API（请参阅REST API Usage），可选的statsd兼容守护程序（请参阅Statsd守护程序使用）和异步处理守护程序。 通过HTTP REST API和statsd守护程序接收数据。异步处理守护程序（称为gnocchi-metricd）在后台对接收到的数据执行统计计算，度量标准清除等操作。
HTTP REST API和异步处理守护程序都是无状态的，并且是可扩展的。可以根据负载添加其它workers。

Back-ends，后端
Gnocchi使用了两个不同的后端存储数据：一个用于存储时间序列（存储驱动程序），另一个用于索引数据（索引驱动程序）。
存储器负责存储所创建的度量的计量值measurement。它接收时间戳和值，并根据定义的归档策略预先计算聚合。
索引器负责存储所有资源的索引，以及它们的类型和属性。Gnocchi不仅了解来自OpenStack项目的资源类型，也提供了一个通用类型，因此您可以创建基本资源并自己处理资源属性。 索引器还负责将资源与度量指标metric相关联。

How to choose back-ends，如何选择后端
Gnocchi目前提供了集中不同的存储引擎：File，Swift，S3，Ceph（首选）。
Storage的驱动程序基于一个名为Carbonara的中间库，由该中间库处理时间序列操作，因为这些存储技术本身都不能处理时间序列。
四个基于Carbonara的驱动程序运行良好，并且后端技术保证可扩展性。 Ceph和Swift本身就比文件驱动器更具可扩展性。
根据您的体系结构的大小，使用文件驱动程序并将数据存储在磁盘上可能就足够了。 如果需要使用文件驱动程序扩展服务器数量，则可以通过NFS在所有Gnocchi进程中导出和共享数据。在任何情况下，显然S3，Ceph和Swift驱动程序在很大程度上更具可伸缩性。Ceph还提供了更好的一致性，因此是推荐的驱动程序。

How to plan for Gnocchi’s storage，如何规划Gnocchi的存储
Gnocchi使用基于Carbonara库的自定义文件格式。在Gnocchi中，时间序列是点的集合，其中点是在时间序列的寿命中的给定测量或样本。使用各种技术压缩存储格式，因此可以基于其最坏情况情况使用以下公式来估计时间序列大小的计算： 点数×8字节=以字节为单位的大小
您要保留的点数通常由以下公式确定： 点数=时间跨度÷粒度
例如，如果您想保留一年的数据，一分钟的分辨率： 点数=（365天×24小时×60分钟）÷1分钟 = 525 600。然后：字节大小= 525 600字节×6 = 3 159 600字节= 3 085 KiB
这只是一个聚合时间序列。如果归档策略使用具有相同“一年，一分钟聚合”分辨率的6个默认聚合方法（mean，min，max，sum，std，count），则使用的空间将最多增加到6×4.1 MiB = 24.6 MiB。

How to set the archive policy and granularity，如何设置归档策略和计量粒度
在Gnocchi中，归档策略以点数表示。如果归档策略定义了10点的策略，粒度为1秒，则时间序列归档将保持长达10秒，每个代表1秒钟的聚合。这意味着时间序列将最多保留最近点和最旧点之间的10秒数据（有时多一点）。这并不意味着它将是10个连续的秒：如果数据被不规则地时间间隔送达，可能存在间隙。
相对于当前时间戳没有数据到期。此外，您不能删除旧的数据点（至少现在）。
因此，存档策略和粒度完全取决于您的用例。根据数据的使用情况，可以定义多个归档策略。典型的低粒度用例可能是：
3600点，粒度为1秒= 1小时
1440点，粒度为1分钟= 24小时
720点，粒度为1小时= 30天
365分，粒度为1天= 1年
这将表示每种聚集方法6125点×9 = 54 KiB。如果使用8标准聚合方法，您的指标将占用8×54 KiB = 432 KiB的磁盘空间。

Default archive policies，默认的归档策略
默认情况下，使用默认存档策略（在default_aggregation_methods中列出，即平均值，最小值，最大值，总和，标准值，计数）创建3个归档策略：
low（每个metric的最大估计大小：5 KiB）
5分钟粒度1小时；1小时粒度1天；1天粒度超过1个月
medium（每个metric的最大估计大小：139 KiB）
1分钟粒度1天；1小时粒度超过1周；1天的粒度超过1年
high（每个metric的最大估计大小：1 578 KiB）
1秒粒度；1分钟粒度1周；1小时粒度超过1年