概要

タグ付けは、モニターするマシンとメトリクスにクエリを実行するために Datadog 全体で使用されます。タグに基づく割り当てとフィルターの機能がないと、環境内の問題を発見し、根本的な原因を見つけられるまで絞り込むことが難しくなります。先に進む前に、Datadog での タグの定義 方法について学んでください。

タグはさまざまな方法で構成することができます。

• Datadog Agent 構成ファイルまたは各インテグレーションの構成ファイル
• Datadog UI を使用
• Datadog API を使用
• DogStatsD を使用

タグの割り当て方法

構成ファイル

tags: ["<KEY_1>:<VALUE_1>", "<KEY_2>:<VALUE_2>", "<KEY_3>:<VALUE_3>"]

tags:
    - "<KEY_1>:<VALUE_1>"
    - "<KEY_2>:<VALUE_2>"
    - "<KEY_3>:<VALUE_3>"

# Set the hostname (default: auto-detected)
# Must comply with RFC-1123, which permits only:
# "A" to "Z", "a" to "z", "0" to "9", and the hyphen (-)
hostname: mymachine.mydomain

tags: <KEY_1>:<VALUE_1>, <KEY_2>:<VALUE_2>, <KEY_3>:<VALUE_3>

# Set the hostname (default: auto-detected)
# Must comply with RFC-1123, which permits only:
# "A" to "Z", "a" to "z", "0" to "9", and the hyphen (-)
hostname: mymachine.mydomain

インテグレーションの継承

タグを割り当てる最も効率的な方法は、インテグレーションの継承を利用することです。AWS インスタンス、Chef レシピ、およびその他のインテグレーションに割り当てるタグは、Datadog に送信するホストとメトリクスによって自動的に継承されます。

コンテナ化環境では、unified service tagging のドキュメントに従って、すべての Datadog テレメトリの構成を管理する単一ポイントを構築することをお勧めします。

クラウドインテグレーション

クラウドインテグレーション は認証ベースです。Datadog では、メインのクラウドインテグレーションタイル（AWS、Azure、Google Cloud など）を使用し、可能な場合は、Agent をインストール することを推奨しています。注: Agent のみの使用を選択した場合、一部のインテグレーションタグは利用できません。

Web インテグレーション

Web インテグレーション は認証ベースです。メトリクスは API 呼び出しで収集されます。注: CamelCase タグは、Datadog によってアンダースコアに変換されます (例: TestTag –> test_tag)。

環境変数

コンテナ化された Datadog Agent をインストールしたら、Agent のメイン構成ファイルにある環境変数 DD_TAGS を使用してホストタグを設定します。複数のタグを指定する場合は、スペースで区切ってください。

注: DD_TAGS 環境変数では、タグの区切り文字としてスペースを使用します。たとえば、DD_TAGS="key1:val1 key2:val2" の場合は 2 つのタグが設定されます。DD_TAGS="test:this is a test" という値の場合は、スペースで区切られた各トークンが個別のタグとして扱われるため、4 つの異なるタグ (test:this、is、a、test) が生成されます。タグ値にスペースを含めるには、代わりに YAML 構成またはインテグレーションアノテーションを使用してタグを設定します。これらの方法では、スペースがアンダースコアに変換されます (たとえば、test:this is a test は test:this_is_a_testになります)。

Datadog は、Docker、Kubernetes、ECS、Swarm、Mesos、Nomad、Rancher から一般的なタグを自動的に収集します。さらに多くのタグを抽出するには、次のオプションを使用します。

例:

DD_KUBERNETES_POD_LABELS_AS_TAGS='{"app":"kube_app","release":"helm_release"}'
DD_CONTAINER_LABELS_AS_TAGS='{"com.docker.compose.service":"service_name"}'

DD_KUBERNETES_POD_LABELS_AS_TAGS を使用する場合、次の形式のワイルドカードを使用できます。

{"foo": "bar_%%label%%"}

たとえば、{"app*": "kube_%%label%%"} はラベル application のタグ名 kube_application に解決されます。さらに、{"*": "kube_%%label%%"} はすべての Pod ラベルを kube_ で始まるタグとして追加します。

Docker Swarm docker-compose.yaml ファイル内で DD_CONTAINER_LABELS_AS_TAGS 変数を使用する際は、次の例のように、アポストロフィーを削除します。

- DD_CONTAINER_LABELS_AS_TAGS={"com.docker.compose.service":"service_name"}

Docker コンテナにラベルを追加する際は、docker-compose.yaml ファイル内で labels: キーワードをどこに配置するかが重要となります。問題が発生しないようにするには、Docker unified service tagging に関するドキュメントを参照してください。

この構成の外部でコンテナにラベル付けを行う必要がある場合は、labels: キーワードを services: セクションの内部に配置します。deploy: セクションの内部には配置しません。labels: キーワードを deploy: セクション内に配置するのは、サービスに対してラベル付けが必要な場合のみです。この配置が正しくないと、Datadog Agent はコンテナからラベルを抽出することができません。

以下は docker-compose.yaml ファイル内でこのラベルの配置を行う場合のサンプルです。この例では、myapplication:セクションのラベル my.custom.label.project と my.custom.label.version のそれぞれに固有の値が設定されています。datadog: セクションの DD_CONTAINER_LABELS_AS_TAGS 環境変数を使用してラベルを抽出し、myapplication コンテナ用のタグを生成します。

myapplication コンテナ内のラベルは、my.custom.label.project および my.custom.label.version です。

Agent がコンテナからラベルを抽出すると、タグは次のようになります。 projecttag:projectA versiontag:1

サンプル docker-compose.yaml:

services:
  datadog:
    volumes:
      - '/var/run/docker.sock:/var/run/docker.sock:ro'
      - '/proc:/host/proc:ro'
      - '/sys/fs/cgroup/:/host/sys/fs/cgroup:ro'
    environment:
      - DD_API_KEY= "<DATADOG_API_KEY>"
      - DD_CONTAINER_LABELS_AS_TAGS={"my.custom.label.project":"projecttag","my.custom.label.version":"versiontag"}
      - DD_TAGS="key1:value1 key2:value2 key3:value3"
    image: 'registry.datadoghq.com/agent:latest'
    deploy:
      restart_policy:
        condition: on-failure
      mode: replicated
      replicas: 1
  myapplication:
    image: 'myapplication'
    labels:
      my.custom.label.project: 'projectA'
      my.custom.label.version: '1'
    deploy:
      restart_policy:
        condition: on-failure
      mode: replicated
      replicas: 1

変数は、カスタムの datadog.yaml で定義するか、環境変数で JSON マップとして設定します。マップキーはソース (label/envvar) 名、マップ値は Datadog タグ名です。

タグカーディナリティ

タグカーディナリティを設定する環境変数には、DD_CHECKS_TAG_CARDINALITY と DD_DOGSTATSD_TAG_CARDINALITY の 2 つがあります。DogStatsD の料金設定が異なるため、それに応じて DogStatsD タグカーディナリティも細かく構成できるように分けられています。それ以外は、これらの変数は同じように機能します。使用できる値は、low、orchestrator、または high です。どちらもデフォルトは low で、Kubernetes クラスターレベルのタグを取り込みます。

カーディナリティの設定によって、次のように対象が異なります。

• low: kube_namespace のような Kubernetes クラスターレベルのタグ。
• orchestrator: pod_name のような Pod レベルのタグ。
• high: container_id のようなコンテナレベルのタグ。

カーディナリティによって、Kubernetes と OpenShift および Docker、Rancher、Mesos とで異なるタグのセットがすぐに使えるように用意されています。ECS と Fargate では、変数を orchestrator に設定すると task_arn タグが追加されます。

注:

• DogStatsD メトリクス用のコンテナタグを送信すると、作成されるメトリクスが増える場合があります (ホストごとではなく、コンテナごとに 1 つ)。これにより、Custom Metrics の請求額が変化する場合があります。
• メトリクスでは、タイムスタンプは最も近い秒に丸められます。同じタイムスタンプのポイントが複数ある場合は、最新のポイントで以前のポイントが上書きされます。設定するカーディナリティの値を大きくすることで、この問題を防止できることがあります。

トレース

Datadog SDK は環境変数、システムプロパティ、またはコード内の構成を通じて構成することができます。各 SDK のタグ付けオプションと構成の情報は、Datadog トレース設定 に関するドキュメントを参照してください。unified service tagging のドキュメントでも、unified service tagging 用の SDK を構成する方法をご覧いただけます。

使用する SDK にかかわらず、スパンメタデータはタイプ化されたツリー構造に従う必要があります。ツリーの各ノードは . で分割され、各ノードのタイプは 1 つのみとなります。

たとえば、ノードをオブジェクト (およびサブノード) と文字列の両方に設定することはできません。

{
  "key": "value",
  "key.subkey": "value_2"
}

上記のスパンメタデータは、key の値が文字列 ("value") を参照できないこと、またサブツリー ({"subkey": "value_2"}) であることから無効となります。

UI

UI でホストタグを割り当てる場合は、ホストマップページ を使用します。任意の六角形 (ホスト) をクリックすると、ページの下部にホストオーバーレイが表示されます。次に、[User] (ユーザー) セクションにある、[Add Tags] (タグを追加) ボタンをクリックします。タグをカンマ区切りのリストとして入力したら、[Save Tags] (タグを保存) をクリックします。UI でのホストタグの変更は、適用されるまで最大 5 分かかる場合があります。

[インフラストラクチャーリストページ] を使用して、UI でホストタグを割り当てます。ホストをクリックすると、ページの右側にホストオーバーレイが表示されます。次に、[User] (ユーザー) セクションにある、[Add Tags] (タグを追加) ボタンをクリックします。タグをカンマ区切りのリストとして入力したら、[Save Tags] (タグを保存) をクリックします。UI でのホストタグの変更は、適用されるまで最大 5 分かかる場合があります。タグを追加したら、タグが UI に表示されていることを確認してから、さらにタグを追加してください。

モニターの管理 ページで、各モニターの隣にあるチェックボックスをオンにしてタグを追加します (1 つ以上のモニターを選択します)。[Edit Tags] (タグを編集) ボタンをクリックします。タグを入力するか、以前に使用したものを選択します。次に、[Add Tagtag:name] または [Apply Changes] (変更を適用) をクリックします。以前にタグを追加してある場合は、タグチェックボックスを使用して一度に複数のタグを割り当てることができます。詳しくは、モニターの管理ドキュメント を参照してください。

モニターを作成する場合は、ステップ 4 [Say what’s happening] (発生している事象を説明する) または [Notify your Team] (チームへの通知) でモニタータグを割り当てます。

最大 10 個のタグの許可リストをメトリクスに適用することにより、ディストリビューションメトリクス 内でパーセンタイル集計を作成します。これにより、タグ値のクエリ可能な組み合わせすべての時系列が作成されます。ディストリビューションメトリクスから出力される Custom Metrics と時系列のカウントの詳細については、Custom Metrics を参照してください。

最大 10 個のタグを適用します。除外タグは使用できません。

AWS インテグレーションタイルでは、アカウントレベルのすべてのメトリクス、および 自動サブスクリプショントリガー によって送信されたログに追加のタグを割り当てることができます。<KEY>:<VALUE> の形式で、タグのカンマ区切りのリストを使用します。

SLO を作成する場合は、ステップ 3 [Add name and tags] (名前とタグを追加) でタグを割り当てます。

API

Web server 1: api.metric('page.views', [(1317652676, 100), ...], host="example_prod_1")
Web server 2: api.metric('page.views', [(1317652676, 500), ...], host="example_prod_2")

Web server 1: api.metric('page.views', [(1317652676, 100), ...], tags=['domain:example.com'])
Web server 2: api.metric('page.views', [(1317652676, 500), ...], tags=['domain:example.com'])

sum:page.views{domain:example.com}

sum:page.views{domain:example.com} by {host}

DogStatsD

DogStatsD に送信するメトリクス、イベント、サービスチェックにタグを追加します。たとえば、アルゴリズムのバージョンでタイマーメトリクスをタグ付けすると、2 つのアルゴリズムのパフォーマンスを比較できます。

@statsd.timed('algorithm.run_time', tags=['algorithm:one'])
def algorithm_one():
    # Do fancy things here ...

@statsd.timed('algorithm.run_time', tags=['algorithm:two'])
def algorithm_two():
    # Do fancy things (maybe faster?) here ...

注: タグ付けは、StatsD の Datadog 固有の拡張機能 です。

host タグを DogStatsD メトリクスに割り当てる場合は、特別な考慮事項が必要です。ホストタグキーの詳細については、メトリクスの送信: DogStatsD のドキュメントを参照してください。

参考資料

お役に立つドキュメント、リンクや記事:

タグの概要よくあるご質問 Datadog でのタグの使用方法よくあるご質問