先定義要還原的事件鏈，而不是只增加日誌量
事件調查通常卡在兩個問題：同一個操作經過 API Gateway、應用服務、訊息佇列與第三方系統後，紀錄無法互相對應；或者攻擊者取得主機權限後，可以修改或刪除本機日誌。前者是關聯問題，後者是證據可信度問題。單純提高日誌等級只會增加搜尋成本，未必能回答誰在何時、透過哪個入口、對哪筆資源做了什麼。
設計前應先列出需要重建的路徑，例如使用者登入、權限變更、資料匯出、ERP 寫入與管理員操作。每條路徑都要涵蓋同步請求與非同步工作，並區分業務事件、技術遙測及安全稽核紀錄。Trace 可以協助效能診斷，但安全事件還需要穩定的主體、目標、決策結果與資料異動資訊；三類紀錄可以共享識別碼，卻不應假設彼此能完全取代。
在信任邊界產生識別碼，並讓它一路傳遞
外部請求進入受信任環境時，系統應產生內部 correlation ID，或先驗證傳入值的格式、長度與來源。直接相信客戶端提供的識別碼，可能造成碰撞、偽造或日誌搜尋混淆。若合作系統已有自己的單號，可另存為 external reference，不要拿它取代內部識別碼。識別碼本身只用來關聯，不是授權憑證，也不應包含帳號、電子郵件或其他個人資料。
- 請求層：保存 correlation ID、trace ID 與 span ID，並在服務間透過明確的標頭或 RPC metadata 傳遞。
- 非同步層：訊息內容或 envelope 應攜帶原始 correlation ID，另外建立 message ID、job ID 與因果來源；重試不得改寫原始關聯。
- 身分層：記錄 actor ID、服務身分、租戶及驗證方式；代理操作還要區分實際操作者與被代理主體。
- 事件層：以結構化欄位記錄 action、target、result、reason code、policy version 與資料分類，避免只留下難以解析的自由文字。
- 時間層：同時保存事件時間與接收時間，統一時區並監控時鐘偏移；排序時仍須考慮佇列延遲與重送。
關聯資訊應由共用 middleware 或 SDK 自動注入，避免每個服務自行實作。若某個下游系統無法保留標頭，可在整合層建立映射表，將內部 correlation ID 與對方交易編號綁定。高基數識別碼不適合成為監控指標標籤，否則會推高成本；它們應留在日誌或追蹤儲存中，再以索引支援查詢。
防竄改不等於宣稱日誌永遠不可變
較可靠的架構會在事件產生後立即送往主機外的集中式管線，並寫入具備 append-only、物件鎖定或 WORM 能力的儲存。應用程式帳號只能新增，不能修改保存期限或刪除紀錄；管理儲存策略、查詢資料與使用簽章金鑰的權限也應分離。若刪除權與日誌都由同一個高權限帳號控制，所謂不可變只是設定上的承諾。
雜湊鏈可揭露紀錄被插入、移除或改寫，批次簽章則能證明匯出檔在簽署後未被變更，但兩者都不能阻止已入侵的服務停止送出日誌。若簽章私鑰與應用程式放在同一台主機，攻擊者也可能偽造後續紀錄，因此金鑰宜放在獨立的 KMS 或 HSM，並保留金鑰版本與輪替資訊。對關鍵事件還可在接收端產生獨立收件序號或時間戳，縮小來源端偽造時間線的空間。
讓保存策略同時支援調查、隱私與成本控制
安全日誌不應完整收錄密碼、存取權杖、Cookie、API 金鑰或原始個資。實務上應採欄位 allowlist、集中遮罩規則與 schema 驗證；需要辨識同一資料主體時，可使用受控的代碼化值，而不是把敏感內容寫入訊息。一般除錯日誌可以抽樣或縮短保存時間，但登入、權限、金鑰使用、管理操作、資料匯出與保存策略變更等稽核事件不宜被取樣。
最後要用演練驗證，而不是只檢查設定：從一個已知操作出發，確認能跨 API、背景工作、LINE、ERP、CRM 或雲端服務找到完整鏈路；模擬遺失一段紀錄，確認雜湊或序號能揭露缺口；匯出調查資料時附上查詢條件、時間範圍、檔案雜湊、簽章與金鑰版本。保留期則依風險、法規、調查週期與成本分層決定。若跨系統傳遞規則不一致，可由整合團隊先建立共用事件模型，再逐步補齊最關鍵的調查路徑。