指標、日誌、鏈路是服務可觀測性的三大支柱，在服務穩定性保障中，通常指標側重於發現故障和問題，日誌和鏈路分析側重於定位和分析問題，其中日誌實際上是串聯這三大維度的一個良好橋樑。
但日誌分析往往面臨成本和效果之間的權衡問題，沒有完美的方案只有適合的方案，本文將結合實戰經驗，介紹一種日誌分析的實現，分析如何在穩定性保障中用好日誌這個維度，以及日誌如何與指標、鏈路相互配合形成故障定位的最佳實踐。
日誌分析難點
1）規範問題：服務模組的語言和框架各異，日誌格式不規範，分析困難；
2）管理問題：微服務模組眾多，日誌收集和管理困難；
3）成本問題：日誌的儲存和計算分析需要消耗大量的資源，主要是儲存計算資源，使用成本高；
日誌分析方案
本文推薦一種在穩定性保障中，經過考量和實戰的日誌分析方案。故障處理場景中日誌分析的核心思路：
- 日誌到指標：基於閘道器日誌分析介面、域名、渠道、端等維度的關鍵指標（流量、成功率、延遲）；
- 指標到大盤：閘道器日誌分析計算出的維度指標（流量、成功率、延遲）用作全域性服務大盤/大屏的建設，用以觀察服務的全域性狀態；
- 指標到日誌：這類維度指標的生成來源於日誌計算，天然可以實現指標到日誌的關聯，在發現指標趨勢異常時，能夠方便的調出相應時間的日誌原文；
- 日誌到鏈路：具體的日誌原文中帶有 traceid，或模組和介面的資訊，基於此資訊可打通trace系統，調出具體請求或模組的trace資訊，展示請求的呼叫鏈路，分析呼叫異常的底層來源；
- 鏈路到日誌：在trace的異常點下鑽查詢日誌系統，調出對應模組和介面的詳細日誌，做進一步的異常判斷；
- 日誌到特徵：另一個分析思路，基於閘道器日誌做異常指標的特徵分析，如，下單介面異常，則自動分析異常請求在來源IP、接入層例項分佈、upstream分佈等等維度上是否有聚集特徵或特徵變化，如果在某個特徵上出現了特徵的變化和聚集，則可以針對這類特徵確定止損的方案或進一步追查的方向；
優點和權衡
這個方案的優點和權衡點在於：
- 分析價效比高：閘道器日誌通常較為規範，如Nginx日誌，並且也容易治理，同時閘道器日誌也最為靠近使用者端，無論從分析和治理的難易度，以及分析的價值上看，都是最佳的選擇；
- 治理價效比高：程式模組日誌由於語言格式各異，治理難度高，且分析的價值大打折扣。治理的重點可以轉移到落地trace系統上來，程式模組一旦使用了trace的sdk或agent，則可以輸出規範的trace資訊和有價值的定位資訊。落地trace也會有相當的成本，但對類似Java這類語言，成本會低很多，可以使用javaagent方案做到無侵入實現；
- 揚長避短：程式模組的日誌原文格式可能各異也不標準，但異常日誌的資訊仍然是判斷問題原因的重要依據，因此在這個過程中能在合適的分析步驟中查詢調出即可，這部分日誌的價值優勢在於原文資訊而不在於分析計算；
該方案以日誌為中心，實現了一條日誌、指標、trace相互串聯的問題發現和分析路徑，這條路徑也是故障問題分析的典型路徑。
同時從方案的落地和推動成本上來講也是一個比較合適的取捨。如果可觀測產品支援好這條路徑資訊的串聯，會大幅提升異常問題定位分析的效率。
方案落地要點
混合雲資源、觀測系統眾多，是目前很典型的企業基礎設施現狀，在此基礎上要實現這個方案可能需要重點解決以下幾個問題：
1）存量系統如何打通：指標、日誌、trace都可能已經有各自獨立的系統，如何串聯融合不同系統的資料？
2）雲上雲下如何打通：很多企業使用了私有化和公有云的混合雲方案，日誌可能也同時使用了私有化的ELK和雲上的日誌系統，如阿里雲SLS和騰訊雲CLS；
3）風險成本如何控制：如果為此要全部推導重建，用一套系統替代原有系統，風險和成本都太高，週期長也不可控；
產品實踐
這裡介紹快貓星雲的 Flashcat 是如何解決這些問題的。
- 資料來源抽象：常見的開源和雲上現有的可觀測系統都可以作為一個資料來源註冊到 Flashcat；
- 資料互動：Flashcat 底層透過 API 和各資料來源互動；
- 統一分析：上層對來自各個資料來源的資料，特別是日誌資料做統一靈活的配置和分析，生成各類自定義維度的報表和指標資料；
- 指標建設：日誌生成的指標資料可以配置到北極星、滅火圖，作為業務健康狀態和系統健康狀態的觀測指標；
- 下鑽關聯：從 Flashcat 的北極星（業務健康度量化）和滅火圖（系統健康度量化）可以下鑽上面描述的問題分析路徑，實現從業務異常的發現、到系統異常的範圍收斂，到具體問題的分析確認的全鏈路串聯；
總結
本文介紹了穩定性保障中日誌分析系統建設面臨的問題、挑戰、需求和建設中的權衡取捨。並介紹了 Flashcat 如何解決這些問題，做到效果和成本最佳，也最具落地的可行性。