タグ

概要

タグは、ホスト・コンテナ・メトリクス・ログ・トレースといったばらばらの対象に共通の目印を付け、同じ属性を持つものを横断して呼び出せるようにする仕組みです。Datadog では値だけのタグも使えますが、環境や役割といった意味を明示できる <code>key:value</code> の形が推奨されます。検索条件を書くときの道具に見えて、実際にはどの単位で集計し、どの単位でアラートを分け、どの単位で費用を数えるかを決める設計対象です。命名の規約を後から変えるのは難しいため、導入の初期に決めておく価値があります。

タグは検索条件ではなく集計の単位

タグの形式は key:value か、値だけの単純な文字列です。キーとして扱われるのは最初のコロンまでの部分で、env:staging:east であればキーは env、値は staging:east になります。Datadog が値だけの形よりも key:value を勧めるのは、キーがあれば「環境ごとに分ける」「役割ごとに合計する」といった操作を機械的に書けるからです。

最後の点が見落とされがちです。タグは付けても消しても表示上は同じように見えますが、値の種類が増えれば内部で保持される系列の数が増えます。タグ設計は見せ方の話ではなく、集計の単位を決める話だと考えたほうが実態に合います。

予約されたキーと、3 製品をつなぐ 3 つのタグ

Datadog にはあらかじめ意味が決まっているキーがあります。2026 年 8 月時点の公式ドキュメントでは host、device、source、service、env、version、team が予約キーとして挙げられています。これらを自分の都合で別の意味に使うと、製品側が期待する紐付けが働かなくなります。 なかでも env、service、version の 3 つは統一サービスタグと呼ばれ、メトリクス・トレース・ログを同じ語彙でつなぐための軸として位置づけられています。障害調査で「このサービスの本番環境の、このバージョンだけ」を 3 種類のデータに対して同じ条件で問い合わせられるかどうかは、この 3 つを最初から揃えたかどうかで決まります。あとから揃えようとすると、過去に取り込まれたデータには目印が付いていないため、比較したい期間ほど穴が空きます。

文字種と正規化の落とし穴

タグには機械的な規則があり、意図した文字列がそのまま残るとは限りません。2026 年 8 月時点の規則では、タグは文字で始まらなければならず、2 文字目以降に使えるのは文字・数字・アンダースコア・マイナス・コロン・ピリオド・アットマークです。スラッシュも許可されていますが、HTTP 経由で取り込むログのタグに限られます。それ以外の文字、たとえばカンマや空白や絵文字はアンダースコアに置き換えられ、連続したアンダースコアは 1 つに縮められ、先頭と末尾のアンダースコアは削られます。長さはキーとコロンと値を合わせて最大 200 文字です。 大文字小文字の扱いは対象によって違います。メトリクスのタグとスパンのタグは小文字に正規化されるため、キーを camel case で書く意味はありません。一方でログの属性やスパンの属性は大文字小文字を区別し、正規化されません。ここを同一視すると、片方では同じものとして扱われ、もう片方では別物として扱われる状態が生まれます。 クラウド事業者から取り込むタグも、事業者ごとに正規化の癖が違います。公式ドキュメントは AWS が TestTag を testtag にする例と、Alibaba Cloud が test_tag にする例を並べています。環境変数 DD_TAGS の場合はさらに癖があり、空白がアンダースコアにならず区切りとして解釈されるため、test:this is a test と書くと 4 つのタグができます。

無制限に増える値を入れない

設計判断として最も効くのは、値の種類が有限かどうかを入れる前に確かめることです。公式ドキュメントは、エポック秒のタイムスタンプ・ユーザー ID・リクエスト ID のように上限のない値をタグにすると、メトリクスが無制限に増えると警告しています。数字で始まるタグも、文脈によっては動くものの、種類を増やす方向に働き挙動が一貫しません。 この手の失敗が厄介なのは、壊れ方が静かなことです。グラフは描かれ、検索も通り、ただ系列の数だけが増えていきます。気づくきっかけは表示の不具合ではなく、集計が重くなったことや、利用量の見積もりが合わないことです。 もう一点、Agent はタグの優先順位を強制しません。設定ファイルと環境変数と別の経路から同じキーを与えると、1 つのキーに複数の値が並ぶ状態になり得ます。公式ドキュメントも service に 3 つの値が付く例を挙げています。集計の分母が意図せず割れる原因になるので、同じキーを与える経路を 1 本に絞っておくのが安全です。

いつ気にする概念か、よくある誤解

タグを真剣に設計するタイミングは、監視対象が 2 台目に増えたときです。1 台のうちは名前で足りますが、2 台目からは「まとめて見る」「片方だけ見る」の両方が必要になり、その切り替えを支えるのがタグだからです。逆に、対象が増えてから規約を入れ直すと、古いデータに目印を付け直せないという壁に当たります。 誤解として多いのは 3 つです。第一に、表記の揺れは Datadog が吸収してくれるという思い込み。メトリクスとログで正規化の扱いが違うため、揺れは残るところに残ります。第二に、キーを省いて値だけのタグを並べても同じという思い込み。値だけでも検索はできますが、集計の軸として使えないため後から効いてきます。第三に、タグは多いほど便利という思い込み。増やせるのは種類が有限な軸だけで、無制限に伸びる値は監視そのものを重くします。 タグの規則の一次情報は Datadog の公式ドキュメント Getting Started with Tags にまとまっています。実際のタグの多くは Datadog Agent の設定やクラウド統合を通じて付くため、付け方の実務はそちらの解説が入り口になります。