S4 Metrics
治理 CloudWatch metric cardinality
何時收回成本?
範例:CloudWatch 自訂指標支出每月 $5,000
如果 CloudWatch 自訂指標支出為每月 $5,000,按保守 60% 降低約為 $3,000/月的可避免總使用費 — 不含 S4 軟體費、EC2 和工作負載差異。
降低 CloudWatch custom-metric 帳單:在 ingest 端治理 metric cardinality,然後在整個 AWS Organization 內自動建立 baseline 並彙總節省。
S4 Metrics 在 ingest edge 治理 CloudWatch custom-metric cardinality — 在 PutMetricData 之前丟棄 high-cardinality dimensions、對 numeric dimensions 分 bucket,並進行 window aggregation,因此只為所需 series 付費,而不是為無邊界的 series 爆炸付費。Open-source metricsd collector (StatsD/DogStatsD + OTLP/EMF/PutMetricData intake) 負責治理並發送到 CloudWatch,另可選 full-resolution S3/Prometheus tee。Commercial layer 增加 auto-baseline 和 AWS Organizations consolidated rollup。
面臨挑戰
CloudWatch 按唯一的時間序列(命名空間 + 指標名稱 + 維度值組合)對自訂指標進行計費,其中前 10,000 個序列在階梯費率下每月每個收費 $0.30。少數高基數維度 — user_id、request_id、path、instance_id — 會組合式地相乘並膨脹為數千到數萬個序列。推高帳單的不是位元組數或請求量,而是這種唯一序列的無節制爆炸。
運作原理
- 1
將遙測資料指向 metricsd
僅需將您的 StatsD/DogStatsD、OTLP、EMF 或 PutMetricData 發送端的端點覆蓋為指向 metricsd 收集器,無需改動任何應用程式程式碼。
- 2
為您成本最高的維度建立基準線
Auto-baseline 透過 ListMetrics 以唯讀方式掃描您的帳戶,根據維度對計費序列數量的貢獻進行排名,並推薦一套包含價格估算的治理規則集。
- 3
在執行 PutMetricData 之前進行治理
在發送前套用規則來 drop、roll up、bucket 和進行視窗聚合,從而僅將值得付費的序列發送到 CloudWatch 的計費路徑。
產品亮點
Ingest 時的 cardinality governance:在 PutMetricData 前 drop / bucket / aggregate。
Auto-baseline 會對成本最高的 dimensions 排名,並提出帶價格估算的 rule set。
透過 READ-ONLY (ListMetrics-only) cross-account role 實現 AWS Organizations consolidated rollup。
包含內容
- metricsd 開源收集器 — 接收 StatsD/DogStatsD、OTLP、EMF 和 PutMetricData,然後透過 govern、aggregate 並 emit 到 CloudWatch。
- 治理引擎 — 對維度進行決定性的 keep / drop / rollup / bucket / sample 轉換,並採用 60 秒視窗聚合和 DDSketch 分位數,停止每個請求都發送一個序列。
- 感知階梯費率的美元模擬執行(dry-run)— 基於檔案或即時的唯讀 ListMetrics 掃描,對照 CloudWatch 階梯計費預估變更前、變更後及節省費用,供您在套用前進行預覽。
- Auto-baseline 規則推薦(商業版)— 對成本最高的維度進行排名,並匯出包含價格估算的規則集,格式為原生的開源 YAML。
- AWS Organizations 整合節省總覽(商業版)— 以唯讀、計算精確階梯費率的方式,提供各帳戶以及組織總計的預估節省費用。
- 可選的全解析度分流(tee)— 將丟棄的維度鏡像到 S3 或 Prometheus remote-write,在保留完整細節的同時將其從按序列計費的路徑中移除。
- 原生的開源 YAML 規則 — 開源 metricsd 可以直接讀取,無廠商鎖定風險。
適用場景
由於 user_id、request_id 或 path 被記入指標並膨脹為數千個序列,導致自訂指標帳單失控的團隊。
need 透過一個計算精確階梯費率的整合檢視來集中掌握基數成本來源的多帳戶組織。
支出前的成本評估 — 在不修改任何內容的情況下,透過模擬執行對候選規則集進行估價,並將預估節省額與 AMI 費率進行對比。
需要在調查中保留全解析度細節,但又希望將其移出按序列計費路徑的團隊(透過 S3 / Prometheus 分流)。
常見問題
丟棄的維度資料會遺失嗎?
不會。被丟棄的維度可以以全解析度分流到 S3 或 Prometheus remote-write;細節沒有被刪除,只是移到了不按序列計費的儲存上,因此您可以在調查時從分流通道中讀回 user_id 等資料。
這會使我被綁定嗎?
不會。所有規則都是開源 metricsd 可以直接讀取的開源 YAML,且推薦的規則在呈現給您之前,已透過開源引擎的往返(round-trip)驗證。即使取消訂閱,您的收集器和規則也會照常執行,不受任何影響。
它是如何安全地存取我的帳戶的?它又在哪裡執行?
商業版 CLI 是完全唯讀的 — 僅包含 cloudwatch:ListMetrics、organizations:ListAccounts、sts:AssumeRole — 絕不發送指標或修改您的帳戶。跨帳戶掃描會使用可在 CloudTrail 中稽核的固定工作階段名稱,扮演(AssumeRole)您建立且僅授予 ListMetrics 權限的角色。一切均在您自己 VPC 內的 AMI 上執行。
支援哪些輸入?
metricsd 接收 StatsD/DogStatsD (UDP),以及透過 HTTP 傳輸的 OTLP 指標、EMF 和 PutMetricData。遷移只需覆蓋終端節點。
開源版和商業版有什麼區別?
收集器(ingest/govern/aggregate/emit)和感知分層的空運行(dry-run)是開源的 Apache-2.0 metricsd。商業層在此基礎上增加了可為您撰寫規則的 ListMetrics auto-baseline、AWS Organizations 聯合彙總、節省額儀表板以及一鍵式 AMI/CloudFormation 部署 — 基於 OSS 核心建構,絕非分叉。
為什麼更便宜
假設在 us-east-1 營運 10 萬條自訂時間序列 (含高基數維度)。
- 前 10k 序列 (×$0.30)
- $3,000 / 月
- 下一個 90k 序列 (×$0.10)
- $9,000 / 月
- 月度合計
- $12,000 / 月
- S3 儲存 (聚合 Parquet)
- $25 / 月
- S4 Metrics 執行個體 (m5.large + 軟體費)
- $100 / 月
- 月度合計
- $125 / 月
按時間序列數量選擇 S4 Metrics 執行個體
| 序列數量 | 推薦執行個體 | S4 Metrics 執行個體費用 | 月度合計對比 CloudWatch |
|---|---|---|---|
| ~10k | t3.medium | $45 / 月 | $50 / 月 (CWL $3,000, −98%) |
| ~100k | m5.large | $100 / 月 | $125 / 月 (CWL $12,000, −99%) |
| ~1M | m5.2xlarge | $310 / 月 | $420 / 月 (CWL $64,500, −99%) |
僅供參考。CloudWatch 自訂指標採用分級定價 (前 10k 系列 $0.30/系列, 接下來 240k $0.10, 之後 $0.05/$0.02)。S4 Metrics 將聚合後的 Parquet 寫入 S3, 僅將熱子集轉發到 CloudWatch。若保留 10k 系列的熱層, 該底價仍存在, 因此實際節省在 70–98% 之間。
計費模式
按小時計費的軟體費用 + EC2 (t3 / m5 class)。按 instance type 計量,提供年度選項。