建立訂單超過三秒的比例升高，監控跳出提醒。客服同時也回報：「剛剛那張訂單等很久。」我們知道系統變慢了，但同一分鐘內有許多人操作，要從幾萬行日誌裡找到他的那一次，該從哪裡開始？

如果紀錄之間沒有共同識別，就只能在混雜的日誌裡，憑時間戳記、操作內容與訂單資料反覆對照。當一次操作跨過好幾個服務，光把相關紀錄找齊，就可能花掉不少時間。

讓同一次操作，有貫穿全程的共同識別

Correlation ID（關聯識別碼） 的用途，就是把同一次操作在不同環節留下的紀錄串起來。

當Web收到建立訂單的請求時，先產生這個識別碼。隨後不管是呼叫其他API、執行業務邏輯，還是存取資料庫，都在相關Log裡帶上同一個ID，讓分散在各層的紀錄有共同的查詢依據。

不過，程式裡有一個ID欄位，還不代表整條流程已經接通。跨API時，需要透過約定的HTTP Header傳遞，由接收端取得並放進自己的日誌脈絡。若每個服務收到請求後都重新產生ID，又沒有保存彼此的關係，紀錄仍然會在服務交界處斷開。

有些框架內建的Request ID，只代表該服務收到的單次請求，不會自動跨服務傳遞。因此，名稱叫什麼不是重點，要確認的是它在何處產生、能傳到哪裡，以及各層是否用同一個欄位記錄。

若專案已經採用分散式追蹤（Distributed Tracing），也可以沿用Trace ID關聯日誌。它用來識別同一條追蹤鏈；個別呼叫則可再由Span ID區分，不必另外建立一套用途相同的識別機制。

回應前端時，可以把關聯識別碼附在Response Header，並提供畫面上的查詢或複製入口，方便客服回報。慢請求不一定會出現錯誤訊息，因此這個入口也不必只在失敗時才看得到。

若是從告警發現異常，就先依時段、操作類型與耗時，篩選出超過三秒的請求，再拿它們的ID往下追。整體指標告訴我們最近有多少操作變慢，個別請求的紀錄則幫助我們找到實際發生的那幾次。

有了ID，還要看得出每一步做了什麼

結構化Log把資料保存成可以查詢與過濾的欄位，而不只是把所有內容拼成一串文字。

例如在同一個Correlation ID下，記錄時間、服務名稱、處理階段、耗時與結果，就能清楚分辨「收到建立要求」、「庫存查詢完成」、「訂單提交完成」。查詢時可以先用ID找齊紀錄，再依服務或階段縮小範圍。

如果整次請求花了三點五秒，其中庫存查詢就占了三秒，就有具體方向可以繼續查。這還不能直接認定資料庫有問題，因為那三秒可能包含網路傳輸、服務處理與資料庫等待，但已經能把調查範圍縮小到對應的呼叫。

這種關聯也能延伸到資料存取層。應用程式可以在資料庫呼叫的紀錄中帶上ID、耗時與操作摘要，讓我們知道這次建立訂單查了哪些資料、在哪個步驟花了時間。

日誌內容也不必包含整份訂單、客戶個資，或每個方法的進出細節。保留能判斷流程、耗時與結果的關鍵事件，既減少不必要的資料負擔，也讓查找時比較容易抓住重點。

在開發時，就把這些紀錄接起來

平常與AI一起修改流程時，就可以順著Web、API到資料存取層，確認Correlation ID是否持續傳遞、關鍵事件是否留下，以及各服務的日誌能否集中查詢。

例如新增一個下游API呼叫，除了功能結果，也要看它有沒有接上既有的識別傳遞與日誌設定。AI 能協助沿著呼叫鏈找出缺口，將各層的紀錄接回同一次操作，後續分析時也才有連貫的資料可用。

效能指標讓我們知道哪裡值得注意；貫穿流程的共同識別與結構化日誌，則讓我們能追到某一次操作實際經過的流程，找到下一步值得調查的位置。

「我們有異常通知嗎？」
「有，出事的時候會有人打電話來。」
「那有了Correlation ID之後呢？」
「現在電話一響，我們就知道誰打來抱怨了。」