監控和日誌

為什麼監控和日誌很重要？

監控（Monitoring）和日誌（Logging）是大型分布式係統中最關鍵的基礎設施（infrastructure）之一，因為沒有監控，就沒辦法知曉服務的運行情況，就沒辦法知道集群中有沒有Down機，機器的CPU使用率、負載是否正常，網站的Traffic是否正常，服務的出錯率是不是在可容忍範圍之內。簡而言之，監控使得我們可以實時的了解網站的運營情況和可用性（Availability）情況。

監控通常是從整體上了解網站的情況，需要具備實時性。而日誌則是詳盡的記錄著係統運行情況，每一次service的調用，每一次數據庫的訪問，都應該寫進日誌，特別是當係統出現問題時，我們希望日誌係統能為我們提供完整的錯誤堆棧（Exception Stack）和盡可能完備的上下文（Context），為係統維護提供支持。日誌可以容忍一定程度的延遲，不需要實時性，特別是基於日誌的報表，因為分析日誌需要一定的時間，也沒辦法做到實時。

監控和日誌有時候是可以互相協作的，例如，日誌中所攜帶的大量係統信息（客戶端IP，運行Transaction所需時間，SQL的利用率（Use Ratio，在一個Transaction中，use ratio>1的話，說明有問題），等一切用戶願意寫入日誌的信息）本身就可以為監控提供信息來源（Source），實際上除了監控，利用日誌信息我們還可以做很多和業務相關的事情，比如分析用戶的行為，統計係統的使用情況，不過因為日誌信息體量巨大，也就是我們通常說的大數據，像ebay每天的日誌信息在幾十個TB，對如此龐大的數據進行存儲和分析，可不是一件容易的事情，通常我們需要借助於FDMS和Hadoop等技術手段。

監控和日誌係統架構

縱觀所有的監控和日誌係統，無外乎就是下麵三步

1. 在業務係統中埋點。

此處需要注意的是，對一些公共組件，例如SOA framework，我們希望在日誌中記錄每個到達SOA Service的request以及request的payload，那麼這個點應該設在framework中，而不是具體的SOA service中，從而起到一個AOP（Aspect Oriented Programming）的效果，並且確保了記錄該信息的風格統一。(前些天，和同事討論到這個AOP，他說對於這個統一打印log的功能，要留一個後門，因為對一些敏感信息，如信用卡卡號，我們需要Mask然後再輸出，也有道理，但是這個後門要怎麼設計呢？各位有沒有好的思路？）

2. 將日誌 \ 監控信息發送到日誌係統後端

這個發送的過程應該遵循一個高性能的設計原則，因為寫日誌的地方會很多，因此對整個業務係統的影響也就非常大，所以一定要高效。例如在eBay CAL係統中，其采用的手段就是：內存中收集日誌信息並緩存，當緩存到達2K時，通過Socket通信，異步的發送到日誌係統後端。利用緩存+Socket+異步，使得寫一條日誌的過程占用正常業務處理的時間是降到極低，不到1MS

3. 日誌係統存儲、分析日誌信息，對外提供日誌檢索，日誌瀏覽、視圖展現等服務

對海量日誌的存儲和搜索，可以采用上文提到的Hadoop技術，對於日誌瀏覽（LogView）服務，需要注意的一點是，我們應該用REST的GET方法提供服務，一個很實際的需求就是，員工之間通常需要傳遞LogView的URL來進行溝通，典型情況是QA會發送一個出錯日誌的URL給PD，說看一下是什麼地方出了錯，因為GET的所有參數都在URL中，所以PD點擊URL就能瀏覽到相應的日誌了。還有就是Access LogView的不一定都是人，也可能是另一個程序，那麼日誌係統可以保持REST的接口不變，而對不同的客戶端（瀏覽器，或Java Client）提供不同Format的response（HTML，或JSON，XML）

A log view REST URL sample for eBay CAL

https://hostname/logviewui/environment/raptorqasql/pool/r1pgwpmtsoa-envhu4744im8fv4q/machine/phx5qa01c-83ea.stratus.phx.qa.ebay.com/eventDetail?datetime=2014/05/13%2019:43&thread=0x9e&evt=1400035419680