ceilometer yoga版本小结

背景

总结下ceilometer yoga版本工作原理，主要看下版本间不同点，publish指标流程

博客涉及代码均为开源公开代码

概述

ceilometer-polling

包含组件ceilometer-agent-compute和ceilometer-agent-central，hardware的主机指标合并到central里了

hardware

封装到central的hardware.snmp里，实际代码看着也不是主机相关的

看完了，虽然叫hardware，但应该没有主机相关的东西

更正，hardware封装到central了，的确是主机的东西，默认不采主机的，不过可以通过手动配置实现对主机采集

加载过程

hardware已经不存在了，指标放到了AgentManager初始化中的extensions_fb中加载

hardware对应的endpoint放到了central下

指标都放到了hardwaer.snmp里，和低版本ceilometer指标直接放在entry_points加载不同，yoga版本通过python开源三方模块stevedore从hardware.snmp再次加载

看到hardware指标加载先用stevedore ExtensionManager加载，获取到GenericHardwareDeclarativePollster对象，再用ExtensionManager.map方法调用GenericHardwareDeclarativePollster的get_pollster_extensions方法

看下ExtensionManager的map方法和get_pollster_extensions方法

GenericHardwareDeclarativePollster.get_pollsters_extensions

看到hardware指标其实是加载snmp.yaml获取的，每个指标pollster其实都是GenericHardwareDeclarativePollster对象，只是指标名字不同，日志里看的是不同名字，调测发现是相同的对象

discover

如果在yaml配置文件中配了resource则不调discover

获取resource

虚机相关resource，默认先从yaml配置文件中读取，如果读取不到再调用manager的discover方法获取。默认的discover好像会获取虚机的数据，此处如果要获取主机信息，可以手动配置resource为主机资源的resource。

如果配置snmp，resource可配形如snmp://127.0.0.1

采集逻辑

公共接口get_samples，调用对象如下

主要逻辑：

根据配置文件中信息，作为入参调snmp接口获取目标信息

GenericHardwareDeclarativePollster实际调用snmp inspector的inspect_generic接口获取数据，inspect_generic获取数据会调很多接口，其中一个重要的是_query_oids，看着会调snmp接口直接获取指标数据，如果配置文件有处理函数，则获取指标数据后再post处理

snmp接口调用原理和流程待总结

默认配置文件snmp.yaml

就这一步，很奇妙

notification

采集完指标发到notification，notification再发到我们需要的地方

接收与转发

notification监听队列，收到polling发送的消息后会转发到对应的endpoint

endpoint加载/etc/ceilometer/pipeline.yaml，根据yaml中的sink，publish sample到对应的sink，默认是gnocchi，调对象的publish_samples方法

流程(重要）

notification初始化创建监听，先加载两个pipeline manager（meter，event），加载manager只传入conf参数

pipeline manager初始化时会加载pipeline，加载pipeline.yaml给pipiline赋值。注意pm_pipeline, pm_source, pm_sink

pipeline manager初始化完成后，notification加载pipe manager里的endpoint，endpoint用来作为参数传入notification监听，监听到后会交到对应endpoint处理

notification的endpoint处理可以看作publish过程。publish由context实现，context会先交给sample pipeline publish，sample pipeline会publish到sample sink，sample sink交给自己的publish对象去publish（sink的publish对象在pipeline初始化时加载服务的endpoint文件获取，然后创建sink时传给sink用，publisher用哪个定义在pipeline.yaml，默认gnocchi），调gnocchi publish对象的publish_samples方法

gnocchi publish

组装数据，调gnocchiclient处理，目前看主要有两个处理，batch_measuers和update resource

大体逻辑是先排序，再按resource_id分组指标，再按组组装gnocchi可处理的指标形式，再调batch_measures和update_resource

batch_measures是将采集的指标存储

update_resource是更新resource，是指标所在的东西，比如虚机，网卡等都以resource粒度存在

batch_measures

组装的数据主要由两个字典，measures和gnocchi_data，两个字典的key都为resource_id，value都是一个字典

gnocchi_data的值有三个字段，分别为resource_type, resource, resource_extra

resource_extra调resource definition的attribute组装，attributes定义在yaml中，默认是gnocchi_resources.yaml，解析出来后的attributes大概这样

发现attr的值也是一个字典，而rd.sample_attributes就是匹配sample和attributes字段然后组装数据到gnocchi_data里

measures里会增加指标采集的值

最后batch_measures调gnocchiclient发送请求，self._gnocchi就是gnocchiclient对象

update_resource 

publish_samples会调用_if_not_cache，这个函数是根据是否cache去gnocchi更新resource

cache信息从oslo_cache加载默认配置，默认不cache，此时_if_not_cached直接更新resource

也是调gnocchiclient更新resource

区分若干yaml

gnocchi_resource.yaml notification转发指标进行publish时格式转换，加载这个yaml，给gnocchi publish时，生成发往ghocchi的数据目标格式

pipeline.yaml notification启动服务时加载pipe manager使用

polling.yaml ceilometer采集指标时需要采集的列表，默认通过加载polling.yaml获取