.Net架構篇:思考如何設計一款實用的分布式監控系統？

前言

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

再聯系起現實生活，無處不在的路網攝像頭，為交通機關監控交通人流提供了友善。

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

理想中的分布式監控

進入網際網路時代，系統調用規模日益龐大，對監控的需求更是迫切。比如一個頁面打開很慢，怎麼分析哪裡慢？是網站接受請求慢還是連接配接資料庫慢，或者消息隊列挂了，或者redis請求慢？我們需要監控系統能提供這些資訊供我們追蹤分析。

是以理想中的分布式監控應該記錄從請求發起那一刻，所調用的公開方法，接觸過的資料庫，緩存，隊列等步驟，以及每一步所消耗的時間。這些都需要大量的日志去記錄。

第二點，理想中的分布式監控必須是對代碼無侵入，應用程式員無需對每個方法去調用監控代碼。這樣完全解藕的監控系統，才更容易使用，加入每個方法，都要調一下監控接口，那不要累死人，代碼也及其不友好。

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

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

第五點，分布式時代，一個調用請求會橫跨很多站點，理想的分布式監控應該提供調用鍊上所有站點的聚合報表檢視，要極力避免死循環，兩個站點長官互相調用的情況下，應該用雙箭頭表明調用關系。

第六點，能提供接入監控的伺服器cpu，記憶體，硬碟空間等名額，并根據警戒線發送通知。這個優先級可以降低，可以借助雲伺服器自身提供的監控，阿裡雲和Ucloud都有自己的伺服器監控面闆。

如何設計一款實用的監控

統一的調用鍊id

根據軟體的調用鍊特性，從一個請求開始到最終的結束，應該具有一個統一的調用鍊id。

時間戳

調用各種方法的時間也應該是順序的，需要一個精确的時間戳，來描述調用方法的進入與離開的時間。

異步傳輸

為了不影響性能，應該以異步傳輸，定時落庫的方式。

延時聚合

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

最後的難點

如果不追求無侵入，提供一個空接口。所有需要記錄日志的實作接口，就已經達到了目标的一半。

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

本篇暫時寫到這裡結束。

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

作者：

從此啟程/範存威

出處：

http://www.cnblogs.com/fancunwei/

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連結。如文章對您有用，煩請點個推薦再走，感謝！ 本部落格新開通打賞，滑鼠移到右側打賞浮動處，即可賞部落客點零花錢，感謝您的支援！