日誌分析如何演變

Linux早期的日誌分析
如果您檢視最新Linux或其他類Unix系統的CLI環境，您會注意到其中安裝的許多最基本的工具可幫助您搜尋或轉換文字。比如grep，head，tail和sed。
這些工具對於各種文字操作任務很有用，對於早期的Unix系統管理員來說，它們構成了可用於執行日誌分析的工具集的基礎。
換句話說，早期的Unix沒有提供從多個源聚合成日誌檔案，或自動將日誌檔案從一種格式轉換為另一種格式的工具。沒有提供實時監控日誌資料和向管理員傳送警報的工具。它當然沒有使用者友好的GUI來視覺化從日誌分析中獲得的資料。
相反，管理員使用基本的文字操作和搜尋工具來根據需要理解日誌檔案。考慮到當時軟體的原始性質，這是他們可以管理的最好的。

瀑布時代的對數分析
到了20世紀90年代和21世紀初，那時正處於瀑布式軟體交付的時代。
那時日誌分析變得更加複雜。有更多的日誌需要分析。作業系統為啟動和系統事件等任務保留了單獨的日誌。應用程式通常也會保留自己的日誌，但不一定集中在一個位置。此外，軟體部署開始變得分散，增加了遠端日誌聚合的重要性。
這些需求導致建立了新一代的日誌分析工具，例如syslog-ng和rsyslog，分別於1998年和2004年首次亮相。這兩個工具提供了支援透過網路進行日誌收集的關鍵功能。
與此同時，Windows世界中出現了一連串的專有日誌分析工具，其中許多專用於特定任務。例如，有BootHawk，它支援分析引導和日誌資料，以便改進Windows系統的啟動和登入時間。
這些工具使管理員可以更輕鬆地檢視日誌資料，但他們並沒有消除執行手動日誌分析的需要。這在當時並不是什麼大不了的事，因為這又是瀑布式軟體交付的時代。如果透過手動排序日誌資料來回應軟體問題需要一段時間並不重要，因為使用者習慣於在軟體更新之間等待數年。持續交付和使用者優先軟體開發尚未成為常見做法。

日誌分析和DevOps
今天，情況發生了變化，瀑布式軟體交付的世界已經讓位於DevOps。出現了新的日誌分析技術以適應它。
在DevOps中，自動化就是一切。因此，手動日誌分析不再有效。它削弱了持續交付，持續反饋和持續可見性流程。
類似地，單獨分析來自多個源的日誌資料是低效的。DevOps支援打破阻礙工作流程的孤島。雖然大多數人可能不會將不同的日誌檔案視為一種孤島，但它們基本上符合該孤島定義。如果必須為要分析的每種型別的日誌或每個主機專門建立單獨的日誌分析工作流，最終會得到一個非常孤立的工作流。
這就是為什麼在DevOps世界中，日誌聚合工具變得至關重要。現代日誌聚合工具從多個位置收集日誌資料，以及多種日誌型別，並允許管理員透過單一窗格研究資料。
簡而言之，在DevOps的世界中，IT團隊不再部署六種不同的工具來收集和分析日誌。今天的日誌分析工具集允許一個工具滿足多個日誌分析需求。

結論
在過去的幾十年裡，日誌分析工具和實踐已經走過了很多。這些變化反映了日誌資料本身的演變，日誌已經從手動分析的原始形式發展成需要大規模聚合的方式，並且要求實時地，以滿足DevOps的需求、持續可見的。