前言
無論從最早期的unix操作系統，還是曾經大行其道的單體式應用，還是現在日益流行的微服務架構，始終都離不開監控的身影。如windows的任務管理器，linux的top命令，都可以看作是監控的面板。
再聯系起現實生活，無處不在的路網攝像頭，為交通機關監控交通人流提供了方便。
系統規模越大，越離不開監控。缺少了監控，就像盲人摸象，窺不到全貌。
理想中的分布式監控
進入互聯網時代，系統調用規模日益龐大，對監控的需求更是迫切。比如一個頁面打開很慢，怎么分析哪里慢？是網站接受請求慢還是連接數據庫慢，或者消息隊列掛了，或者redis請求慢？我們需要監控系統能提供這些信息供我們追蹤分析。
所以理想中的分布式監控應該記錄從請求發起那一刻，所調用的公開方法，接觸過的數據庫，緩存，隊列等步驟，以及每一步所消耗的時間。這些都需要大量的日志去記錄。
第二點，理想中的分布式監控必須是對代碼無侵入，應用程序員無需對每個方法去調用監控代碼。這樣完全解藕的監控系統，才更容易使用，加入每個方法，都要調一下監控接口，那不要累死人，代碼也及其不友好。
第三點，理想中分布式監控應該對性能不造成損耗或者極小的損耗。如果流量一大，監控系統CPU飆生的話，那這個監控無疑是失敗的。
第四點，許多方法有層級，方法內調用其他方法，應該能通過報表聚合查看，進入每個方法的時間以及調用耗時，調用方法的層級樹。
第五點，分布式時代，一個調用請求會橫跨很多站點，理想的分布式監控應該提供調用鏈上所有站點的聚合報表查看，要極力避免死循環，兩個站點長官相互調用的情況下，應該用雙箭頭表明調用關系。
第六點，能提供接入監控的服務器cpu，內存，硬盤空間等指標，並根據警戒線發送通知。這個優先級可以降低，可以借助雲服務器自身提供的監控，阿里雲和Ucloud都有自己的服務器監控面板。
如何設計一款實用的監控
統一的調用鏈id
根據軟件的調用鏈特性，從一個請求開始到最終的結束，應該具有一個統一的調用鏈id。
時間戳
調用各種方法的時間也應該是順序的，需要一個精確的時間戳，來描述調用方法的進入與離開的時間。
異步傳輸
為了不影響性能，應該以異步傳輸，定時落庫的方式。
延時聚合
如果能做到實時聚合更好，如果實現困難可以采用延時聚合報表，延時的時間應該小於一分鍾。這個時間使用人群應該能接受，當然如果能縮短到幾秒鍾，那使用人群會更加高興。聚合報表應首先提供最近時間內的耗時排序，可以查看調用的方法樹，可以查看調用鏈的所有站點，其他需求可以后期開發，解決核心需求。
最后的難點
如果不追求無侵入，提供一個空接口。所有需要記錄日志的實現接口，就已經達到了目標的一半。
為了完成對應用無侵入的目標，我們首先需要一款真正的aop，即靜態編織Aop，這個只聽說過postsharp，為什么只有它能實現？或者是類似fiddler之類的抓包工具。
本篇暫時寫到這里結束。
可參考的如google dapper論文，zipkin,聽雲。