先把管線鋪好，再談內容怎麼設計

Week 1 建立了概念地圖，這週開始動手。第一步不是急著設計 Agent 日誌的欄位，而是先理解 Cloud Logging 的資料流：日誌從應用程式產生之後，會經過哪些環節、能被送到哪裡、能被加工成什麼。這決定了後面幾篇的日誌設計有多少發揮空間。

資料流：從產生到落地

Cloud Logging 的基本流向是：應用程式寫出日誌 → 進入 Log Router（日誌路由器）→ 依照你設定的規則，決定要留在 Cloud Logging 的 Log Bucket、還是送到別處。

Log Router 是關鍵的分流點。它讓你可以用條件判斷（例如依 severity、依資源類型、依日誌內容欄位）決定不同的日誌要走不同的路，而不是所有日誌都用同一套保存策略。

Sink：把日誌送到該去的地方

Sink 定義「符合某個條件的日誌，要被送到哪個目的地」。常見的目的地包括：

Log Bucket：留在 Cloud Logging 內，可以直接用 Logs Explorer 搜尋，適合近期需要頻繁查詢的日誌。

BigQuery：適合需要做大規模分析的日誌——對 Agent 場景特別有用，例如你想分析「過去三個月，Agent 在哪類任務上的工具呼叫失敗率最高」，用 SQL 查詢會比在 Logs Explorer 一筆筆翻有效率得多。

Cloud Storage：適合長期封存、查詢頻率低但因法規要求必須保存的日誌。

Pub/Sub：適合需要即時串流處理的場景，例如把特定日誌事件即時推送到下游的告警或分析系統。

Log-based Metrics：把日誌變成可告警的指標

這是 Cloud Logging 一個容易被低估的功能：你可以定義規則，把符合特定條件的日誌筆數轉換成一個 Metric，這個 Metric 就能被 Cloud Monitoring 用來設定告警（Week 4 的主題）。

對 Agent 場景，這個機制很實用——例如你在日誌裡記錄了「Agent 判斷無法處理，轉接人工」這個事件，就可以建立一個 Log-based Metric 追蹤轉接次數，一旦短時間內飆高就觸發告警。這正好回答 Day1 開場提到的客服 Agent 轉接率暴增場景：如果日誌設計得當，這個異常在告警層就能被抓到，不用等使用者抱怨。

待實測提醒：Cloud Logging 的保存期限預設值、各類 Sink 的計價方式、以及 Log-based Metrics 的配額限制會隨方案調整，發布前請對照 Cloud Logging 官方文件 確認目前規格。

這篇的檢查清單

• [ ] 是否已規劃不同類型的 Agent 日誌該走哪條 Sink 路徑，而非全部混在一起？
• [ ] 是否已評估把需要大規模分析的日誌送進 BigQuery？
• [ ] 關鍵的 Agent 行為事件是否已規劃轉成 Log-based Metrics 以便告警？

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