天機閣——全鏈路跟蹤系統設計與實現

傳說中天機閣裏有一臺掌控世間一切的機器，萬物運行由此產生。本文的“天機閣”是一個基於鏈路跟蹤的監控系統，後臺開發人員能夠通過“天機閣”洞察“天機”，快速解決問題。

爲了支撐日益增長的龐大業務量，業界大量使用微服務架構。服務按照不同的維度進行拆分，互聯網應用構建在不同的軟件模塊集上，這些軟件模塊可能是由不同的團隊開發、可能使用不同的編程語言來實現、可能布在了幾千臺服務器，橫跨多個不同的數據中心，分佈式系統變得日趨複雜。

如何快速進行故障定位？如何準確進行容量評估？如何動態展示服務的鏈路？如何進行系統性能優化？這是分佈式系統給後臺開發同學帶來的四大挑戰。業界都是通過鏈路跟蹤系統來解決以上問題，然而騰訊在鏈路跟蹤方面比較欠缺。爲了填補此空白，“天機閣”系統橫空出世。

“天機閣”通過採集、存儲、分析分佈式系統中的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天生就能滿足此要求，目前天機閣可以在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跟蹤運維事件（版本發佈、配置變更、網絡故障等）關聯，做到初級原因分析。

轉載來自公衆號“小時光茶社”：https://mp.weixin.qq.com/s/RBPJFrj2mcTUjbm4aH9TRg