オブザーバビリティ

S4 Metrics

カスタムメトリクスのカーディナリティを統制

メトリクスのカーディナリティ統制置き換え対象のAWSサービス: CloudWatch カスタムメトリクス

CloudWatchカスタムメトリクスの請求を削減。取り込みエッジでカーディナリティを統制し、自動ベースライン化とAWS Organization横断の節約ロールアップを提供します。

S4 Metrics は、取り込みエッジでCloudWatchカスタムメトリクスのカーディナリティを統制します — PutMetricDataの前に高カーディナリティな次元を落とし、数値をバケット化し、ウィンドウ集約。必要な系列ぶんだけ課金され、青天井の系列爆発を防ぎます。OSSのmetricsdコレクタ(StatsD/DogStatsD + OTLP/EMF/PutMetricData入力)が統制を担いCloudWatchへ出力、任意でフル解像度のS3/Prometheusティーも。コマーシャル層は自動ベースライン(高コスト次元のランク付けとライブListMetricsに基づくルール案)とOrganization連結ロールアップを追加します。

課題

CloudWatch のカスタムメトリクスは一意の時系列（名前空間 + メトリクス名 + ディメンション値の組み合わせ）単位で課金され、最初の 10,000 系列は 1 系列あたり月 $0.30 という階層で積み上がります。user_id・request_id・path・instance_id といったわずかな高カーディナリティのディメンションが組み合わせ的に数千〜数万の系列へ膨張し、請求額を押し上げます。請求を膨らませるのはバイト数やリクエスト量ではなく、この歯止めのない一意系列の増殖です。

仕組み

1
テレメトリを metricsd へ向ける

StatsD/DogStatsD・OTLP・EMF・PutMetricData の送信先エンドポイントを metricsd コレクターへ向け替えるだけで、アプリケーションのコードは変更不要です。
2
高コストなディメンションを棚卸し

auto-baseline が ListMetrics で読み取り専用にアカウントを棚卸しし、課金系列への寄与でディメンションを順位付けして、価格付きのガバナンスルールを提案します。
3
PutMetricData の前にガバナンス適用

ルールでディメンションを drop・rollup・bucket・ウィンドウ集約してから送出し、支払う価値のある系列だけを CloudWatch の課金経路へ流します。

特長

取り込み時のカーディナリティ統制: PutMetricDataの前にdrop/bucket/aggregate。

自動ベースライン: 最もコストの高い次元をランク付けし、価格付きのルールセットを提案。

AWS Organizations連結ロールアップ(ListMetricsのみの読み取り専用クロスアカウントロール経由)。

含まれるもの

OSS コレクター metricsd — StatsD/DogStatsD・OTLP・EMF・PutMetricData を受信し、govern → aggregate → emit で CloudWatch へ送出。
ガバナンスエンジン — ディメンションを keep / drop / rollup / bucket / sample で決定的に変換し、60 秒ウィンドウ集約と DDSketch 分位点で 1 リクエスト 1 系列の送出を止めます。
階層対応のドル建てドライラン見積り — CloudWatch の階層に対して before/after/savings をファイルまたはライブの ListMetrics スキャンから算定（適用前に確認可能）。
auto-baseline ルール提案（商用）— 高コストなディメンションを順位付けし、価格付きのルールセットを OSS そのままの YAML で書き出します。
AWS Organizations 連結セービングス集計（商用）— 読み取り専用・tier-correct なアカウント別および組織合計の見積り。
任意のフル解像度ティー — 削除したディメンションを S3 または Prometheus remote-write へミラーし、詳細を捨てずに系列課金の経路から外します。
OSS そのままの YAML ルール — オープンソースの metricsd がそのまま読み込み、ロックインはありません。

こんな用途に

user_id・request_id・path などがメトリクスに乗って数千の系列へ膨張し、カスタムメトリクス料金が暴走しているチーム。

カーディナリティコストの所在を、tier-correct な連結ビューで一元把握したいマルチアカウント組織。

支出前のコストレビュー — ドライランで候補ルールを価格付けし、何も変更せずに想定セービングスを AMI 料金と比較。

調査用にフル解像度の詳細は保持しつつ、それを系列課金の経路から外したいチーム（S3 / Prometheus ティー）。

よくある質問

落としたディメンションのデータは失われますか。

いいえ。落としたディメンションはフル解像度で S3 または Prometheus remote-write へティーできます。詳細は削除されず、系列単位で課金されない保存先へ移されるだけなので、調査時にはティーから user_id などを読み戻せます。

ロックインされませんか。

されません。すべてのルールはオープンソースの metricsd がそのまま読み込む OSS の YAML で、提案は提示前に OSS エンジンでラウンドトリップ検証されます。サブスクリプションを解約しても、コレクターとルールはそのまま動き続けます。

どのようにアカウントへ安全にアクセスし、どこで動きますか。

商用 CLI は完全に読み取り専用（cloudwatch:ListMetrics・organizations:ListAccounts・sts:AssumeRole のみ）で、メトリクスの送出やアカウントの変更は一切行いません。クロスアカウントのスキャンは、お客様が作成し ListMetrics のみを付与するロールを、CloudTrail で監査できる固定セッション名で AssumeRole します。すべてお客様の VPC 内の AMI で動作します。

どの入力に対応していますか。

metricsd は StatsD/DogStatsD（UDP）と、HTTP 上の OTLP メトリクス・EMF・PutMetricData を受信します。移行は送信先エンドポイントの変更のみです。

オープンソースと商用版の違いは何ですか。

コレクター（ingest/govern/aggregate/emit）と階層対応のドライランは Apache-2.0 のオープンソース metricsd です。商用層はその上に、ルールを書き出す ListMetrics auto-baseline、AWS Organizations 連結集計、セービングスダッシュボード、ワンクリックの AMI/CloudFormation デプロイを追加します。フォークではなく OSS コアの上に構築されています。