Log 問題域

文章目錄

• 如何不帶來額外的效率損失
• 如何在程式運行出錯時記錄儘可能多的資訊
• 如何方便尋找特定條件的錯誤
• 如何橫切的添加通用資訊

 

• 如何不帶來額外的效率損失
• 如何在程式運行出錯時記錄儘可能多的資訊
• 如何方便尋找特定條件的錯誤
• 如何橫切的添加通用資訊

 

如何不帶來額外的效率損失

在之前接觸的一個大型產品中見過散布著如下代碼:

if (Log.Level > DEBUG) {
    logger.write(some_method_to_build_the_log_string());
}

問為什麼不在logger.write()裡面判斷記錄層級, 這樣外面寫起來就很清爽

logger.write(some_method_to_build_the_log_string());

答曰效率問題, 後面一種寫法會導致無論日誌最終有沒有被寫入, some_method_to_build_the_log_string()都會先行被調用求值, 而這可能很耗時...

一個解決辦法是額外的中介層: 能夠延時求值的東東, 比如函數指標, 函數對象, 總而言之能夠儲存當前上下文而在將來某個時刻能夠回調的東西, 諸如 C# 裡的 Func<string>

這樣logger.write()的簽名就從 void write(string info) 變成 void write(Func<string> getInfo);

帶來的一個問題是啥時真正寫入, 一般可以是使用者事務結束的時候. 其實當並發使用者量大時, 表面上延時求值可以不阻礙當前請求的處理速度, 但當求值發生時, 可能會阻礙其它請求的處理. 所以Func<string>代替string效率上的優勢並不明顯, 更多的是代碼上的簡潔

 

(Func<string>的另一個好處是把IO操作延遲了, 當時沒有IO操作，所有IO操作都被推到完成使用者請求之後再進行，尤其是如果因為其它原因需要把Log存到資料庫的時候. 當然不用Func<string>, 直接用string也可以實現延遲IO操作, 只需要把string都緩衝起來, 找個時機再寫出來即可)

然而Func<string>更大的意義是解決第二個問題:

如何在程式運行出錯時記錄儘可能多的資訊

通常最終寫到日誌裡的資訊, 都是根據配置的層級決定的, 比如配置了記錄層級是INFO, 那麼無論出不出錯, DEBUG層級的資訊都不會被寫到日誌裡. 然而現實情況是, 一旦出錯, 我們可能需要DEBUG資訊來定位問題. 於是我們不得不把記錄層級設定成DEBUG,然後重新運行應用,企圖複現. 但運行環境的差異使得複現像撞大運, 可遇不可得. 於是在案發第一現場就記錄所有線索變得極具效率

對日誌即時求值和寫入是很難實現這個目的的, 而延時求值, 回調, 這層額外的間接則將其變得輕而易舉.

我們要做的就是儲存所有寫日誌的回調, 直到寫入的那一刻, 根據某種規則, 從中挑選部分回調真正去執行; 規則可以是正常情況下根據記錄層級設定, 出錯的時候則全部寫入, 等等

 

(這裡的目的就是避免日誌過於簡略或者繁瑣, 鼓勵大家多寫日誌而不必擔心運行時效率)

如何方便尋找特定條件的錯誤

尋找是資料庫的強項, 把日誌結構化, 存到資料庫裡即可. 這會帶來事務的問題: 寫日誌是否和使用者正常的業務放在一個事務裡?

如何橫切的添加通用資訊

如果把log建模為一個對象, 可以應用builder模式, pipeline等, 讓log對象依次通過一堆builder組成的pipeline, 每個builder負責給log增磚添瓦, 最後出來的就是一個包含了各種彼此獨立的資訊的對象