騰訊內部全鏈路追蹤系統 “天機閣” 的設計與實現
小時光茶社
傳說中天機閣裡有一臺掌控世間一切的機器，萬物執行由此產生。本文的“天機閣”是一個基於鏈路跟蹤的監控系統，後臺開發人員能夠通過“天機閣”洞察“天機”，快速解決問題。
為了支撐日益增長的龐大業務量，業界大量使用微服務架構。服務按照不同的維度進行拆分，網際網路應用構建在不同的軟體模組集上，這些軟體模組可能是由不同的團隊開發、可能使用不同的程式語言來實現、可能布在了幾千臺伺服器，橫跨多個不同的資料中心，分散式系統變得日趨複雜。
如何快速進行故障定位？如何準確進行容量評估？如何動態展示服務的鏈路？如何進行系統性能優化？這是分散式系統給後臺開發同學帶來的四大挑戰。業界都是通過鏈路跟蹤系統來解決以上問題，然而騰訊在鏈路跟蹤方面比較欠缺。為了填補此空白，“天機閣”系統橫空出世。
“天機閣”通過採集、儲存、分析分散式系統中的trace資料、指標資料和日誌資料，完成全鏈路跟蹤，從而解決上述問題。目前天機閣接入了1200+個服務，trace資料上報峰值500萬/分鐘，指標資料上報峰值1.3億/分鐘，日誌資料每天30T。如此海量的資料天機閣是怎樣處理的？天機閣的鏈路跟蹤是怎樣實現的？又是怎樣做到低侵入，低開銷的？這些問題本文將一一為您揭祕。
微服務崛起讓系統越來越複雜
如摘要所述，企鵝電競也採用微服務架構。圖1是企鵝電競首頁介面的依賴關係圖，這張圖大家可能看不清楚，看不清楚才是正常的，因為系統依賴的服務太多了。這種情況下一個請求涉及幾十個服務，若其中某個關鍵服務出現了失敗，只知道有異常，但具體的異常在哪個服務引起的就需要進入每一個服務裡面看日誌，這樣的處理效率是非常低的。
圖1：
企鵝電競首頁介面拓撲圖
後臺開發的痛
微服務的好處不用多說，然而微服務也是一把雙刃劍，其壞處就是系統太複雜，後臺開發者面臨著以下四大問題。
1、故障定位難：一次請求往往需要涉及到多個服務，這些服務很可能是由多個團隊負責的。一旦出問題，只知道有異常，但具體的異常在哪個服務引起的就需要進入每一個服務裡面看日誌，這樣的處理效率是非常低的。最壞的情況可能要拉上多個團隊一起定位。
2、容量評估難：企鵝電競每個月都就有好幾場推廣活動。活動形式還經常變化，導致流量入口經常不同。企鵝電競有500多個模組，不同入口的流量導致各模組的qps增量是不同的，容量評估是一件難事。接入天機閣之前，企鵝電競的每次大型上量活動都需要2個開發同學花一整天的時間來做容量評估，事倍功半。
3、鏈路梳理難：一個新人加入後臺團隊，他在這個微服務體系中接手一個模組，根本不知道自己身在何處，不知道自己的系統被誰依賴了，也不知道自己的系統下游依賴哪些服務，需要看文件，一行行根據程式碼來分析，費時費力。
4、效能分析難：一個服務依賴於後臺多個服務， 如果某介面的耗時突然增加，開發得從自己開始，逐步分析各依賴介面的耗時情況。
業界解決方案
業界都是用分散式鏈路跟蹤系統來解決上述問題。Dapper是谷歌生產環境下的分散式跟蹤系統，算得上各大鏈路跟蹤系統的鼻祖。2010年穀歌發表了Dapper的論文， 之後各大網際網路公司紛紛參照dapper的思想推出各自的鏈路跟蹤系統。包括Twitter的Zipkin，韓國人的pinpoint，Apache的HTrace，阿里的鷹眼Tracing、京東的Hydra、新浪的Watchman等。
我們的出路
騰訊在鏈路跟蹤這塊比較薄弱，需要儘快填補這個空白。以上幾款鏈路跟蹤系統都各自滿足了鏈路追蹤的功能，但落實到我們自己的生產環境中時，這些Trace系統存在諸多問題。 谷歌“dapper”和阿里“鷹眼”並不開源。Pinpoint和zipkin已經開源，然而pinpoint通過位元組碼注入的方式實現呼叫攔截和資料收集，僅能用於java伺服器，Zipkin沒有C++的版本，並且功能不夠用。 最終我們選擇用zipkin的協議，參照阿里鷹眼的架構自建一套騰訊內通用的鏈路跟蹤系統----天機閣。
天機閣介紹
天機閣是什麼
天機閣是一個以分散式鏈路跟蹤為核心的監控系統。它通過採集、儲存、分析分散式系統中的呼叫事件資料，再結合壓測資料和TNM2資料，實現故障診斷、容量評估以及系統梳理等多種功能，大大降低開發人員的運維挑戰， 見圖2。資料採集架構圖見圖11。
圖2：
天機閣功能示意圖
注：“呼叫事件資料”包括“trace資料”、“指標資料”、“日誌資料”三種。
trace資料——指鏈路跟蹤的span資料，主要用於鏈路跟蹤、還原、繪製拓撲圖。
指標資料——指rpc的模調資料，包括分鐘級別的rpc請求量、成功率、延時分佈、錯誤碼分佈等等。
日誌資料——業務日誌。
天機閣有些啥功能
1. 故障定位 ：天機閣利用跟蹤資料，可以還原呼叫鏈，再結合日誌資料，可以快速實現故障定位。例如：使用者投訴他的視訊點贊數不對，開發同學可以根據使用者qq號碼找到投訴使用者的請求trace。 檢視trace詳情就能很清楚的看到該請求在獲取點贊結果的時候超時了，開發同學可以迅速完成定位並處理。Ui介面見圖3。
圖3 ： trace跟蹤ui介面
2. 鏈路梳理 ：有了跟蹤資料，畫出業務拓撲圖就是水到渠成，圖4是企鵝電競某服務的拓撲圖。
圖4： rpc呼叫生成樹
3. 容量評估 ：天機閣的鏈路跟蹤系統，能拿到各服務的呼叫拓撲圖。 指標資料統計模組能拿到rpc指標資料，tnm2系統能獲得服務的部署資訊，根據這些資訊。 壓測系統能壓測出各svr的性瓶頸。根據以上資料，天機閣能精確的評估出各服務的部署是否合理。 若遇到大型活動，開發者只需提供入口介面的qps增量， 天機閣就能預估出後續各依賴服務的qps增量，並給出推薦擴容資料。
圖5：容量評估結果
4. 效能分析 ：天機閣的壓測系統能壓測出單服務的效能資料，結合鏈路跟蹤以及指標統計資料，能很好的分析出整個系統的效能瓶頸，找出優化方向。
5. 其他功能 ：除以上4個功能外，天機閣還有實時告警，過載保護，名字服務，指標資料查詢等多個實用功能，歡迎大家到天機閣系統體驗。體驗地址：http://tjg.oa.com (天機閣擔心資料被意外修改或者洩漏，許可權沒有全員開放，感興趣的同學可以找alexzeng申請許可權)。
天機閣總體架構
天機閣包含鏈路跟蹤、壓測系統、容量管理系統、名字服務四大系統，總體架構見圖6。
鏈路跟蹤系統：鏈路跟蹤是天機閣的核心， 它負責採集、儲存和分析rpc呼叫的trace資料、指標資料和日誌資料，實現快速故障定位、鏈路梳理的功能，見圖6的藍色部分。
壓測系統：提供自動壓測能力，目的是找出各服務的效能瓶頸，見圖6左上角。
容量管理系統：本系統結合trace資料、指標資料、壓測資料和tnm2資料，實現精準的容量評估功能，見圖6粉色部分。
名字服務：這個就不多說了。
圖6： 天機閣總體架構
鏈路跟蹤的技術實現
鏈路跟蹤的原理
Rpc呼叫場景說明
首先來看一個簡單的rpc呼叫鏈場景（見圖7），一個請求通過接入層cgi呼叫下游的svr1，然後svr1先呼叫服務svr2，拿到結果後再呼叫svr3，最後組合svr2和svr3的結果，通過cgi返回給使用者。這裡發生了3次rpc，我們用①②③④⑤⑥表示了RPC的順序，怎麼做到跟蹤還原呢？
簡單地說，天機閣利用rpc框架，在每次rpc的起點和終點進行資料上報。用Jstorm對上報的資料進行實時處理並存入hbase。管理端分析hbase資料進行視覺化展示，以達到鏈路跟蹤的目的。
圖7：簡單的rpc呼叫場景
trace上報資料說明
在天機閣跟蹤樹結構中，每個服務介面是一個節點，節點之間的連線就是span（跨度）。Span是鏈路跟蹤系統中的主要資料結構，它記錄了rpc主調節點和被調節點之間的關係。 Span包含資料如下：
1. traceID ：一次業務請求會分配一個唯一的TraceID， rpc的時候，框架會通過帶內資料的方式吧TraceID傳遞到下游svr，本請求涉及的所有rpc上報的span擁有同一個唯一的2. TraceID， 系統可以通過TraceID把所有rpc的span關聯起來，形成一個span集合。
2. SpanID ：span的ID，每個合併span在一個traceId下有唯一的SpanID。為了方便後續處理，一個rpc的“主調span”和“被調span”擁有相同的spanID，見圖8相同顏色的span的spanID相同。
3. parentID ：父span的id，rpc呼叫有層級關係，所以span作為呼叫關係的儲存結構，也有層級關係，就像圖8所示，跟蹤鏈是採用跟蹤樹的形式來展現的，樹的根節點就是呼叫的頂點。所以，頂級span的parentId=0，拿圖8所展現的例子來說，cgi請求svr1的span就是頂級span，spanID=1，parentid=0。 svr1請求svr2的span是頂級span的子span，spanID=2，parentid=1。而svr1請求svr3的也是定級span的子span，spanID=3，parent=1。很顯然span2和span3是平級關係。這樣就可以把rpc集合還原成呼叫樹了。
4. Event（事件） ：除了呼叫樹，開發者還很關心rpc的時間關係以及耗時資訊。 為此，我們定義了4個rpc日誌事件：
a. client傳送資料：client send簡稱cs
b. client收到回包：client recv簡稱cr
c. server收到資料：server recv簡稱sr
d. server傳送回包：server send簡稱ss
“主調span”會包含cs和cr的時間點， “被調span”會上報sr和ss時間點。“合併span”擁有以上4個事件時間點。有了這些時間點，幾乎所有階段的耗時都可以計算出來。
1. Name： 介面名字，記錄本次rpc呼叫是server的哪個介面。
2. Result：呼叫結果，rpc的返回值，一般0標識成功。
3. Caller：主調資訊，包括主調svr名字，IP
4. Callee：被調資訊，包括被調svr名字，IP、port
5. 其他資訊： span結構體中，還會儲存一些方便分析問題的其他資訊，但這些資訊不影響鏈路跟蹤，這裡就不詳述了。
trace上報過程說明
說到這裡，大家對span的印象可能還是有點模糊不清，於是我們繼續拿圖7的服務呼叫來舉例，如果我們將圖7的應用接入天機閣，將會看到圖8的效果
圖8：span上報細節
一個完整span既包含client資料，也包含server資料，所以一個完整span要分兩次上報。rpc的起點上報的資料稱為“主調span”，rpc的終點上報資料稱為“被調span”， “主調span”和“被調span”也叫子span。 子span在jstorm實時計算的時候，合併成“合併span”儲存到hbase，上報過程見圖8。圖中一共3次rpc，共上報6個子span， 這6個子span在計算層合併成3個合併span， 詳細過程如下：（ 前方高能預警，這個過程比較複雜，對上報過程不感興趣的同學可以跳過 ）。
a. 第1個子span：cgi在發起rpc前，生成一個client span， traceId=111111， spanid=1， parented=0（沒有父span）。並將這3個ID通過帶內資料的方式傳遞給svr1。等cgi收到svr1的回包後，補全span的事件時間：cs=t1， cr=t12，並上報主調span。見圖10中cgi上報的“主調span”。
b. 第2個子span：svr1從請求資料中解出client span， 生成一個“被調span”， “被調span”的三個ID跟起點span一樣，traceId=111111， spanid=1， parented=0。 Svr1傳送回包給cgi後，就補全時間時間sr=t2， ss=t11，並上報“被調span”，見圖10中svr1上報的“被調span”。
c. 第3個子span：svr1在發起svr2的rpc前，生成一個client span， traceId=111111， spanid=2（每個“主調span”生成一個新的spanid）， parented=1（以本svr的“被調span”的id當parentId）。並將這3個ID通過帶內資料的方式傳遞給svr2。等cgi收到svr2的回包後，補全span的事件時間：cs=t3， cr=t6，並上報“主調span”。見圖10中svr1上報的spanid=2的“主調span”。
d. 第4個子span：svr2參照第2步，上報spanid=2的被調span。
e. 第5個子span：svr1參照第3步，上報spanid=3的主調span。
f. 第6個子span：svr3參照第4步，上報spanid=3的被調span。
trace還原說明
天機閣可以從hbase中查出所有spanid=111111的span。 再通過spanid和praentID，可以還原呼叫樹。還能計算各種耗時。 例如：
Cgi的請求總耗時 = span1.cr - span1.cs = t12 - t1
（注：span1指spanid=1的“合併span”）
圖中①的網路耗時 = span1.sr - span1.cs= t2 – t1
Svr1的呼叫svr2的耗時 = span2.cr - span2.cs = t6-t3
Svr1的呼叫Svr3的耗時 = span3.cr - span3.cs = t10-t7
時間差修正
需要注意的是，span的時間戳精確到毫秒，各機器存在一定的時間誤差。 這個誤差會導致耗時計算不太準確。天機閣通過以下辦法，在展示結果的時候進行通過以下兩步進行時間修正（參見圖9）。
1. 保證每個span的cs，sr，ss，cr四個時間點是嚴格順序的，也就是保證t1<t2<t3<t4。
2. 若t1<t2<t3<t4不成立，說明機器的時間偏差較大，則需進一步修正：
t2=t1+((t4-t1)-(t3-t2))/2
t3=t4-((t4-t1)-(t3-t2))/2
注：以上修正是假設圖9中①的耗時跟②的耗時相當。實踐證明這個假設效果不錯。
圖9：時間差修正
鏈路跟蹤架構
天機閣的架構跟阿里鷹眼2016年的架構類似， 分為資料採集、實時計算、資料儲存、離線分析四層，詳情如圖10。
圖10：天機閣鏈路跟蹤架構
資料採集
天機閣資料採集了trace資料、指標資料、業務日誌三類資料。分別儲存在hbase、habo、es和磁碟四種儲存上，見圖11。
圖11：天機閣資料採集架構
1. trace資料 ：就是1所說的span資料，主要用於鏈路跟蹤、還原。儲存在hbase中。
2. 指標資料 ：包括介面緯度的成功數、失敗數、返回碼、耗時分佈等指標資料，儲存在habo系統中。
3. 業務日誌 ：業務日誌分冷、熱兩類，冷資料包括全量日誌，儲存在磁碟上。 熱資料指鏈路跟蹤被取樣且發生錯誤的日誌，熱資料儲存在es系統中。
這三個資料相互配合，可以較好的完成監控和故障定位。 首先，Jstorm實時計算“指標資料”，發現異常後生成告警資訊， 開發同學點選告警資訊，開啟鏈路跟蹤檢視，可以找出故障點。 再檢視跟告警相關的業務日誌，就能大致定位到告警原因（參見圖3）。
資料採集的重點是要做到低侵入和低開銷，只有滿足以上兩個設計要點，業務才有可能選擇接入天機閣。這裡重點討論一下天機閣的“trace資料”是怎麼做到低侵入，低開銷的。
低侵入：低侵入比較簡單， 天機閣選擇在srf框架底層做文章。增值產品部統一使用srf框架， 業務升級新的srf框架，僅重編就能無痛接入天機閣。
低開銷：這裡的開銷是指“正在被監控的系統在生成追蹤和收集追蹤資料的消耗導致系統性能下降”，我們希望把這個開銷降低到可以忽略的程度。 “trace資料”採集最大的開銷在於建立和銷燬span，根span的建立和銷燬需要損耗平均205納秒的時間，而同樣的操作在其他span上需要消耗172納秒。時間上的差別主要在於需要在根span上給這次跟蹤分配一個全域性唯一的ID。減少span的生成，能大大的降低開銷。天機閣通過以下4個手段保證重要事件不錯過的前提下，儘量降低開銷。
1. 取樣上報 ：鏈路跟蹤並不需要所有請求都上報， 天機閣一開始取樣率為1/1024。這個簡單的方案在高吞吐量的服務上非常有效。但是這個取樣率在低吞吐量服務的上，容易錯過重要事件，其實低吞吐量的服務能接受更高的取樣率。 最後我們用一個取樣期望率來標識單位時間內取樣的追蹤。這樣一來，低流量低負載自動提高取樣率，而在高流量高負載的情況下會降低取樣率，使損耗一直保持在控制之下。（注意：這裡的取樣率要求一次請求的多次rpc要麼都取樣，要麼都不採樣，不然鏈路就串不起來， 天機閣在請求入口處進行取樣， 取樣標識通過帶內資料往下游傳遞，保證一次請求用同一個取樣標識。）
2. 染色上報 ：天機閣支援染色上報機制，目前推薦用uin染色， 公司內部的號碼都會被取樣上報。
3. 出錯上報 ：鏈路跟蹤的初衷是幫助開發者定位、分析問題， 那麼請求出錯就很有必要上報了。 出錯上報需要注意兩點。
a. 防止雪崩：如果後端服務故障，會導致前端所有請求都被上報，可能因為上報消耗大量的效能，導致服務雪崩。 為此，天機閣的資料上報設定了一個上限，每秒上報超過50條，就不再上報。
b. 逆向生成：為了降低開銷，未取樣的rpc是不會生成traceID和SpanID的。 若未取樣的rpc發生錯誤，需要從後往前逆向構造呼叫關係。 這種情況天機閣會幫父span生成一個id，並通過回包把父spanid傳遞給主調。主調據此來構造呼叫關係。值得一提的是隻有發生錯誤的分支才上報，未發生錯誤的分支會遺漏，跟蹤樹退化成一條跟蹤線。不過這個退化後的跟蹤線足夠定位問題了。
4. 共享記憶體無鎖上報 ： 上報api將需要上報的Span通過jce序列化成二進位制，寫入本地共享記憶體無鎖佇列中，然後由agent來消費共享記憶體批量上報到kafka，共享記憶體無鎖佇列使用的是即通開源的高效能無鎖共享記憶體佇列，效能可達800w/s。 天機閣的無鎖程式設計細節見KM文章：天機閣——說說無鎖（Lock-Free）程式設計那些事。
效能損失驗證：開啟天機閣上報後，實測qps下降低於3%。測試server的邏輯是 讀取cmem小資料(大約幾個位元組)返回，比較簡單的操作。在cpu消耗差不多的情況下，qps下降2.9%左右，詳細資料見下表。如果業務邏輯更復雜，這個操作的消耗佔比會更低，效能損耗會更不明顯。
圖12： 效能驗證表
實時計算
為什麼選擇Jstorm
天機閣的計算層任務主要包括以下兩點：
1. 把同一個rpc的起點span和終點span合併成一個合併span，並存儲到hbase中。
2. 按分鐘粒度的時間視窗統計指標資料，若發現異常，則通知告警服務。
其中第2點的實時性要求高，適合選用用流式計算引擎。通過下表的對比，當初我們選擇了Jstorm（其實現在Flink在多個方面已經比Jstorm做得更好，我們計劃後續替換才Flink）。
對比
Jstorm
Flink
Spark Streaming
視窗支援:
較為完善，自帶一些視窗聚合方法，並且會自動管理視窗狀態。
視窗支援:
較為完善，自帶一些視窗聚合方法，並且會自動管理視窗狀態。
有視窗支援:
但只能小批量來模擬流式，也就是多個事件的集合。
容錯方式:
ACK機制
檢查點機制：參考flink實現
容錯方式:
檢查點機制：通過分散式一致性快照，對資料流和運算元狀態進行儲存。在發生錯誤時，使系統能夠進行回滾
容錯方式:
同Flink
容災性：
強，並有整套解決方案
容災性：
強
容災性：
一般
實時性：
秒級(精度毫秒)
實時性：
秒級(精度毫秒)
實時性：
分鐘(精度秒)
處理效能：
B6 10億/天 storm 5~6倍
處理效能：
Strom 的3~5倍
處理效能：
Strom 的2~6倍
應用狀態：
成熟、TEG TRC實時計算平臺、阿里Jstorm
應用狀態：
較少、美團、阿里搜尋(Blink)
應用狀態：
較成熟、實時推薦系統
實時計算的挑戰
作為監控系統，需要做到 實時性 ， 一致性 和 確定性 。
實時性比較好辦，Jstorm天生就能滿足此要求，目前天機閣可以在3分鐘左右發出告警，比模調系統快2到3分鐘。
所謂一致性，是指jstorm處理的資料與agent上報的資料一致。 要求系統具備自愈能力， 比如jstorm重啟後，資料能夠被重新計算，監控曲線不能掉下來。天機閣為保證一致性，採取了以下措施。
1. 多地部署，做到異地容災。
2. 利用zookeeper保證master只有一個。
3. 啟用ack機制，保證每條資料被正確的處理一次。
注：啟用ack的弊端也很明顯：jstorm記憶體消耗明顯增大，jstorm處理效能也會下降。 目前天機閣的jstorm叢集機器不足，暫時關閉了ack機制。
什麼是確定性？舉個例子，jstorm發現某一分鐘的請求量突然陡降，這時候我應該發報警，還是不發報警，為什麼我很難做這個抉擇，因為我不知道監控的物件真的出了問題，還是監控系統本身的流計算部分出了問題，流計算系統是不是哪裡卡住了，還是資料收集通道出現了問題。天機閣實現了一個齊全度演算法來完成確定性保障，它與 Apache Flink 中採納的 Snapshot 演算法有些近似。天機閣上報的資料帶有日誌時間， Jstorm的時間視窗以日誌時間為準，如果下一分鐘的的日誌已經超過一定數量，我們認為前一分鐘的資料到齊，可以發出告警。
儲存選型
通過圖11我們可以看出，鏈路跟蹤主要儲存三種資料：trace資料、指標資料、日誌資料。
Trace資料的儲存有以下要求，經過對比，我們選擇用hbase來儲存trace資料。
1. 容量大：目前每天上報量1T， 隨和天機閣推廣，還會倍增。
2. 生命週期：trace資料短時間有用，我們只儲存最近10天的資料，希望過期資料能自動淘汰。
3. 高併發：trace資料寫多讀少，需要支援高併發寫入的儲存。
4. 支援按key讀寫：支援traceID為key存取資料。
指標資料的資料量更大，高峰期達到1億條/分鐘。為了方便檢視，指標資料必須支援多維度賽選，我們最終選擇habo來儲存指標資料。
日誌資料我們儲存在硬碟中。 為了方便查詢，我們把trace相關的熱日誌儲存在es中。
指標資料的資料量更大，高峰期達到1億條/分鐘。為了方便檢視，指標資料必須支援多維度賽選，我們最終選擇habo來儲存指標資料。
日誌資料我們儲存在硬碟中。 為了方便查詢，我們把trace相關的熱日誌儲存在es中。
容量評估的技術實現
原SNG服務部署大量使用虛擬機器， 擴縮容流程重，時間長， 然而業務卻經常搞大活動，微服務架構複雜，每次大活動前，都需要耗費開發資源進行架構梳理以及容量評估。 為了解決這個痛點，天機閣實現了兩個容量評估方式。
-
基於入口的容量評估。
-
基於業務指標的容量評估。
基於入口的容量評估
天機閣能實現精準容量評估，得益於以下幾個要點：
1. 鏈路跟蹤：能自動梳理出某入口的後續依賴關係。
2. 壓測系統：能獲得各server的容量瓶頸。
3. 指標統計：各介面的實際qps等指標資料。
4. Tnm系統：這裡可以查詢各模組部署情況，和各機器的cpu消耗情況。
有了以上資料，我們能計算出各模組當前的容量是多少。 開發同學進行容量評估時，只需要指定入口模組的請求增量，天機閣就能結合鏈路跟蹤，較準確的評估出後續各依賴模組的請求增量。評估出這些模組是否需要擴容，要擴容多少。 那麼如何計算出各模組的請求增量？原理見圖13。
圖13：鏈路跟蹤拓撲圖以及傳導係數
上圖是天機閣通過鏈路跟蹤繪製的一個拓撲圖。圖中A、B、C、D……分別代表一個服務。
線條上的數字4w， 代表該介面被調的頻率。 比如A服務，每秒被呼叫4萬次。 其中A服務每秒呼叫D服務2萬次， D服務總共被調3.8萬次每秒。
圖中綠色數字代表傳導係數，比如A到D的傳導係數是0.5。 因為A被請求4w次每秒，A就會主動呼叫D服務2萬次每秒。 有了拓撲圖和傳導係數，那麼就能很容易的根據入口評估出後續服務的請求增量。如圖13， 假如A的請求增加2萬/秒的請求量。 那麼後續服務將會增加紅色字型所描述的請求增量,見圖14。
圖14：容量評估模型
基於入口的容量評估簡單，精準，圖15是天機閣的實踐評估結果 。
圖15：企鵝電競某活動容量評估結果
基於業務指標的容量評估
“企鵝電競”是接入天機閣的第一個業務。 企鵝電競有一個關鍵指標PCU——同時觀看直播的使用者數。 企鵝電競的大部分服務請求量跟pcu資料正相關。天機閣為企鵝電競專門開發了基於pcu的容量評估模型。圖5是天機閣基於pcu的容量評估結果。詳細評估過程間ＫＭ文章：天機閣容量評估設計與實現。
壓測系統
天機閣的壓測系統導現網流量進行壓測，不需要開發構造請求，僅需要點選個啟動按鈕，就能自動完成壓測，並生成詳細的壓測報告。報告包括壓測結果詳情（圖１6），效能趨勢圖（圖１7），壓測結果環比（圖18），以及其他的一些效能指標。詳細壓測方案見KM文章：壓測系統使用指引。
圖１6：壓測結果詳情
圖１7：壓測效能趨勢
圖18：壓測結果環比
實時告警
天機閣的告警有兩個特點。
1. 實時性高：得益於jstorm的實時計算，天機閣的告警延時在2到3分鐘。
2. 告警收斂：天機閣知道服務的依賴關係，所以可以做到告警收斂， 假如圖14中的D服務故障，那麼會影響到A、B、C三個服務也會異常。 天機閣只會生成一條告警，並把A、B、C與D的關係描述出來。如圖19
圖19：告警收斂
總結&計劃
傳說中天機閣裡有一臺掌控時間一切的機器，萬物執行由此產生。本文的“天機閣”增值產品部開發同學利用業餘時間打造的監控系統，目標便是做到一切盡在掌握，開發人員能夠通過“天機閣”洞察“天機”，快速解決問題。
目前天機閣在故障定位、容量評估、鏈路梳理方面達到了不錯的效果，相當於阿里鷹眼2014年左右的水平，不過距離業界先進水平還有很大差距。革命尚未成功，同志仍需努力， 希望在19年有跟多的愛好者加入到天機閣的建設中來，完成以下計劃，早日窺得“天機”。
1. 推廣：與taf結合，把天機閣api整合到taf框架，方便天機閣進一步推廣。
2. 多語言支援：支援go語言api。
3. 模組化：把採集、實時計算、持久化、告警等流程做成一個個積木塊，業務可按需配置需要的模組，自定義資料處理流程。
4. 平臺化：讓業務可以在天機閣平臺上開發自己的檢視外掛。
5. 全鏈路壓測：按照業務的拓撲圖，實現全鏈路壓測。
6. 關聯識別：把trace跟蹤運維事件（版本釋出、配置變更、網路故障等）關聯，做到初級原因分析。
開源協同。
小時光茶社
長按識別左側二維碼，關注我們漲姿勢