カーディナリティ

概要

カーディナリティは、監視データに付けたタグキー 1 つに対して、実際に現れるタグ値が何種類あるかを表す数です。<code>env</code> が本番・検証・開発の 3 通りならカーディナリティは 3、ユーザー ID をタグにすれば利用者の数だけ増えます。厄介なのは、この数がタグキーごとに掛け合わされる形で総量に効くことです。値の種類が有限なタグを足す判断と、上限のない値を足す判断は、見た目の作業量が同じでも結果がまったく違います。ダッシュボードの重さ、割当の消費、請求額の読みにくさは、たいていこの一点に由来します。タグを増やすかどうかを決める場面では、便利かどうかではなく、値が何種類まで伸びうるかを先に見積もるのが実務の順序です。

1 つのタグキーに、値が何種類あるか

Datadog の公式用語集は、カーディナリティを「あるメトリクスについて、1 つのタグキーに紐づくタグ値の個数」という意味で説明しています。数える対象がタグキー単位である点が要点です。env というキーに production・staging・development の 3 つの値が現れるなら、env のカーディナリティは 3 です。region が 5 拠点なら 5、user_id が登録利用者の数だけあるなら、その数がそのままカーディナリティになります。 この数え方に慣れると、監視設計の会話が具体的になります。「タグを増やすと重くなる」という言い方は原因を指していません。重くなるのはタグの本数ではなく、各キーの値の種類が掛け合わされた結果です。だからこそ、キーごとに「このキーは何種類まで伸ばしてよいか」という上限を決める発想が効きます。カーディナリティは観測される現象の名前ですが、実務では割り当てる予算として扱うほうが判断が早くなります。タグを設計するときに、キーの一覧ではなくキーごとの値の種類数を書き出す形にすると、後から効いてくる差が最初に見えます。

足し算ではなく掛け算で伸びる

カーディナリティが問題になるのは、それが掛け算の因数として働くからです。1 つの指標に対して 3 本のタグが付き、それぞれの値の種類が 20・3・40 だとすると、組み合わせは 2,400 通りになります。ここに 1 本、値の種類が上限のないタグを足した瞬間、総量は見積もれる数から見積もれない数へ移ります。

最後の行が実際の事故の形です。Datadog の公式ドキュメントは、エポック秒のタイムスタンプ・ユーザー ID・リクエスト ID のように上限のない値をタグに入れると、メトリクスが無制限に増えると明示的に警告しています。追加した本人には「調査のために 1 本足しただけ」に見えるところが問題で、増えるのは足した 1 本ではなく、既にあった 2,400 通りに掛かる形の総量です。 上限のある値でも、掛け算である事実は変わりません。値の種類が 5 のタグを 1 本足せば、単純計算で総量は 5 倍になります。逆に言えば、削る側も掛け算で効きます。カスタムメトリクスの個数を減らしたいときに、指標の名前を統合しても総数が動かないのは、名前の本数が因数ではなくタグ値の種類が因数だからです。

送る量と、検索できる量を切り離す

掛け算の性質そのものは変えられませんが、Datadog には掛け算の対象を絞る仕組みがあります。2026 年 8 月時点の公式ドキュメントによれば、Metrics without Limits はカスタムメトリクスの取り込みと索引付けを切り離す機能で、送信自体はそのまま行われ、そのうちどのタグを検索・グラフ・モニターから使えるようにするかを利用者が選びます。 指定のしかたは 2 通りです。使うタグを列挙する許可リスト方式と、外すタグを名指しする除外リスト方式で、API では exclude_tags_mode を true にすると後者になります。単一メトリクスの設定画面は、過去 30 日間に実際に問い合わせられたタグをもとにした推奨の許可リストがあらかじめ入る作りです。問い合わせに一度も使われていない指標については、許可リストを空にして索引付けをやめる選択もできます。 運用上の注意も公式に明記されています。まず、タグを管理する前にそのメトリクスの型が決まっている必要があります。次に、一括設定の既定値は「すべてのタグを許可」で、個別に積み上げた設定を上書きします。そして見積もり表示で索引付け後の量が取り込み量より大きく出た場合は、その設定を保存してはいけないとされています。利用量の画面ではこの 2 つの量が Ingested と Indexed として別に見えるため、設定変更の効き方は感覚ではなく数字で確かめられます。 課金との関係は契約している方式で変わります。公式ドキュメントは、カーディナリティに基づく方式では設定済みの指標だけが取り込み量に数えられ、未設定の指標は索引付け後の量だけが対象になると説明しています。一方、メトリクス名に基づく方式では、設定にかかわらず送信したデータポイントがすべて取り込み量に数えられます。どちらの方式かを知らずに削減作業を始めると、手間をかけた側の数字が動かないという結末になります。

見積もらずに使うとどうなるか、そして混同しやすい相手

カーディナリティという見方を持たない監視は、タグを足すか足さないかの判断を「あると便利か」だけで決めることになります。その結果は 2 つの形で表れます。1 つはダッシュボードや検索の重さで、もう 1 つは月末に届く数字の読みにくさです。どちらも原因が構成の中に散らばっているため、後から探すと時間がかかります。カーディナリティを先に見積もっておけば、「このタグは値が 6 種類だから入れる」「これは利用者数に比例するから入れない」という形で、判断が 1 分で終わります。 混同が目立つのは、量が増える原因を送信の頻度だと考えることです。頻度を落としても組み合わせの数は減らないため、この方向の対策はほとんど効きません。もう 1 つは、設定から消したタグは過去のデータからも消えると考えることです。索引付けの設定を変えた効果はそれ以降に及ぶもので、すでに保持されている系列の履歴が遡って書き換わるわけではありません。データベースの世界で言うカーディナリティ (列に含まれる異なる値の数) とほぼ同じ発想ですが、Datadog では対象がタグキーであり、費用と表示速度に直結する点が違います。 近い言葉を並べると輪郭が出ます。タグは目印そのもの、カーディナリティはその目印が取る値の種類数、カスタムメトリクスは組み合わせを 1 個として数えたときの単位です。メトリクスは数値の時系列という上位の概念で、カーディナリティはそこに付く属性の広がりを指します。インフラ監視のようにホスト単位で自動的にタグが付く領域では、利用者が意識しないところでもキーが増えるため、定期的に値の種類を確認する習慣が役に立ちます。一次情報は Datadog の公式ドキュメント Glossary と Metrics without Limits にあります。