這週把「看不懂」變成「查得到」

Week 2 的五篇構成一條完整的日誌設計流程：Day7 鋪管線（Router／Sink／Log-based Metrics）→ Day8 設計欄位結構（從動作到決策）→ Day9 加上關聯識別碼（讓多 Agent 可追溯）→ Day10 控制成本（分級保存與抽樣）→ Day11 處理敏感資訊（記錄與隱私的取捨）。

完整結構化日誌 Checklist

管線設計

• [ ] 已規劃不同類型日誌的 Sink 路徑，而非全部混在一起
• [ ] 需要大規模分析的日誌已規劃送進 BigQuery
• [ ] 關鍵行為事件已轉成 Log-based Metrics 以便後續告警

欄位結構

• [ ] 日誌記錄了決策理由（decision_summary、considered_options），而不只是動作
• [ ] 欄位設計前已先列出「未來想回答的問題」並反推需求
• [ ] event_type 分類設計讓查詢可以只看特定類別事件

關聯追蹤

• [ ] 已設計 trace_id / session_id / span_id 三層識別碼
• [ ] 跨 Agent 呼叫時 trace context 確實被傳遞
• [ ] 已實測驗證「單一 trace_id 能撈出完整鏈路」

成本控制

• [ ] 日誌已依用途分級，套用不同保存策略
• [ ] 高流量場景已設計抽樣規則，失敗案例一律完整記錄
• [ ] 定期檢視日誌用量分布，找出成本大戶

隱私治理

• [ ] Prompt/Completion 的記錄政策已明確決定
• [ ] 完整內容有獨立存取控制與較短保存期
• [ ] 日誌寫入前有敏感資料遮罩機制

下週要往哪走

日誌回答的是「發生了什麼、為什麼」，但要看清楚「這條推理鏈怎麼展開、時間花在哪」，需要另一種視角。Week 3 進入 Cloud Trace，把 Agent 的決策鏈路畫成一棵可以逐層展開的 Span 樹。

參考資料來源

• Google Cloud，《Cloud Logging 官方文件》
• Google Cloud，《Instrument generative AI applications — Cloud Trace》
• OpenTelemetry，《GenAI Semantic Conventions》，opentelemetry.io

💡 關於作者 我是 Fngi，專注在 AI 安全與雲端資安領域。如果這系列對你有幫助，歡迎追蹤 Instagram @aid3fend，我在那裡分享更多 AI 資安的實務筆記與趨勢觀察。