前言

無論從最早期的unix作業系統,還是曾經大行其道的單體式應用,還是現在日益流行的微服務架構,始終都離不開監控的身影。如windows的工作管理員,linux的top命令,都可以看作是監控的面板。

再聯絡起現實生活,無處不在的路網攝像頭,為交通機關監控交通人流提供了方便。

系統規模越大,越離不開監控。缺少了監控,就像盲人摸象,窺不到全貌。

理想中的分散式監控

進入網際網路時代,系統呼叫規模日益龐大,對監控的需求更是迫切。比如一個頁面開啟很慢,怎麼分析哪裡慢?是網站接受請求慢還是連線資料庫慢,或者訊息佇列掛了,或者redis請求慢?我們需要監控系統能提供這些資訊供我們追蹤分析。

所以理想中的分散式監控應該記錄從請求發起那一刻,所呼叫的公開方法,接觸過的資料庫,快取,佇列等步驟,以及每一步所消耗的時間。這些都需要大量的日誌去記錄。

第二點,理想中的分散式監控必須是對程式碼無侵入,應用程式設計師無需對每個方法去呼叫監控程式碼。這樣完全解藕的監控系統,才更容易使用,加入每個方法,都要調一下監控介面,那不要累死人,程式碼也及其不友好。

第三點,理想中分散式監控應該對效能不造成損耗或者極小的損耗。如果流量一大,監控系統CPU飆生的話,那這個監控無疑是失敗的。

第四點,許多方法有層級,方法內呼叫其他方法,應該能通過報表聚合檢視,進入每個方法的時間以及呼叫耗時,呼叫方法的層級樹。

第五點,分散式時代,一個呼叫請求會橫跨很多站點,理想的分散式監控應該提供呼叫鏈上所有站點的聚合報表檢視,要極力避免死迴圈,兩個站點長官相互呼叫的情況下,應該用雙箭頭表明呼叫關係。

第六點,能提供接入監控的伺服器cpu,記憶體,硬碟空間等指標,並根據警戒線傳送通知。這個優先順序可以降低,可以藉助雲伺服器自身提供的監控,阿里雲和Ucloud都有自己的伺服器監控面板。

如何設計一款實用的監控

統一的呼叫鏈id

根據軟體的呼叫鏈特性,從一個請求開始到最終的結束,應該具有一個統一的呼叫鏈id

時間戳

呼叫各種方法的時間也應該是順序的,需要一個精確的時間戳,來描述呼叫方法的進入與離開的時間。

非同步傳輸

為了不影響效能,應該以非同步傳輸,定時落庫的方式。

延時聚合

如果能做到實時聚合更好,如果實現困難可以採用延時聚合報表,延時的時間應該小於一分鐘。這個時間使用人群應該能接受,當然如果能縮短到幾秒鐘,那使用人群會更加高興。聚合報表應首先提供最近時間內的耗時排序,可以檢視呼叫的方法樹,可以檢視呼叫鏈的所有站點,其他需求可以後期開發,解決核心需求。

最後的難點

如果不追求無侵入,提供一個空介面。所有需要記錄日誌的實現介面,就已經達到了目標的一半。

為了完成對應用無侵入的目標,我們首先需要一款真正的aop,即靜態編織Aop,這個只聽說過postsharp,為什麼只有它能實現?或者是類似fiddler之類的抓包工具。

本篇暫時寫到這裡結束。

可參考的如google dapper論文,zipkin,聽雲。