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

前言

不管從最先期的unix操做系統，仍是曾經大行其道的單體式應用，仍是如今日益流行的微服務架構，始終都離不開監控的身影。如windows的任務管理器，linux的top命令，均可以看做是監控的面板。

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

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

理想中的分佈式監控

進入互聯網時代，系統調用規模日益龐大，對監控的需求更是迫切。好比一個頁面打開很慢，怎麼分析哪裏慢？是網站接受請求慢仍是鏈接數據庫慢，或者消息隊列掛了，或者redis請求慢？咱們須要監控系統能提供這些信息供咱們追蹤分析。

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

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

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

第四點，許多方法有層級，方法內調用其餘方法，應該能經過報表聚合查看，進入每一個方法的時間以及調用耗時，調用方法的層級樹。

第五點，分佈式時代，一個調用請求會橫跨不少站點，理想的分佈式監控應該提供調用鏈上全部站點的聚合報表查看，要極力避免死循環，兩個站點長官相互調用的狀況下，應該用雙箭頭代表調用關係。

第六點，能提供接入監控的服務器cpu，內存，硬盤空間等指標，並根據警惕線發送通知。這個優先級能夠下降，能夠藉助雲服務器自身提供的監控，阿里雲和Ucloud都有本身的服務器監控面板。

如何設計一款實用的監控

統一的調用鏈id

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

時間戳

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

異步傳輸

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

延時聚合

若是能作到實時聚合更好，若是實現困難能夠採用延時聚合報表，延時的時間應該小於一分鐘。這個時間使用人羣應該能接受，固然若是能縮短到幾秒鐘，那使用人羣會更加高興。聚合報表應首先提供最近時間內的耗時排序，能夠查看調用的方法樹，能夠查看調用鏈的全部站點，其餘需求能夠後期開發，解決核心需求。

最後的難點

若是不追求無侵入，提供一個空接口。全部須要記錄日誌的實現接口，就已經達到了目標的一半。

爲了完成對應用無侵入的目標，咱們首先須要一款真正的aop，即靜態編織Aop，這個只據說過postsharp，爲何只有它能實現？或者是相似fiddler之類的抓包工具。

本篇暫時寫到這裏結束。

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