日誌管理與日誌分析方案 | 觀測雲

日誌管理應解決的問題

在同一次排查中讓日誌可搜尋、可治理、可解釋

生產級日誌流程不只是存入資料，還要有可重現的採集路徑、一致欄位、存取與保留政策，以及連到服務、主機、Pod、Trace 和告警的上下文。

方案概覽

觀測雲將已支援的日誌採集、Pipeline、DQL、儀表板、監控器與跨信號上下文放在同一工作流中。團隊可從錯誤或告警開始，縮小資料範圍，再用執行階段與應用證據驗證原因。

營運挑戰

有數量、沒上下文：更多記錄不會自動告訴團隊哪個服務、版本或使用者路徑受影響。

欄位不一致：非結構化格式和經常變動的 Schema 讓共用查詢難以維護。

排查孤立：日誌與指標、Trace 分離時，團隊必須手動重建事故時序。

治理與成本壓力：存取、敏感欄位、索引、保留和存儲都需要清楚政策。

觀測雲如何支援這套流程

採集已支援來源：依各資料源選擇對應的 DataKit、Syslog、HTTP、雲端或應用路徑。

以 Pipeline 標準化：解析、重新對應、補充、遮罩與路由日誌，產生可共用查詢的欄位。

關聯證據：把服務、環境、版本、主機、Pod 和 Trace ID 帶入日誌排查。

治理資料週期：依營運價值設定 Workspace 存取、索引、保留、歸檔與告警。

排查流程

橫跨異構日誌搜尋同一事故

先標準化：先統一時間、服務、環境、級別和負責人欄位，再建立共用查詢。

從一行日誌進入受影響服務

保留關聯鍵：使用 Trace ID、服務標籤、主機、Pod、版本和請求屬性繼續排查。

在噪音變成存儲與告警負擔前處理

有意識地處理：依診斷與治理價值過濾、採樣、遮罩和路由資料。

在噪音變成存儲與告警負擔前處理

將重複模式變成監控與儀表板

將查詢營運化：把驗證後的搜尋升級為共用視圖和帶負責人與 Runbook 的告警規則。

繼續探索

日誌管理平台

查看產品能力、邊界與文件已列明的流程。

統一可觀測性平台

將日誌與指標、Trace、RUM、基礎設施與事故連結。

RUM 真實使用者體驗監控

把瀏覽器和行動端影響連到後端與日誌證據。

常見問題

日誌管理方案應解決哪些問題？

應支援已文件化的採集、解析、搜尋、存取控制、保留、儀表板、告警，並能連到服務與基礎設施。實際範圍以資料源和已設定路徑為準。

觀測雲如何關聯日誌、指標和 Trace？

使用一致的服務、環境、版本、主機、Pod 與 Trace 屬性。關聯效果取決於這些欄位是否被正確採集與標準化。

如何處理敏感資料與日誌成本？

導入前先定義採集範圍、遮罩、索引、保留、歸檔、存取與採樣。具體控制以當前版本與部署文件為準。

集中日誌後還需要原始系統嗎？

需要。原始系統和雲端服務可能仍是平台專屬控制或原始記錄的權威來源；觀測雲提供已設定資料的共用分析層。