こんにちは！日々のシステムの監視やメトリクス収集、本当にお疲れ様です。
ふとDatadogの請求書を見て、「うわっ、今月もカスタムメトリクス代が跳ね上がってる……！」と冷や汗をかいた経験はありませんか？
「ユーザーID」や「リクエストのURL」といった高いカーディナリティ（値の多様性）を持つタグをメトリクスに付与した瞬間、Datadogのインデクシングコストは爆発的に膨れ上がります。それを恐れて「泣く泣く重要なタグの付与を諦める」というのは、オブザーバビリティの世界では最大の敗北と言っても過言ではありません。
ですが、安心してください。今日ご紹介する「Metrics Without Limits」をマスターすれば、その悩みは綺麗に消え去ります。
今回は、この機能の仕組みから、コストを抑えつつ全てのメトリクスを安全にキャプチャする「現場の裏技」まで、優しく丁寧にお伝えしていきますね。これをマスターすれば、毎日のコスト管理やメトリクス設計のストレスが劇的に軽くなりますよ！
—
1. 高いカーディナリティが引き起こす「Datadogのコスト地獄」
まずは、なぜカスタムメトリクスがコストの魔物と化すのか、その原因をサクッとおさらいしておきましょう。
Datadogのカスタムメトリクス課金は、基本的に「メトリクス名 × ユニークなタグの組み合わせ（タイムシリーズ数）」で決まります。
例えば、次のようなメトリクスを送信したとします。
app.http.request.latency{status=”200″, user_id=”12345″, endpoint=”/api/v1/items”}
もし `user_id` が10万人分、`endpoint` が50種類あったとしたらどうでしょう？ たった1つのメトリクス名から、一瞬で何百万もの時系列データ（タイムシリーズ）が生成されます。Datadog側でこれをインデックスし続けると、翌月の請求書を見て経営陣から呼び出される大惨事になりかねません。
従来の対策は、「送信側（アプリケーションやStatsD）のコードを書き換えて、特定のタグを削る（事前アグリゲーション）」という非常に面倒なものでした。これでは、いざ障害が起きたときに「あのユーザーのレイテンシーはどうなっていたんだっけ？」と調べたくても、データが捨てられているので手遅れになります。
このジレンマを鮮やかに解決するのが、Metrics Without Limitsです。
—
2. Metrics Without Limits の基本アーキテクチャと魔法の仕組み
Metrics Without Limits（MWL）のコンセプトは極めてシンプル、かつラジカルです。
> 「とりあえず、すべてのタグがついたフルデータのメトリクスをDatadogに送り込め。集計やフィルタリングのルールは、後からDatadogのUI上で自由に変えればいい」
従来のフロー vs MWLのフロー
- 従来：
アプリケーション ➔ （コードでタグを削る・絞り込む） ➔ Datadogインジェスト ➔ 課金確定
- Metrics Without Limits：
アプリケーション ➔ （全タグ付きのまま素通し） ➔ Datadogインジェスト ➔ Datadog側で動的にインデックス・集計ルールを適用 ➔ コスト最適化＆保存
「えっ、じゃあ最初に全部送ったら、その瞬間に課金されちゃうんじゃないの？」と思われるかもしれませんが、ここがMWLのミソです。Datadog側で「どのタグの組み合わせをインデックスして課金対象にするか、どれを破棄するか（あるいは全体の集計に含めるか）」を後からコントロールできるのです。
—
3. 実践！Metrics Without Limits の基礎セットアップ
それでは、実際にDatadog上でこの魔法を使えるように設定していきましょう。特別なコードの書き換えは不要です。エージェントが正常にカスタムメトリクスを送信できている状態からスタートします。
ステップ1: コード側での準備（いつも通り送るだけ）
PythonのDatadogクライアント（`datadogpy` や `statsd`）を使って、高カーディナリティなタグを含めたメトリクスを送信してみましょう。
from datadog import initialize, statd
options = {
‘statsd_host’: ‘127.0.0.1’,
‘statsd_port’: 8125
}
initialize(options)
ユーザーIDやエンドポイントという高カーディナリティなタグをあえて含めて送信
statd.increment(
‘app.order.processed’,
tags=[
‘env:production’,
‘payment_method:credit_card’,
‘user_id:usr_99887766’, # 高カーディナリティなタグ
‘endpoint:/api/v1/checkout’ # 高カーディナリティなタグ
]
)
このコードを実行すると、Datadogには `user_id` や `endpoint` ごとの膨大な数のタイムシリーズが流し込まれます。
ステップ2: Datadog UIでのMetrics Without Limits設定
さあ、ここからが本番です。
1. Datadogの左側メニューから [Metrics] ＞ [Summary] に移動します。
2. コストを最適化したいカスタムメトリクス（例: `app.order.processed`）を検索して選択します。
3. メトリクス詳細画面にある [Configure Metrics Without Limits] （または類似のタグ管理・除外設定タブ）を開きます。
4. ここで、「インデックスに含めるタグ（Indexed Tags）」 と 「除外・集計するタグ」 のルールを設定します。
💡 現場で使える設定例
- 詳細分析用（直近数日）： `user_id` も含めたすべてのタグをインデックスし、詳細なトラブルシューティングに使う。
- 長期保存・コスト削減用： `user_id` はインデックスから外し（Drop）、`env` と `payment_method` だけを残して集計する。
これにより、「普段はコストを最小限に抑えつつ、必要なときだけ特定の高カーディナリティタグを復活・活用する」 という離れ業が可能になります。
—
4. 【現場の裏技】タグ付けを自由に変更しながらコストを最適化する運用ノウハウ
最後に、このMetrics Without Limitsを現場の運用に組み込み、最大限に恩恵を受けるためのプロの知見をいくつかシェアします。
裏技その1：「デバッグ期間だけタグを生かす」というアプローチ
新しい機能（新マイクロサービスや新エンドポイント）をリリースした直後は、どのリクエストでエラーやレイテンシーが悪化しているか分かりません。
リリース後1週間程度は、MWLの画面から一時的に高カーディナリティタグ（`endpoint` や `customer_tier` など）のインデックスを有効化し、原因究明を徹底します。そして、システムが安定したら再びそのタグをインデックス対象外（Excluded）に切り替えます。
コードを1行も書き直さず、デプロイも不要で、DatadogのUI上のクリックだけでこれが完結するのが最大の強みです。
裏技その2：メトリクスとログ・トレースの役割分担を明確にする
「そもそも、すべての詳細データをメトリクスで持つ必要があるのか？」という視点も忘れてはいけません。
- メトリクス（Metrics Without Limitsで軽量化）： 全体的な傾向、SLOの監視、トレンド把握。ここでは高カーディナリティタグは基本的に落とし、大まかな集計値を見る。
- APM（トレース） / ログ（Logs）： 個別のユーザーIDやエラーメッセージなど、完全な詳細を追う必要があるときは、メトリクスではなくトレースやログ（Log Managementのファセット）に任せる。
MWLはこの「メトリクスとトレース/ログの橋渡し」をスマートにしてくれます。メトリクス側で異常なスパイク（例：特定の決済方法でエラーが増えた）を検知し、詳細な原因追求はトレース側にスムーズにバトンタッチする、という理想的なオブザーバビリティ・パイプラインが構築できます。
—
まとめ
いかがでしたでしょうか？
Metrics Without Limitsは、単なる「コストカットのツール」ではありません。「データを捨てたくない開発者」と「予算を守りたいマネージャー」の双方をハッピーにする、現代の監視アーキテクチャの必須パッチです。
「コードを汚さずに、後から柔軟に集計ルールを変えられる」という安心感を手に入れたあなたなら、もうメトリクス設計で夜中にうなされることはなくなるはずです。
ぜひ、今日の業務からDatadogのMetrics Without Limitsを覗いて、自社のカスタムメトリクス帝国をスマートに最適化してみてくださいね。あなたの毎日の運用が、より軽やかで楽しいものになりますように！