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），視場景而定。

• 時間累積型，一直做累加操作
• 時間值型，只看某個時間的數據值，不疊加任何數據
• 時間率型，時間作為分母，如速率，平均響應時間等。