先釐清成本來源，不要只看儲存容量
正式環境的日誌成本通常不只來自保存空間，還包括代理程式傳輸、收集器運算、索引建立、查詢掃描、跨區流量與長期封存。若大量低價值資訊在應用端產生後一路送進搜尋平台，即使最後縮短保存期限，前段的傳輸與索引成本仍已發生。因此，設計採樣前應先拆解日誌管線，確認費用主要發生在寫入、索引、查詢還是保存階段。
採樣位置也會改變能力邊界。應用端採樣最能節省下游成本，但它只能根據當下已知資訊做決定，往往不知道請求稍後是否會失敗。集中式收集器能看見較完整的事件序列，適合依請求結果進行尾端採樣，代價則是資料仍須先傳到收集層。實務上常採混合設計：在來源端移除明顯噪音，於收集層保留跨服務判斷能力，再把高價值資料送入昂貴的即時索引。
先列出不可採樣的資料，再處理一般流量
不要從「正常請求保留多少」開始，而應先建立保留矩陣。每一類事件都要有保留理由、保存位置、期限與責任人。錯誤並不等於全部永久保留；某些高頻、已知且可聚合的錯誤可以限流，但必須保留首次出現、錯誤指紋、影響範圍與週期性樣本。
- 必須完整保留：安全與稽核事件、權限變更、資料寫入結果、部署與設定變更，以及法律或營運流程要求的紀錄。這類資料應走獨立管線與權限政策，不應和一般應用日誌共用隨機採樣率。
- 條件式完整保留：未處理例外、逾時、重試耗盡、外部整合失敗、資料一致性告警，以及特定高風險交易。條件應依結構化欄位判斷，而不是搜尋訊息文字。
- 一致性採樣：成功且高頻的請求可依 trace ID、request ID 或業務關聯鍵做確定性採樣。相同關聯鍵必須得到相同決策，避免只留下半條呼叫鏈。
- 摘要或聚合：健康檢查、輪詢、快取命中與重複狀態訊息，通常更適合轉成指標、計數器或週期摘要，而不是逐筆索引。
敏感資料遮罩必須發生在採樣之前。被丟棄的大多數資料仍可能短暫經過應用程式、代理程式或收集器；採樣不能取代個資、憑證與商業敏感資訊的過濾。指標也不應直接套用日誌採樣邏輯，否則錯誤率與流量基線會被扭曲。
用關聯性與動態規則保住除錯能力
真正有用的單位通常不是單一日誌列，而是一個可重建的請求或業務流程。每筆結構化日誌至少應帶有時間、服務、環境、版本、嚴重度、trace ID、request ID、操作名稱與結果；跨 LINE、ERP、CRM、雲端服務或 IoT 管線時，再加入不含敏感內容的業務關聯鍵。若系統決定保留某個失敗請求，相關服務的事件也應一起保留，否則工程師仍看不到失敗前的因果鏈。
固定採樣率容易在流量低時留下太少資料，在尖峰時又產生不可控成本。較穩健的策略會同時考慮每個服務與事件類型的預算、最低樣本量、錯誤優先級及速率上限。新出現的錯誤指紋、剛部署的版本、延遲異常或重要整合流程可以暫時提高保留；已確認且重複的噪音則逐步降低。即使錯誤原則上完整保留，也要設置防洪機制，避免單一故障把日誌平台塞滿，反而排擠其他服務的證據。
動態政策必須可解釋。建議在保留的事件中記錄採樣規則版本、決策原因與估算權重，並對被丟棄的事件維持聚合計數。這能讓值班工程師分辨「沒有發生」和「發生但未被保留」，也能在分析流量分布時校正樣本，而不把採樣後的數量誤當成真實總量。
把可追查性當成需要驗證的系統能力
採樣策略上線前，應用已知情境做演練：單一服務拋出例外、跨服務逾時、第三方 API 間歇失敗、背景工作重試耗盡，以及部署後才出現的新錯誤。對每個情境確認能否從告警或工單找到入口，沿著關聯鍵重建時間線，辨識執行版本與設定，並定位失敗邊界。若只能看到最終錯誤、看不到前序決策，採樣規則仍不合格。
營運時則應監控日誌產生量、收集器丟棄量、各規則命中量、索引延遲、查詢成本與儲存水位。規則變更要像程式碼一樣接受審查、版本化並能快速回復；事故期間可啟用有時限的診斷模式，針對指定服務、版本、租戶或關聯鍵提高保留，逾時後自動恢復，避免臨時設定永久留下。
好的採樣方案不是找到一個永久適用的比例，而是建立分級保留、一致關聯、動態調整與定期驗證的閉環。當系統橫跨企業助理、RAG、LINE、ERP、CRM、雲端與 IoT 平台時，應由各整合邊界共同定義可追查欄位，才能在控制成本的同時保留完整的事故證據。