Hadoop Metrics体系架构分析

• context一般不直接实例化，而是从ContextFactory中get出来，首先ContextFactory的实例通过静态方法getFactory()来实例化，在getFactory()的实例化过程中，会读取hadoop-metrics.properties配置，然后依据传入的context名在配置中找到对应的构建方法进行构建，构建完了之后，立即进行初始化。

MetricsUtil类负责上从ContextFactory实例中获取context实例，并且startmonitor。在startmonitor中启动一个timer，这个timer定时类里边，首先调用updater.doUpdates()，然后调用emitRecords();将context中的所有metricsRecord全部通过调用各个context的emitRecord->emitMetrics发送出去

• 从上面也能看出一个context中包含有多个updater（通过Set<Updater>来保存，在updater构造函数中将自己注册到相应的context中），也包含多个Record(通过Map<String,RecordMap> bufferedData->RecordMap extends HashMap<TagMap,MetricMap>->TagMap extends TreeMap<String,Object> : MetricMap extends TreeMap<String,Number>)
• 现有的context包括Filesystem，Ganglia，Nullcontext，当然也可以自己实现一个来达到自己的目的
• 收集到自己所有的数据之后，还需要到hadoop-metrics.properties中去配置一个context，然后让数据（Record在构建函数中绑定context）随这个context而sink出去。
• ganglia中，每个图的命名由contextname.recordname.metricsname组成

• 数据存放在Map<String,MetricValue> metricTable结构，MetricValue保存数值型数据，并且标识出该数据是绝对值还是相对值
• 比较操蛋的是，Record中不会保留过去的数值，只保留最近一次数据（即使是相对数据），所以Record中有个update方法，在这个方法内调用context的update方法，Record中的数值更新到context中对应的Record中去（相对值则会加上context中的老数据）
• 每个Record都有一个RecordName，所以context中即使有多个RecordMap也能通过名字表示出来，然后存放到bufferData中去。
• 在构造函数中，每个Record绑定一个context，通过context将数据sink出去。

• 这个类目的是为了将过程中收集数据更新到信息载体中去，准备发布了，但是谁来发起这个更新呢，如前所述是由context中的timer定时调用的，先更新，后sink。
• 在构造函数中首先获取对应的context，然后创建一个Record（同时将该Record加入到context的Recordmap中去），最后将自己注册到context中。
• 有一个结构为Map<String, MetricsBase> metricsList的来保存这个updater类中所有的统计数据，在update方法中将metricList（MetricsRegistry registry ）中所有的metrics更新到Record中去。
• 基本上每一类需要统计的数据都有一个对应的updater来完成上述的操作
• 在程序运行过程中，需要进行数据统计的时候，就会从updater的
• metrics可以动态添加（RpcMetrics）到metricList（MetricsRegistry registry ）中，也可以预先定义好（NamenodeMtrics），视场景而定。

• 时间累积型，一直做累加操作
• 时间值型，只看某个时间的数据值，不叠加任何数据
• 时间率型，时间作为分母，如速率，平均响应时间等。