這其實是個很大的題目，作法百百種，但是核心概念就是要將原本需要人工設計、維護的 log parser 轉變為用程式自動地去找出隱藏在 log 中訊息架構。這樣說可能不太好理解，我們直接看圖：
圖中最上面是 hadoop 印 log 訊息的程式片段，在執行過程中會在 log 檔產生中間的訊息，而最下面則是一般使用 log parser 通常會想得到的結果。通常 log parser 要產生出最下方的結果依賴於使用者知道 log 訊息的架構，比方說每個 log 訊息最一開始是時間資訊、然後是嚴重程度、從哪個元件印出來的、訊息內會有那些地方是固定或可變的...等等。然而這種方法最大的困擾點是目標程式改版、訊息架構有些許變化，log parser 也一定要跟著修改才能運作。所以近年來就有人開始研究是否有辦法讓程式自己找出那海量的 log 訊息中的架構，這樣就不用花大量的時間去維護 log parser 了。
"Tools and Benchmarks for Automated Log Parsing." 這篇發表在 2019 ICSE (International Conference on Software Engineering) 的論文簡單來說就是整理了至今發表的各種方法並且加以評比各自的精準度與效能。另外他們也把程式放上 github 了，有興趣的可以下載來使用看看，對於有這類需求的人我想是個滿適合拿來入門的。
實際使用起來的狀況看他們提供的 benchmarking script 應該會更清楚，仔細交叉比對的話應該可以發現針對不同的 tool 依然會需要不同的設定，換言之使用前依然必須對要使用的 tool 有一定的理解程度，沒辦法讓你無腦直接套用看結果。
另一個在使用上比較值得注意的大概是就是參數裡面有一個 "log_format"。這是啥呢? 簡單來說就是你也不能沒看過 log 的格式就直接套用在其中一個 tool XD 這邊的假設應該可以看成每一行要處理的訊息必定包含某些固定格式的內容，像是時間、ID、嚴重程度...等等，你必須要先把這些固定會有的內容的格式先給 parser，parser 在處理時會先過濾掉這些內容，隨後才會對剩下的變動內容作處理，並且找出這些內容間有沒有共通的樣式。
就結論來說，對於剛要開始處理 log 的新手來說，藉由 logparser 的論文可以先大致了解待處理的 log 的形式比較適合使用哪些種類的 tool，並且實際使用該工具去分析了解該工具是否可以吻合需求。不過如果想作為一套不論甚麼 log 都能處理的自動化工具就言之過早，他依然需要一定程度的人工介入
沒有留言:
張貼留言