3秒知識卡

三基石關系：

Metrics（指標）→ 系統脈搏（CPU/錯誤率）

Logs（日志）→ 事件日記（錯誤堆棧/用戶行為）

Traces（追蹤）→ 血緣地圖（請求跨服務路徑）

協同價值：故障定位速度提升 10倍（MTTR從1小時→6分鐘）

一、為什么必須是這三個？運維數據界的“水糧氧”

1. 從支付系統故障看三基石協同作戰

故障現場：

• 用戶支付失敗率突增30%，但服務器CPU/內存指標全部正常?

排查過程：

關鍵角色：

• Metrics：發現業務指標異常（但無法解釋原因）
• Logs：找到錯誤關鍵詞“Connection timeout”
• Traces：還原完整調用鏈（穿透12個微服務）

結果對比：

• 傳統方式：4人團隊排查3小時
• 三基石聯動：6分鐘定位證書過期

2. 三者本質差異與互補性

維度	Metrics	Logs	Traces
數據結構	數值型（時間序列）	文本型（非結構化）	樹形拓撲（請求鏈路）
核心價值	量化健康度（如錯誤率）	記錄事件上下文（如異常堆棧）	還原調用關系（如服務依賴）
存儲成本	低（1TB/月）	高（原始日志100TB/月）	中（采樣后10TB/月）
典型案例	Prometheus監控儀表盤	ELK排錯日志	Jaeger鏈路追蹤圖

二、深度治理指南：金融級數據治理框架

1. Metrics治理四步法（攜程50億/分鐘實踐）

架構圖：

關鍵治理策略：

• 降采樣：原始秒級數據→按業務保留策略（如核心交易保留1年原始數據，非核心服務僅留小時級聚合值）
• 動態聚合：自動識別熱點指標（如支付延遲）實時計算P99分位值
• 成本控制：通過標簽（env=prod）區分存儲等級，冷數據轉存S3

2. Logs治理三大戰場（某銀行日志壓縮率95%）

致命痛點：

• 開發隨意打印日志 → 單日2PB無效日志（DEBUG日志占比70%）?

治理方案：

技術組合：

• 采集：Filebeat（輕量級）+ OpenTelemetry（標準化）
• 處理：Loki（日志聚類）+ Flink（實時分析）
• 存儲：ES熱數據保留7天 + MinIO冷數據歸檔

3. Traces治理黃金法則（穿透387個微服務的秘密）

核心挑戰：

• 微服務鏈路追蹤成本指數級增長（100萬QPS → 每日TB級Span數據）?

攜程實戰方案：

關鍵決策：

• 采樣策略：
  • 錯誤請求：100%采樣
  • 慢查詢：>200ms全留存
  • 正常請求：隨機5%采樣
• 存儲優化：
  • 僅存儲關鍵Span（DB調用/RPC通信）
  • 丟棄中間件內部Span

三、技術選型決策樹：不再被廠商綁架

Metrics方案選擇（根據數據規模）

Logs架構選型（根據業務需求）

場景	推薦方案	案例說明
實時故障排查	ELK/EFK	某電商日志檢索＜3秒
長期合規審計	Loki+S3	金融業7年歸檔成本降80%
安全威脅分析	Splunk+機器學習引擎	檢測黑客攻擊行為

Traces技術決策矩陣

四、血淚教訓：三基石實施中的五個深坑

1. 埋點混亂

   • 反例：某證券APP未統一TraceID格式 → 跨系統無法關聯
   • 根治方案：強制OpenTelemetry規范（TraceID需含：appName+timestamp+random）

2. 采樣過載

   • 反例：某短視頻平臺全量采集日志 → 日均存儲成本￥50萬
   • 黃金比例：
     • Metrics：100%采集
     • Logs：生產環境ERROR全采，INFO按1%采樣
     • Traces：錯誤鏈路100%，正常請求<10%

3. 數據孤島

   • 反例：某銀行指標/日志/追蹤存在三個系統 → 故障定位需人工串聯
   • 破局關鍵：
     • 在Span中植入Logs關鍵字（如error_code）
     • 在Metrics標簽中嵌入TraceID（如http_requests_total{trace_id="xyz"}）

4. 治理滯后

   • 反例：某P2P公司先建平臺后治理 → 清理無效日志耗時6個月
   • 最佳實踐：