Telemetry，直译为遥测技术。在openstack中，是一个服务的名称，主要负责采集openstack中各组件资源使用率等关键数据
Telemetry，也可以看成是在openstack中负责Telemetry服务开发团队的名称。在2016年4月发布的Mitaka版本为止，Telemetry包含三个项目：
数据采集是Telemetry的核心。可以为监控系统提供资源实时健康状态数据；可以给计费系统提供资源使用率等信息。ceilometer提供的数据采集覆盖了所有的openstack项目：
计算（nova），主要包含云服务器的使用情况数据存储（cinder、swift），块存储、对象存储数据网络（neutron），包含公网ip、带宽、路由等在内的所有网络相关数据认证、授权（keystone），用户管理、认证等相关的数据甚至还支持IPMI协议，采集物理环境的数据从openstack外部看ceilometer，他是openstack对接外部监控告警系统、计费系统的唯一接口，提供整个云环境中资源的数据以供其他系统使用
Ceilometer在openstack中扮演着收集所有需要关注的数据的角色，其实社区对于数据采集有一个更高层次的认识：“成为数据采集的一种标准，而不管数据的来源为何，也不管数据将被用来做什么”。这么一来，所有数据采集的工作，都可以按照ceilometer的设计来实现，比如你的网站的访问量、博客阅读量，甚至其他类似停车场的进出车辆数据的采集，都可以使用ceilometer的设计来实现
关于Aodh项目，Telemetry团队的认识也是摇摆不定的，经历了几个阶段：
aodh独立于ceilometer，作为一个单独的项目aodh合并到ceilometer中，ceilometer-api的一部分、ceilometer-alarm-evaluator、ceilometer-alarm-notifier的全部就是aodh在ceilometer中的实现（具体版本不大清楚，大致开始于H版本，Kilo是合并在一起的最后一个版本，但实际发布是在Mitaka）到了Mitaka版本，aodh再次从ceilometer中独立出来。从社区对于Telemetry的定义来看，这必然会成为定局，此后aodh跟ceilometer彻底分开，ceilometer专注于数据采集，aodh作为ceilometer上游的一个应用继续发展Aodh在ceilometer采集数据的基础上，作为数据的实际使用用户，是基于ceilometer采集到数据的应用的一个具体例子而已，未来还会有更多类似的应用项目出现
Aodh向更上层的应用提供REST API，让更上层的应用可以通过这些API来创建告警策略，来对云环境中的资源进行实时的监控。周期性的告警评估保证了监控的颗粒度，告警评估的结果必然是“数据不足”、“告警”、“正常”三种状态中的一种，策略中还可以定义每种状态触发后采取的下一步动作。比如监控云服务器，当CPU利用率达到95%时，给指定的url发送请求，这个url的具体实现视个人需求，可以发送邮件通知、短信通知等
关于这个项目，因为在平常工作中没有实际的使用经验，对于项目的理解仍然停留在官方文档的描述上，我会尽最大努力不要犯错
社区的定义是“时间序列化的、度量、资源的数据库”，数据库自然以存储数据为主，在ceilometer中有太多太多的数据需要存储了，并且跟资源总数、运行时间正相关，数据会不断的呈线性增加。除了大容量的问题难以解决外，还必须要解决响应速度的难题，在ceilometer中，如果我想查看某云服务器最近一年的峰值（统计学概念。要得到峰值，至少需要指定统计步进，一个步进内可能有很多个采样点，从这些采样点中计算得到最终的峰值，并且指定的步进不同，得到的结果也不同），这需要大量的计算。gnocchi能否在ceilometer的这两个难题上提供非常可观的改善？还有待实际的验证。希望可以彻底解决ceilometer的两大难题