「磁碟用盡」聽起來像是過去年代的笑話，但 2023 年豐田曾因伺服器磁碟空間耗盡，被迫暫停所有汽車產線。對維運者而言，磁碟空間的問題是再低階卻也再致命不過的議題。Observability 服務一樣脫離不了這個現實，本章整理資料保留期（Retention Period）相關的設計考量：要存哪些、要存多久、要怎麼存。

儲存膨脹是必然#

隨著被觀測的服務越來越多、時間累積越來越長，儲存需求也只會單調上升。如果沒有規劃好，後果不只是帳單失控，還可能演變成像前述案例般的停機事故。

「先收集，未來再說」是 Observability 入門時很常聽到的建議，但在 Production 必須加上一句「同時定期檢視這些資料還有沒有被使用」，否則就只是把成本後置。

儲存哪些#

並不是每筆資料都值得保存。為了保存而額外占用的空間，會反過來拖慢查詢效率。

Metrics#

對 Metrics 而言，可以從兩個方向縮量：

• 移除不必要的 Label。例如 http_requests_total{method="GET", path="/api/v1/users"} 通常已足夠，若多塞 user_agent、user_agent_version 等高基數 Label，會讓資料量爆量，多數情況也根本沒人查詢。
• 直接捨棄沒人使用的指標。

Grafana Labs 的 Grafana Cloud 提供了 Adaptive Metrics 功能，分析使用情形後將指標分成「未使用」、「只用部分 Label」、「全部都用」三類，並對未使用的進行移除、對部分使用的進行 Label 收斂或合併。實測顯示參與測試的客戶平均能節省 20%~50% 的儲存。

Traces#

Traces 體積容易膨脹，常見的兩種縮量手法：

• Sampling：例如 Jaeger 提供多種 Head Sampling 策略；OpenTelemetry Collector 同時支援 Head Sampling 與 Tail Sampling。Sampling 能有效降低量，但代價是部分 Traces 會消失。
• 在收集端就過濾掉沒價值的 Span：像 /health、/metrics 這類 endpoint 透過 Automatic Instrumentation 一定會被產出，但對問題排查通常沒幫助。OpenTelemetry Collector 的 Filter Processor 就能在 Pipeline 早期把它們刪除，避免無謂占用儲存。

儲存多久#

保留期需要被認真評估。太短會讓某些慢慢顯現的問題（例如效能逐步下滑）來不及被發現；太長則會把儲存空間吃乾。多數工具都提供 Retention 設定：

• Loki：retention 相關參數。
• Mimir：metrics storage retention。
• Tempo：compactor.block_retention。

這些 Retention 機制大多以「時間」為條件，而非「容量」。當突發大量資料寫入或日均量持續增長時，仍可能在 Retention 還沒到期前就把磁碟塞滿，所以儲存空間的監控不能省。

怎麼儲存#

儲存方式對成本影響甚大：

• 物件儲存（Object Storage）通常比 Block Storage 便宜，例如 GCP 上 Cloud Storage Standard Storage 與一般持久磁碟的單位價格可能差到一倍。冷儲存（Cold Storage）比熱儲存（Hot Storage）更便宜，但讀取延遲與費率不同，需要根據查詢頻率取捨。
• 多數工具支援資料壓縮，能再進一步壓低空間需求。

多租戶（Multi-tenancy）是另一個無法忽略的議題。當同一個工具或平台被不同團隊或組織共用，資料隔離就變得至關重要。Loki、Mimir、Tempo 都提供以 Tenant ID 為界的多租戶機制，搭配 S3 相容的物件儲存（例如自架的 MinIO），不同租戶的資料可被切到獨立的 Bucket 進行隔離。

設計儲存策略時，不妨從「冷／熱資料」的角度切入：近期常查的留在熱儲存，舊資料下沉到冷儲存或物件儲存歸檔。資料保留期（Retention Period）就不是一刀切的數字，而是一條分層曲線。

小結#

如同章節標題的玩笑話「如果資料要加上一個期限，我希望是一萬年」，現實裡並不存在「全部都留下來」這個選項。透過挑出真正有用的資料、選用合適的儲存後端、加上壓縮與多租戶設計，可以在預算有限的情況下盡量延長有價值的保留期。但更關鍵的，是把儲存空間納入持續監控，並隨業務成長動態調整策略，而不是上線那一刻才決定。

原文出處#

• 原書/iThome：https://ithelp.ithome.com.tw/articles/10339393