談服務執行日誌記錄(10.26)

對應服務執行日誌記錄，在前面曾經談過相關的文章，即給出了服務執行日誌，注意包括了服務執行例項和服務執行例項詳細輸入和輸出包括兩個方面的內容。因此對於日誌記錄實際上就涉及到這方面內容如何處理。對於服務執行詳細的輸入和輸出，其中輸入本身有包括了我們約定的標準的MsgHeader訊息頭和詳細的業務系統XSD資料結構。對於這個XSD資料結構本身又可能包括了多層結構。

如果從日誌記錄的完整可配置性來說，最優的方式是可以針對每一個服務單獨配置究竟記錄哪些內容，即例項日誌是否記錄？對於輸入是否記錄，輸出是否記錄，對於輸入和輸出中的多層結構本身又記錄到那層Segment元素上面。這個一個最理想的實現方案。

服務例項頭日誌的記錄

首先對於服務日誌例項頭，這個例項我們會記錄每次服務呼叫的消費方，消費方IP，呼叫開始時間，結束時間，呼叫的報文量，提供服務的OSB叢集節點等關鍵資訊。而我們常說的不記錄日誌，是指對服務執行詳細日誌不記錄，而對於服務執行例項頭日誌都記錄。

但是最近服務執行監控發現，有個別實時大併發量呼叫服務，一個服務本身一天的呼叫量就好幾百萬次，而其它服務執行次數只有不到10萬次。在這種場景下將使整個服務例項頭表資料量增長極快。即使現在我們對服務例項頭表採用的是按天的分割槽表記錄，但是仍然會發現該表資料增長量極大。估計不到3個月就達上億條記錄。

為了解決該問題有兩種方式來處理，即：

1. 可以靈活的配置，例項頭也不記錄日誌

2. 可以針對服務獨立配置，對呼叫量超大的服務，啟用獨立的例項頭記錄表，即分表儲存

對於第一種情況，如果例項頭都不記錄日誌，基本服務例項就在OSB總線上面存代理呼叫，我們也無法觀察到服務一天呼叫的詳情和次數，如果要統計次數也只有看access.log記錄。但是對於這種情況如果有失敗和異常呼叫還是會記錄日誌。比較好的情況是對於這種情況需要記錄下一天呼叫的總數情況，或者記錄下每分鐘呼叫的一個總次數情況。

對於第二種情況，需要獨立建新的資料表（也可以是分割槽表）進行日誌記錄，因此對於這類特殊情況在服務部署的時候需要將日誌資訊重定向到一個獨立的分割槽表裡面。同時在服務日誌查詢的時候需要預設不查詢這部分日誌，如果需要查詢大併發服務呼叫日誌，單獨啟用一個選單進行查詢。

詳細輸入和輸出報文日誌記錄

對於服務的訊息頭MsgHeader記錄，由於服務規範是統一的，因此這個MsgHeader訊息頭也是統一的，因此我們可以靈活的配置是否記錄這個訊息頭。但是這個訊息頭本身資訊量並不大，比如只有消費方系統，編碼，路由程式碼，安全校驗token等關鍵資訊，而沒有具體的業務欄位類資訊。

對於輸入和輸出，需要實現能夠靈活配置分開記錄的功能。

即對於查詢類服務，往往都是輸入資料量很小，但是輸出資料量很大，當查詢類服務響應緩慢的時候，如果輸入和輸出都沒有記錄日誌，那就很難對響應緩慢的服務進行優化和分析，而必須要聯絡消費端業務系統。因此對於這類服務可以配置為只記錄服務輸入，而不記錄輸出。而對於匯入類服務正好相反，即為了後續的問題分析排查，可以只記錄輸出，不記錄輸入。

但是對於匯入類服務的輸入資訊，如果全部不記錄日誌，那麼在匯入出現異常的時候問題排查也相對困難，因此就可以考慮前面提到的可以靈活的配置記錄到輸入結構的哪層上面。比如對於採購訂單匯入的四層結構，我們可以配置對於訂單頭表進行日誌記錄，而剩餘的三層不記錄日誌。當然要實現這個處理起來會比較麻煩，也會影響到日誌分析和記錄的效能。

在服務日誌記錄的時候，如果一個服務調用出現異常，對於這種情況應該是不管是否配置了日誌記錄，都應該對輸入輸出報文，例項頭日誌進行全部記錄，以方面後續進行問題分析和排查。

對於Solr全文檢索日誌記錄

對於服務執行例項報文的全文檢索記錄，也需要做到可以靈活的配置，即針對某個服務是否記錄Solr查詢日誌並建立索引，同時對於特定的服務也需要能夠記錄，可以靈活的選擇輸入是否記錄，輸出是否記錄。

如果對於服務異常調用出現，對於該異常呼叫類情況，為了方便後續的問題排查，最好的方式也是不論針對該服務是否配置了建立索引，都統一記錄索引資訊。建立全文檢索的索引檔案相對的耗費儲存空間，最怕的就是服務出現某種大併發異常呼叫，這些呼叫都是同樣的請求大併發反覆呼叫，如果配置了記錄索引就會導致索引檔案快速增長，而且後續無法針對該服務單獨進行清理。