01. 日志數據的起源

日志數據的起源可以追溯到計算機科學和信息技術的早期發展。隨著計算機系統變得越來越復雜和龐大，監控和診斷系統的運行狀態也變得越來越困難，于是工程師們意識到需要一種記錄和存儲系統事件和信息的機制，讓計算機“說人話”，主動表達自己發生了哪些變化，運行了什么代碼，并記錄下來。這就是日志的誕生。

日志數據記錄了系統或應用程序在執行過程中每個事件的明細詳情。當系統或應用程序啟動時，它會記錄啟動過程中的每一個步驟，包括加載的驅動程序、初始化的設備和運行的服務。如果系統或應用程序遇到錯誤或異常情況，日志會記錄錯誤消息、警告信號和異常堆棧跟蹤，幫助工程師定位問題。

此外，日志還可以記錄用戶的活動和行為。當用戶與計算機系統進行交互時，日志會記錄用戶的請求、輸入和操作，以便企業追蹤用戶行為、提供個性化服務或進行安全審計。以下為日志的簡單示意圖：

02. 日志數據特點

日志數據和指標數據都是運維中非常重要的數據類型，可以幫助運維人員監測系統的穩定性，及時發現和解決問題，那么日志數據相對于指標數據有哪些特點呢？日志數據通常是實時的，記錄的是事件發生的瞬間的數據情況，而指標數據通常是定期收集的，提供的是更加量化和簡潔的信息。

日志數據特點：詳細，多樣性，海量，可讀、實時

指標數據特點：簡潔，波動性，定期，量化、直觀

基于日志和指標的數據特點，當系統發生故障時，運維人員通常先關注指標數據，了解故障范圍和影響面，快速恢復故障，降低對業務的影響；然后再通過日志數據定位和診斷問題，分析故障的根本原因，徹底解決故障問題。因此統一管理和應用企業日志數據十分重要。

03. 日志規范之道：記錄何時何事

現在你可能會想，既然日志數據如此有用，那是不是應該立馬行動起來，建設工具進行日志收集和分析呢？很高興你感受到了日志數據的價值，但請先等等，工欲善其事，必先利其器，在建設工具之前，我們有必要先規范化日志的輸出。

如果把建設日志工具比喻成蓋房子，那么日志工具的能力相當于房梁，日志工具的上層應用場景相當于房子的門戶，日志本身的記錄相當于房子的基座。如果日志輸出沒有邏輯，基座搭建不穩，那么房子無論怎么裝修都是不牢固的，無法抵擋狂風暴雨。

日志應該記錄什么？理論上來說，日志應該記錄一切，事無巨細，這樣無論什么時間點程序發生了什么事件，工程師們都可以通過日志查看現場快照。但這可能會快速讓網絡和磁盤達到負載飽和，還可能會讓業務系統有潛在的性能瓶頸，因為花費了太多時間來記錄日志，導致可能比業務本身運行的時間還多。因此，針對不同的應用程序，日志需要記錄的信息、推薦的日志記錄頻率可能都是不一樣的。

在確定日志應該記錄什么信息之前，不妨重新回顧一下輸出日志數據的目的：定位根本問題，避免回答不了“為什么跑成了這個樣子”的疑問。當應用程序出現問題時，通常你會先問哪些問題？在排查故障的過程中，通常你需要哪些信息進行協助？基于目的去思考，那么需要日志記錄什么信息，答案就顯而易見了。

日志除了需要記錄有用信息外，還需要遵循一些規則，讓工程師們能夠看懂這個日志在描述一件什么事。在筆者看來，日志輸出應該遵循這些規則：

• 合理使用日志級別，避免在高級別日志中輸出調試信息。
• 符合安全審計要求，不輸出涉及機密和安全的信息。
• 包含必要的、準確的信息，便于定位和分析問題。
• 保持精簡，禁止大量打印口語化且不含有效信息的詞語。

04. 高效管理日志的秘訣

輸出規范化的日志后，下一步就是把日志收集起來進行管理。工程師們通常通過建設日志工具完成日志的集中收集，主流的日志工具架構將這個過程劃分為五層去實現，如下圖所示。

接入層：

接入層是指與應用程序直接交互的組件，負責接收應用程序生成的日志消息。它可以是一個Agent、API或中間件，用于捕獲應用程序中的日志事件。

傳輸層：

傳輸層接收來自接入層的日志消息，并將其傳輸到處理層或存儲層。除傳輸日志數據外，通常還充當緩沖層，支持海量數據堆積、高吞吐讀寫，提供異步解耦、削峰填谷的能力。

處理層：

處理層接收傳輸層發送的日志消息，并進行進一步的處理和增強。它可以執行各種操作，如日志數據的過濾、解析、替換、富化等。

存儲層：

存儲層是用于保存和管理日志數據的組件。它負責接收處理層發送的日志消息，并將其持久化存儲。存儲層可以是數據庫、文件系統、日志管理平臺或云服務等。通常使用Elasticsearch、ClickHouse作為日志存儲系統，便于查詢日志。

應用層：

應用層是日志工具的最上層，提供了用戶界面和應用程序編程接口（API），使用戶能夠查詢和分析日志數據。它可以支持日志的監控、告警、報表生成和可視化等功能。

通過日志工具的五層架構實現日志數據的收集和管理后，深入探討日志的高效管理變得至關重要。若想實現日志的高效管理，需要專注于三個核心要素：統一、集中、合理劃分。

1）統一，指的是通過Agent統一采集各類設備的日志

當前日志采集面臨以下挑戰：

• 資源設備種類豐富，可能包含服務器、數據庫、中間件、交換機、防火墻等。
• IT系統異構，不同應用程序之間可能具有不同的架構、數據模型、通信協議和編程語言。
• 運行環境不一，應用程序可能部署和運行在云上、云下或容器環境。

如果缺乏統一的采集能力，需要對每一種采集場景進行定制化適配，那么工程師們可能會在日志接入這一步就喪失信心，企業的接入實施成本也會極高。這種折磨人的情況往往會通向兩個分支：

• 開始即結束，倒在了第一步。
• 耗費極高的人力成本和時間成本接入日志后，陷入一個新的困境“值得嗎？”，并且如果工程師們在一開始就對日志工具形成一種十分難用的思維，后續也很難高頻地去使用日志工具。

因此，好的日志工具應該實現采集的統一，用一個Agent即可滿足各種采集場景。高效接入不同設備的日志，將時間和精力投入在更值得建設的業務場景上。

2）集中，指的是集中納管日志

日志分散在不同系統時，手動查找日志和分析問題十分困難，工程師們可能需要橫跨應用甚至服務器查看上萬條日志后才能定位到關鍵日志。這個時候你發現一個奇怪的現象了嗎？明明日志的誕生是為了讓工程師們更高效地回答“why it error”，但是為了找到這條帶有“答案”的日志，工程師們需要花大量時間在成千上萬條日志中先回答“when？where？which？”等等問題。這么一通操作下來，工程師們辛辛苦苦卻沒有提升排障效率，這顯然與設計日志的初衷不符。

那么要如何破除這個困境呢？答案是，通過建設日志工具用一個大池子將日志集中納管起來。這樣的好處是，當發生故障時，工程師們可以直接利用日志工具的界面化操作進行日志的統一查詢和分析，無需花精力關注數據究竟以什么形式存儲在池子的哪里。

除此之外，日志工具提供的集中納管能力，還可以確保日志數據的完整性、可追溯性和可審計性，滿足監管部門的安全審計要求。

3）合理劃分，指的是合理劃分日志在工具上的管理維度

日志數據是為業務服務的，日志的管理維度應該根據企業的組織管理模式進行靈活調整。日志工具通常都有其界面化的管理單位，用于輔助工程師們更好地管理日志，將有關聯的日志組織在一起。以筆者使用的日志工具為例，日志主題是日志的管理單元，采集項是日志的采集單元，一個日志主題可以包含多個采集項。這兩個單元的使用遵循以下原則：

• 日志主題應該管理某一類日志。如果以應用/服務為維度管理日志，那么一個日志主題對應一個應用/服務下的所有日志，例如支付服務日志。如果以組件/資源為維度管理日志，那么一個日志主題對應同一類組件/資源的所有日志，例如MySQL數據庫日志。
• 采集項應該采集同一種輸出格式、代表同一類事件的日志，例如支付服務的訪問日志。采集項的顆粒度盡可能的細。

通過為業務服務的視角劃分日志的管理維度，將使工程師們在故障排除時事半功倍。例如，支付服務發生故障了，工程師可以直接查看支付服務在故障時間點產生的日志，縮小時間和空間范圍，快速定位問題。

05. 高價值日志與存儲成本平衡

完成日志的高效管理后，在這個階段，很多企業會面臨一些新的、棘手的問題：

• 日志數據量太大了，每天TB級別的日志，存儲資源hold不住。
• 監管要求日志數據必須保留180天及以上，存儲成本太高了。
• 存儲資源增加后，存儲資源的運維成本也增加了。
• ES集群存儲的數據量太大，索引總是爆掉怎么辦？

這些問題導向的本質其實是一樣的：高價值日志與存儲成本之間找不到平衡點，企業需要為1%價值的日志付出99%的存儲成本和運維成本。

那么應該怎么平衡成本呢？我們可以一起分析一下。首先來看目前常用的日志存儲數據庫——Elasticsearch，官方對它的介紹是：“Elasticsearch 是分布式搜索和分析引擎，為所有類型的數據提供近乎實時的搜索和分析。”

官方給Elasticsearch的定位是一個搜索和分析引擎，工程師們利用它可以便捷快速地查看和分析日志。所以只有當日志需要被頻繁使用時，才更適合存儲在Elasticsearch中。如果日志使用非常低頻，只是需要被存儲起來以滿足安全合規審計，那么更適合存儲在大數據存儲引擎里（例如HDFS），而非存儲在Elasticsearch，因為大數據存儲引擎相比Elasticsearch，價格更低、更易維護。

因此，日志工具為了平衡高價值日志和存儲成本，衍生出了日志歸檔能力。

• 將高頻查看、近期（一般為15天內）的日志存儲在Elasticsearch，方便搜索和分析。將低頻查看、久遠但需要合規審計的日志存儲在大數據存儲引擎里，降低存儲成本和維護成本。
• 對于兩種不同的存儲介質，應具備數據自動遷移/備份的能力。不再需要頻繁查看的日志數據可以平滑地遷移至容量更大的存儲設備上。如果審計部門或工程師需要查看歷史久遠的日志數據，可以通過簡單的界面化操作快速將日志數據重新載入到Elasticsearch或閃存設備上進行查詢和分析。

除此之外，日志工具還會提供一些技術手段幫助企業降低存儲成本。

• 采集數據時，進行數據壓縮。不過這可能會使Agent消耗極高的CPU和內存，而Agent往往安裝在業務機器上，因此需要關注業務資源占用的影響。
• 傳輸數據時，進行數據壓縮。這可能會使傳輸組件消耗極高的CPU和內存，但相比第一點的好處在于傳輸組件不一定部署在業務機器上，可以通過增加機器資源解決這個問題。
• 日志歸檔至大數據存儲引擎時，進行數據壓縮。由于歸檔操作是周期性而非實時性的，因此資源的消耗和業務的影響相比第一和第二點會低很多。

06. 嘉為鯨眼日志中心

高效管理日志數據對日志數據價值發揮至關重要，企業通常需要引入相應的工具，構建日志管理能力，確保日志數據發揮價值，保障業務的平穩運行。

嘉為藍鯨日志中心是面向企業IT研發和運維，滿足分布式架構下海量日志采集及存儲、檢索及分析的一款高性能日志產品，基于業界主流的全文檢索引擎，通過藍鯨專屬 Agent 提供多種場景化日志采集，提供快速檢索分析、輔助故障定位功能。

1）方案優勢

采集豐富：不同終端不同格式日志統一采集，采集過程中支持解析、脫敏、過濾，采集簡單便捷；

推廣便捷：內置常用組件的日志解析模板和儀表盤模板，且允許用戶自建日志解析模板庫，方便接入推廣；

智能高效：融合藍鯨海量數據分析底座和智能化組件，實現高效的日志智能聚類，智能異常檢測和告警；

聯動流暢：和監控告警體系打通，快捷配置日志關鍵字、日志指標告警，無需依賴跳轉；

信創適配：已適配多種國產化設備和系統，也可完成對信創設備的采集。

2）客戶價值

高效排障：聯動藍鯨基礎監控告警，實現關鍵字、日志指標異常檢測，告警通知，明細日志下鉆，高效故障定位；

數據安全：提供完善的權限管控、數據隔離以及敏感數據能保護能力，保障數據安全，滿足數據安全管理訴求；

成本優化：提供數據分層架構，按照冷、熱數據分層，合理降低存儲成本；

便捷推廣：結合藍鯨Agent能力實現日志采集插件一鍵部署、批量安裝、性能穩定。

如果您想要了解更多日志管理相關內容，或有相關建設需求，歡迎聯系我們！