兩個系統之間的最後一哩

Week 2 建立了結構化日誌，Week 3 建立了 Trace。但如果這兩者是兩個獨立的系統，實際除錯時你還是要在兩個介面之間手動比對時間戳——這很痛苦，也容易對錯。這篇處理怎麼把兩者串起來。

串接的關鍵：在日誌裡帶上 trace_id

其實 Day 8 設計結構化日誌時就埋好了伏筆：那份 JSON 日誌的第一批欄位就包含 trace_id 與 span_id。這正是串接的基礎——只要日誌帶有 trace_id，你就能用同一個 ID 在兩個系統之間跳轉。

Google Cloud 的整合更進一步：如果日誌的欄位符合 Cloud Logging 的特定格式（例如把 trace 資訊放在 logging.googleapis.com/trace 這類特殊欄位），Cloud Logging 與 Cloud Trace 之間可以自動關聯，在介面上直接提供跳轉連結。

待實測提醒：Cloud Logging 與 Cloud Trace 自動關聯所需的欄位格式與設定方式，請對照 Cloud Logging 結構化日誌官方文件 確認，並實際驗證跳轉功能是否如預期運作。

實際除錯流程長什麼樣

串接好之後，一次典型的除錯流程會是：

1. 從告警開始（Week 4 的主題）：收到「任務失敗率異常升高」的告警
2. 看聚合資料：在 Dashboard 上確認是哪類任務、哪個時段
3. 挑一次代表性的失敗執行，開 Trace：看到 Span 樹，發現卡在某個 execute_tool
4. 從該 Span 跳到對應日誌：看到那一步的 decision_summary，理解 Agent 當時為什麼選擇這個工具、以及工具回傳了什麼
5. 判斷根因：是工具本身壞了、還是 Agent 誤判該用這個工具

這條路徑之所以能走通，是因為 Week 2 跟 Week 3 的設計是互相搭配的——如果日誌沒有 decision_summary，第 4 步就只能看到「呼叫了這個工具」，回答不了為什麼。

設計原則：兩者職責分工

Trace 回答「結構與時序」：這次執行有哪些步驟、順序、各花多久。

Log 回答「內容與理由」：每一步具體發生了什麼、為什麼這樣決定。

不要試圖把所有資訊都塞進其中一個——Trace 的屬性塞太多會撐爆、日誌硬要表達階層結構會很難查詢。讓兩者各司其職，用 trace_id 串起來。

這篇的檢查清單

• [ ] 日誌是否都帶有 trace_id 與 span_id？
• [ ] 是否已驗證能從 Trace 直接跳轉到對應日誌？
• [ ] Trace 與 Log 的職責是否清楚分工，而非重複塞相同資訊？

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