In Production 3──如果資料要加上一個期限，我希望是一萬年

可觀測性資料不是收集完就沒事了。儲存哪些資料、保留多久、用什麼方式儲存——這三個問題的答案，直接決定了你的可觀測性系統是每月花幾百美元還是幾萬美元。

儲存哪些資料#

不是所有產生的 Telemetry 資料都值得儲存。在資料進入儲存層之前，先問自己：這筆資料在未來會被誰、在什麼情境下查詢？如果答不出來，它可能就不需要被儲存。

Metrics 的儲存成本主要由時間序列數量決定，而時間序列數量由 Label 的排列組合決定。這就是所謂的高基數（High Cardinality）問題：

一個 http_requests_total Metric 加上 method、status_code、endpoint 三個 Label，排列組合可能只有幾百個
但如果再加上 user_id 這個 Label，時間序列數量就會爆炸到數百萬

控制 Label 維度的原則：

高基數問題是 Metrics 系統最常見的故障原因之一。一個不小心加上的高基數 Label，可能在幾小時內吃光所有記憶體和儲存空間。

Traces 的資料量通常是三大信號中最大的。每個請求都可能產生數十個 Span，每個 Span 都帶有豐富的上下文資訊。全量儲存所有 Traces 在大多數情況下既不經濟也不必要。

取樣策略的選擇：

Head-based Sampling（頭部取樣）：在請求進入系統時就決定是否取樣。簡單、低開銷，但可能錯過有問題的請求
Tail-based Sampling（尾部取樣）：等整個 Trace 完成後再決定。可以根據結果（如錯誤、高延遲）選擇性保留，但需要更多資源來暫存資料
混合策略：對錯誤請求 100% 保留，對正常請求按比例取樣。這是最常見的生產實踐

即使採用取樣，仍然可以從取樣的 Traces 中生成精確的 Metrics（如 RED Metrics）。OpenTelemetry Collector 的 Span Metrics Connector 就能做到這一點——用少量的 Trace 儲存成本，獲得完整的 Metrics 覆蓋。

Logs 是最「自由奔放」的信號——開發者想記什麼就記什麼，格式也五花八門。正因如此，Logs 也最容易失控：

不同類型的信號有不同的「保鮮期」。過了保鮮期的資料，查詢頻率急劇下降，但儲存成本持續累積。

Metrics：適合長期保留（數月到數年），因為 Metrics 的單筆資料量小，長期趨勢分析（容量規劃、季節性分析）需要歷史資料。但長期資料不需要原始精度
Traces：適合短期保留（1-7 天，最多 30 天）。Traces 主要用於排查近期問題，很少有人會去查一個月前的 Trace。資料量大、查詢價值隨時間快速遞減
Logs：保留期限取決於合規需求。有些產業法規要求日誌保留 1-7 年，但大部分操作性日誌保留 30-90 天就夠了

降取樣是長期保留 Metrics 的關鍵手段。原理很簡單：你不需要用秒級精度看去年的 CPU 使用率，分鐘級甚至小時級就足夠了。

典型的降取樣策略：

降取樣可以將長期 Metrics 的儲存成本降低 90% 以上，同時保留足夠的精度供趨勢分析使用。

降取樣不只是「丟掉資料點」。好的降取樣會保留每個時間區間內的最小值、最大值、平均值和計數，確保你仍然能看到異常峰值，而不是被平均值抹平。

現代可觀測性後端（Grafana Mimir、Grafana Loki、Grafana Tempo、Thanos）幾乎都支援以**物件儲存（Object Storage）**作為主要的持久化層：

物件儲存的優勢在於成本極低、容量幾乎無限、內建冗餘。它的劣勢是查詢延遲較高，但透過適當的快取層可以緩解。

**冷熱分離（Tiered Storage）**是平衡效能與成本的關鍵架構：

大部分的查詢都集中在最近的資料上，冷熱分離讓你用最少的高速儲存服務最多的查詢需求。

手動管理資料的保留和清除不切實際，也容易出錯。你需要自動化的 Retention Policy：

最有效的成本控制手段不是在儲存端省錢，而是在收集端就過濾掉不需要的資料。OpenTelemetry Collector 提供了多種 Processor 來實現這一點：

在收集端過濾資料是不可逆的——被丟棄的資料就找不回來了。在啟用 Filter 之前，先確認你真的不需要這些資料。一個好的做法是先觀察一段時間，確認哪些資料從未被查詢過，再逐步加入過濾規則。