F-22戰斗機是第五代隱身戰斗機，其各項能力是世界公認的名列前茅，能夠“Control the Sky”。F-22的綽號為“Raptor”，譯為“猛禽”。而這正是美團可觀測性平臺Raptor名稱的由來。

Raptor作為美團的可觀測性平臺，融合了前端監控、基礎設施監控、應用層監控，同時也給業務提供指標、鏈路、部分日志監控能力，并提供豐富大盤報表及實施告警功能。

在WOT全球技術創新大會2023·北京站的《可觀測性技術與實踐》專場中，來自美團的技術專家任天帶來了主題為《美團可觀測性平臺：Raptor建設與實踐》的精彩分享，詳細介紹了Raptor的“飛天”建設之路。

如何“Control the Sky”？

如何在互聯網中監控一切？什么樣的架構設計才能滿足可觀測性平臺的需求？美團首先從可觀測性平臺的特點和業務使用方式入手，總結出“全、快、準、穩”四個特點，根據特點將整體的可觀測性平臺分為橫向和縱向，通過分層設計和監控能力建設，從而搭建出美團可觀測性平臺Raptor。

可觀測性平臺的橫向分類是基于業務流量訪問圖，因此美團從橫向進行產品分類時將Raptor分為三層：監控移動端APP、瀏覽器、H5小程序以及其他容器的大前端監控，面向實際后端業務開發的應用層監控，以及面向基礎設施監控的系統層。

縱向分類是從可觀測性平臺監控的角度出發，分為指標、鏈路和日志。基于此，美團為Raptor構建了以指標為主的監控體系架構，通過指標體系監控對象的運行狀態；而日志和鏈路更側重于異常分析或者個案分析。

在Raptor的前端領域中，監控指標分為請求類指標和自定義指標；應用層則拆分成Transaction、Event、Problem和Business四類指標。這些指標可以進行串聯，比如將Transaction、Event和Problem串聯，從而構成整個進程內的鏈路監控。除此之外，還有面向主機側監控的系統層、面向K8s集群內監控的Mps和美團自建的進程間鏈路的監控系統Mtracer。

而無論是橫向還是縱向分類，Raptor都是基于全方位、可擴展和高可用的設計原則。若想滿足這些原則，分層設計是最好的選擇。因為分層設計的可觀測性平臺擴展性強、各端領域的監控邏輯相對統一，并且告警、降采樣等技術能力可以得到重用。因此Raptor分為采集層、接入層、存儲層、分析層和應用層，每層根據應用的特點進行獨立設計。

為Raptor建設“飛天”之路

整體介紹完Raptor的設計后，任天著重介紹了Raptor的建設實踐之路，以及Raptor如何“飛”上天空。

首先第一個建設是應用層監控——開源版Cat。Cat基于流式的處理流程，實時性很強；其監控類型也非常豐富，能夠基本覆蓋用戶所有的需求。同時，美團對可觀測性平臺的推廣覆蓋度較全，對PaaS或中間件都制定了較為嚴格的埋點規范。基于以上特點，Cat能夠生成更加豐富的報表類型。

應用層Cat功能雖強大，但由于Cat是侵入式埋點，所以也會侵入到業務進程中。因此，需要在保證高可用狀態的同時，避免影響業務的核心流程。SDK的設計就尤為重要。

美團的SDK設計是通過內存隊列和整個處理邏輯進行解耦。當消息通過埋點API構建時，會進行消息采樣。被采樣到的消息進入內存隊列中，后續的Sender線程能夠發送數據；沒被采樣到的指標也會保留，并在本地預聚合。這種設計能夠避免因采樣失誤導致的指標數據不全、不準。

此外， SDK層還能高效上報協議，并且處理邏輯與業務核心線程是獨立的，保證在出現問題時業務也能正常運轉。

Cat和SDK的建設使后端服務有了監控能力，但這樣就能滿足業務的可觀測性訴求了嗎？答案必然是“否”。

如果后端服務正常，中間網絡出現問題，用戶同樣無法正常使用。因此還需要建設大前端領域的監控，從用戶端視角觀測端到端的鏈路。

大前端的監控處理數據流程相對簡單。首先在APP、Web、小程序中嵌入內置的SDK采集接口性能。數據到處理層后，處理層會統計每個接口的成功率、響應時間以及APP或小程序的性能和開銷。如果有錯誤日志則會采集錯誤日志。此外，在RN動態容器中也會存在一些自定義監控。

那么現在已經具備了大前端和后端服務的監控能力，應該可以滿足開發人員的訴求了吧？答案依舊是“否”。因為后端服務在基礎設施中運行，所以還要監控設施。

美團建設了針對基礎設施的系統層監控，也稱之為Hosts監控。在Hosts監控的流程中，第一步是Agent進程采集本容器中的基礎指標，同時對每個進程提供監控能力。在進程內可以通過開放接口調用Agent監控線程池隊列；Pass組件則可以監控接口連接、流量等。所以相較于應用層，系統層是從進程外的視角監控整個狀態。

對于K8s集群的使用人群，美團還建設了MPS，能夠提供K8s集群視角的監控能力。

當這些層次都建設完畢后，Raptor的監控功能已經相對完善，但監控指標散落在各個領域，查看起來非常不方便。所以美團建設了大盤領域。

大盤領域提供數據匯總的能力，通過配置可以將各個領域的監控數據整合在一張圖中，展示的圖表類型也非常豐富。還可以關聯告警，在機房故障或大促時配置大盤值守，從而判斷服務是否正常。在運維方面，也可以配置運維大盤進行觀測。

加上大盤領域后，Raptor基本覆蓋了美團的業務場景，能夠一站式解決可觀測性訴求。

但可觀測性團隊沒有止步于此。為了更加完善Raptor，團隊在實際業務中尋找用戶痛點，提取其中共性并進行改善。

團隊總結出解決痛點的四個關鍵詞：復用、升級、新建和開放，隨后進行完善建設。

完善Raptor的第一個建設是對存儲進行分級，也就是冷熱分離。同時對數據進行降采樣，保證存儲舊數據時存儲力度足夠粗。另外在設計過程中，由于每個領域的監控訴求不一樣，所以存儲設計也不一樣。

第二個建設是針對降低時延設計的架構。當用戶Client將可觀測數據上報到接入層后，查詢層查詢存儲設備的同時，也能直接在接入層的內存查詢，從而保證數據上報后立即展示，整個時延在秒級以內。除此之外還有容災和隔離性的建設。

Raptor的“實戰”表現

綜合以上Raptor的所有建設和能力，可以說Raptor從宏觀的觀測角度到具體細節共分為五個層次：大盤、端到端、應用層、系統層和鏈路。這五個觀測領域能夠滿足不同觀測員、不同階段的觀測需求。當遇到問題時，觀測員可以逐級向下使用。

這種觀測鏈路在實際應用中有什么優勢？當觀測員檢查公司Hbase服務的可用率時，不僅可以看到整體的可用率，輸入具體集群名稱還可以查看具體集群的可用率。從宏觀到微觀都可以進行觀測。

另一個實際案例是故障排查。當觀測員收到Hbase可用率告警時，排查思路首先是使用Hbase客戶端檢查Client服務是否有網絡故障或使用參數不符合預期，從Client視角排查報錯的監控指標。確認Client正常后，再排查Hbase集群服務指標是否正常。這種方式可以監控整個鏈路，無論是Client還是Hbase導致的問題都能被排查。

這種故障排查方式應對的是后端問題，偏重后端服務。而端上的故障排查則在大前端領域進行。當發現某URL成功率下降，可以觀測該URL對應的具體后端服務指標是否正常。如果后端服務指標正常，則可以基本確定是中間網絡層出現問題。這種排查方式可以將自身服務、端上服務和中間網絡層服務全部納入。

在未來，Raptor會“飛”得更高更遠

若想飛得更高更遠，則需要克服面臨的困難并規劃好未來路線。在分享的最后，任天談到了Raptor面臨的挑戰和未來規劃。

第一個挑戰是容災。在容災過程中，不僅需要保障自身機房容災性，還要保障外部依賴的機房容災性，從而確保可觀測性平臺的可用性和穩定性。所以在未來需要減少外部依賴并提高全鏈路容災降級能力。

第二個挑戰是建設拓撲鏈路。現在美團大部分的服務都是微服務，微服務及其接口的調用量巨大，關系復雜，所以需要進行梳理。針對這一挑戰，未來需要重點建設全量拓撲鏈路和技術運營，包括分析根因定位及上下游鏈路。

除此之外，任天還提及到了其他的三點規劃。第一點是精細化可觀測性，從分鐘力度到秒級力度，甚至到亞秒級力度，以及擴展維度。

各個系統也有規劃，比如將指標、鏈路和日志進一步深度融合，從而更好地定位故障；還有將監控系統與企業內部系統、運營系統打通。

最后是運營規劃。可觀測性系統不僅用來觀測，未來也會用于運營，比如運營人員分析訂單量從而運營業務指標。

在未來，期待Raptor“飛”得更高更遠！以上內容整理自美團技術專家任天在WOT全球技術創新大會2023·北京站《可觀測性技術與實踐》專場中的精彩分享。獲取完整PPT請關注51CTO技術棧公眾號，后臺發送【WOT2023PPT】即可直接領取。