前言

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

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

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

理想中的分散式監控

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

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

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

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

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

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

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

如何設計一款實用的監控

統一的呼叫鏈id

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

時間戳

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

非同步傳輸

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

延時聚合

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

最後的難點

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

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

本篇暫時寫到這裡結束。

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