再来一篇Eoghan Glynn关于Gnocchi的slides。
What's the problem we're trying to solve here?
现有的Ceilometer samples model是free-form metadata的,这就导致了虽然很灵活,但是太heavy了。
-
导致了一系列影响Ceilometer调优的问题:
- 大量的storage footprint。
- 数据摄入是次优的。
- query API是non-scaling的。
API的表达是弱类型的。
Key approaches taken by Gnocchi
- 记录
强类型的resource
attributes。 - 依靠
events
来重构resource state timeline。 -
Eager pre-aggregate
metric data。 - 支持受限的
cross-metric
aggregation。
Compare and contrast ...
classic Ceilometer | Gnocchi |
---|---|
按需的aggregation | Eager pre-aggregation |
resources和samples在storage中是缠绕在一起的 | resources和time-series data拥有独立的storage和data models |
Gnocchi basics
- Resource : cloud resource (instance, volume, etc)。
- Metric : 你想搜集的任何data,靠UUID来辨别,或者name和resourceId的组合。
- Measure:(timestamp, value) 时序的数据点。
- Archive policy: admin定义的数据存储policy。
- 1 second resolution over a day, 1 hour resolution over a year, etc
- 由间隔(in seconds)和保留时间(retention time-span)组成。
- Aggregation:用来汇聚数据的功能(sum, avg, etc)。
- Retention: 不会永久储存源数据,而是储存根据archive policy汇聚后的数据。
Gnocchi aggregation mechanism
Gnocchi Indexer concept
- Gnocchi的主要概念是获取不同metrics的数据点。
- 尽管脱离了resource联系,metrics没有任何实际用途。
- Resources是强类型的attributes。
- Metric用name来做联系。(e.g. "cpu_util")
- 和resources做松散联系的metrics可以用来做cross-aggregate。
- Gnocchi indexer负责来indexing entities, resources和将它们关联起来。
- Resources和它们的attributes是well-defined, typed和indexed。如果resource type对于Gnocchi是未知的,可以使用generic type。
Covering existing ceilometer use-cases
- Alarming to drive Heat autoscaling:依赖跨所有instances的aggregating samples with matching meta-data。
- 使用跨metric的aggregation,基于强类型的resource attributes,而不是free-form的metadata。
- 根据per-sample的resource metadata,重构resource state timeline。
- 使用针对相对罕见的events的queries来获取state的变化。
We're not re-inventing TSDB here
- Gnocchi的可插入式drive model可以利用已有的专业以metrics为导向的DB (InfluxDB and OpenTSDB)。
- Gnocchi自己基于Pandas和Swift,提供了规范的存储驱动。
- 在专业TSDB use-case中,Gnoccchi管理resource-metrics关系和抽象的archive policy概念。
Ref
Eoghan Glynn http://www.slideshare.net/EoghanGlynn/rdo-hangout-on-gnocchi