日誌管理完整指南：集中收集、保留、遮罩與故障排查 | Guance

Log management(日誌管理)是指把系統產生的日誌(logs)集中收集、統一儲存、支援快速搜尋與分析的一整套做法。 日誌是三種可觀測性訊號(logs/metrics/traces)中細節最豐富的一種——錯誤堆疊、請求明細、審計記錄都在裏面——但前提是你搵得到。日誌管理要解決的就是「分散、量大、格式不一」三個問題,令排障時唔使喺幾十部機之間逐個撈。

點解要集中(centralized logging)

分散日誌有三個致命傷:

搵唔到:一台服務幾個實例,日誌散落各機,查一單問題要逐部 SSH 入去。
留唔住:容器同 auto-scaling 令機器隨時消失,機器上的日誌一齊消失。
對唔齊:各服務日誌格式不一,冇共同欄位,跨服務分析近乎不可能。

集中式日誌管理(centralized log management)將所有日誌收到一處,加上結構化(structured)欄位同統一時間戳,先至令「一次搜尋,全部搵到」成為可能。這是可觀測性的地基之一,詳見什麼是可觀測性。

保留(retention)與成本的平衡

日誌管理最大的成本來源是「全部留、全部索引」。務實的做法是分級:

延伸閱讀APM 應用程式效能監控完整指南：從 Trace 到告警

級別	例子	策略
熱(hot)	錯誤、關鍵交易	全索引,即時可搜,保留 7–30 日
溫(warm)	一般應用日誌	部分索引或低成本索引,保留 30–90 日
冷(cold)	合規/審計需要的歷史	歸檔(archive)到平價儲存,需要時先還原

重點:索引(indexing)先係錢,唔係儲存。將「全部索引」改為「分級索引」,通常係慳錢最快的一步。除錯(debug)級別的日誌平時唔索引,出事先至臨時開,係常見做法。

敏感資料與遮罩(masking)

日誌好容易混入個人資料(姓名、電話、卡號、IP),受香港《個人資料(私隱)條例》(PDPO)規範。實務上要:

產生時就遮罩:喺應用層或 Collector 把敏感欄位做 masking/redaction,唔好等入到儲存先處理;
權限分級:唔係個個工程師都要睇到原始內容;
保留期限寫入政策:留幾耐、邊個可以還原,要講得明。

具體合規責任請諮詢法律顧問。原則係:能唔收就唔收,一定要收就遮罩咗先收。

查障時點樣同 trace 互相跳到

日誌同 trace 係查障的一對。做法是喺應用輸出日誌時寫入 trace ID,咁樣:

延伸閱讀Datadog 替代方案 7 選（2026）：成本、功能與選型比較

由一條 trace(見分散式追蹤是什麼)可以直接跳去該段服務當刻的日誌,睇到完整錯誤細節;
反過來,由一條錯誤日誌都可以用 trace ID 返去睇成個請求喺邊度慢。

冇呢個關聯,日誌同 trace 就係兩個獨立孤島,排障仍然靠估。慢查詢呢類具體場景的排查,可以參考英文版 How to Monitor MySQL Slow Queries。

常見問題

Q. 日誌管理同日誌監控(log monitoring)有咩分別?
日誌管理係收集、儲存、搜尋的基礎設施;日誌監控係喺上面加規則——例如「error 關鍵字出現多過 N 次就告警」。管理係前提,監控係應用。先有前者先至可以做到後者。

Q. 要留住幾多日誌先算合理?
視乎用途。排障用的熱數據 7–30 日通常夠;合規或審計需要的先至要按年計,而且應該歸檔而唔係全索引。將保留期同成本掛鈎去定,而唔係「能留就留」。

Q. 日誌量好大,成本點控制?
三招:分級索引(上面講咗)、採樣或過濾低價值日誌、歸檔到平價儲存。最貴嘅係索引,唔係硬碟。

Q. 容器環境日誌特別難搞喺邊度?
容器一消失日誌就消失,所以一定要喺容器層面就把日誌轉發出去(stdout/stderr 或由 agent 收集),唔可以依賴落盤後先執。呢個係容器化後日誌管理的第一課。