統合サービスタグ付け

概要

統合サービスタグ付けは、3 つの予約済みタグである envserviceversion を使用して Datadog テレメトリを結び付けます。

これら 3 つのタグを使用すると、次のことができます。

  • バージョンでフィルタリングされたトレースおよびコンテナメトリクスを使用してデプロイの影響を特定する
  • 一貫性のあるタグを使用して、トレース、メトリクス、ログ間をシームレスに移動する
  • 統一された方法で環境やバージョンに基づいてサービスデータを表示する

:

  • version タグは、新しいアプリケーションのデプロイごとに変更されることが期待されています。アプリケーションのコードに異なる 2 つのバージョンがあるなら、それらの version タグは異なっていなければなりません。
  • Autodiscovery ログ構成が存在しない場合、ログの公式サービスは、デフォルトで、コンテナのショートイメージになります。ログの公式サービスをオーバーライドするには、Autodiscovery Docker ラベル/Pod アノテーション を追加します。たとえば: "com.datadoghq.ad.logs"='[{"service": "service-name"}]'
  • スパンに関連付けられているホストはデータベース/キャッシュホストではないため、データベースとキャッシュのスパンでは、ホスト情報が除外されます。

要件

  • 統合サービスタグ付けには、Datadog Agent 6.19.x/7.19.x 以上のセットアップが必要です。

  • Unified service tagging には、予約済みタグ の新しい構成をサポートする SDK バージョンが必要です。詳しい情報については、セットアップ手順 に言語ごとに記載されています。

言語最小 SDK バージョン
.NET1.17.0+
C++0.1.0+
Go1.24.0+
Java0.50.0+
Node0.20.3+
PHP0.47.0+
Python0.38.0+
Ruby0.34.0+
  • 統合サービスタグ付けでは、タグの構成に関する知識が必要です。タグの構成方法がわからない場合は、構成に進む前に、タグの概要 および タグの付け方 のドキュメントをお読みください。

構成

統合サービスタグ付けの構成を開始するには、環境を選択します。

コンテナ化環境

コンテナ化環境において、envservice、および version は、サービスの環境変数またはラベル (Kubernetes の デプロイメントと Pod ラベル、Docker コンテナラベルなど) を通じて設定します。Datadog Agent がこのタグ付け構成を検出し、コンテナから収集したデータに適用します。

コンテナ化環境で統合サービスタグ付けをセットアップするには

  1. オートディスカバリー を有効にするこれにより、Datadog Agent は特定のコンテナで実行されているサービスを自動的に識別し、そのサービスからデータを収集して、環境変数を envservice,version のタグにマッピングできます。

  2. Dockerを使用している場合は、Agent がコンテナのDocker ソケットにアクセスできることを確認してください。これにより、Agent は環境変数を検出し、それらを標準のタグにマッピングできます。

  3. コンテナオーケストレーションサービスに対応する環境は、以下のように完全構成または部分構成のいずれかに基づいて構成します。

構成

Admission Controller を有効にして Datadog クラスターエージェントをデプロイした場合、Admission Controller はPodマニフェストに変更を加え、必須環境変数のすべてを取り込みます (設定されている変更条件に基づく)。その場合、Podマニフェスト内の DD_ 環境変数の手動設定は不要です。詳しくは、Admission Controller のドキュメントを参照してください。

完全な構成

Kubernetes の使用時にすべての統合サービスタグ付けを取得するには、デプロイオブジェクトレベルとポッドテンプレート仕様レベルの両方に環境変数を追加します。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    tags.datadoghq.com/env: "<ENV>"
    tags.datadoghq.com/service: "<SERVICE>"
    tags.datadoghq.com/version: "<VERSION>" 
...
template:
  metadata:
    labels:
      tags.datadoghq.com/env: "<ENV>"
      tags.datadoghq.com/service: "<SERVICE>"
      tags.datadoghq.com/version: "<VERSION>" 
  containers:
  -  ...
     env:
          - name: DD_ENV
            valueFrom:
              fieldRef:
                fieldPath: metadata.labels['tags.datadoghq.com/env']
          - name: DD_SERVICE
            valueFrom:
              fieldRef:
                fieldPath: metadata.labels['tags.datadoghq.com/service']
          - name: DD_VERSION 
            valueFrom: 
              fieldRef: 
                fieldPath: metadata.labels['tags.datadoghq.com/version']

OpenTelemetry のリソース属性の環境変数を使用することにより、envservice、および version のタグを設定することもできます。

  containers:
  -  ...
     env:
         - name: OTEL_RESOURCE_ATTRIBUTES
           value: "service.name=<SERVICE>,service.version=<VERSION>,deployment.environment=<ENV>"
         - name: OTEL_SERVICE_NAME
           value: "<SERVICE>"
OTEL_SERVICE_NAME 環境変数は、 service.name 属性 ( OTEL_RESOURCE_ATTRIBUTES 環境変数) よりも優先されます。
部分的構成
ポッドレベルのメトリクス

ポッドレベルのメトリクスを構成するには、次の標準ラベル (tags.datadoghq.com) を Deployment、StatefulSet、または Job のポッド仕様に追加します。

template:
  metadata:
    labels:
      tags.datadoghq.com/env: "<ENV>"
      tags.datadoghq.com/service: "<SERVICE>"
      tags.datadoghq.com/version: "<VERSION>" 

これらのラベルは、ポッドレベルの Kubernetes CPU、メモリ、ネットワーク、ディスクメトリクスをカバーし、Kubernetes の Downward API を介してサービスのコンテナに DD_ENVDD_SERVICEDD_VERSION を取り込むために使用できます。

ポッドごとに複数のコンテナがある場合は、コンテナごとに標準ラベルを指定できます。

tags.datadoghq.com/<container-name>.env
tags.datadoghq.com/<container-name>.service
tags.datadoghq.com/<container-name>.version 
ステートメトリクス

Kubernetes ステートメトリクスを構成するには:

  1. 構成ファイルの中で join_standard_tagstrue に設定します。設定場所については、この 例の構成ファイル を参照してください。

  2. 同じ標準ラベルを親リソース (Deployment など) のラベルのコレクションに追加します。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    tags.datadoghq.com/env: "<ENV>"
    tags.datadoghq.com/service: "<SERVICE>"
    tags.datadoghq.com/version: "<VERSION>" 
spec:
  template:
    metadata:
      labels:
        tags.datadoghq.com/env: "<ENV>"
        tags.datadoghq.com/service: "<SERVICE>"
        tags.datadoghq.com/version: "<VERSION>" 
Datadog SDK と StatsD クライアント

Datadog SDKおよび StatsD クライアントの環境変数を構成するには、Kubernetes の Downward API を以下の形式で使用します。

containers:
-  ...
    env:
        - name: DD_ENV
          valueFrom:
            fieldRef:
              fieldPath: metadata.labels['tags.datadoghq.com/env']
        - name: DD_SERVICE
          valueFrom:
            fieldRef:
              fieldPath: metadata.labels['tags.datadoghq.com/service']
        - name: DD_VERSION 
          valueFrom: 
            fieldRef: 
              fieldPath: metadata.labels['tags.datadoghq.com/version'] 
コンテナ化された環境での APM データに対する自動バージョンタグ付け
この機能は、Application Performance Monitoring (APM) データに対してのみ有効です。

APM で version タグを使用してデプロイを監視したり、自動障害デプロイ検出を通じて不良なコードデプロイを特定したりできます。

APM データの場合、Datadog は次の優先順位で version タグを設定します。手動で version を設定した場合、Datadog がその version 値をオーバーライドすることはありません。

優先順位バージョン値
1{バージョン値}
2{image_tag}_{first_7_digits_of_git_commit_sha}
3{image_tag} または {first_7_digits_of_git_commit_sha} (どちらか一方のみ利用可能な場合)

要件:

  • Datadog Agent バージョン 7.52.0 以上
  • サービスがコンテナ化された環境で動作しており、新しいバージョンのデプロイを追跡するには image_tag で十分な場合、これ以上の構成は不要です
  • サービスがコンテナ化された環境で実行されていない場合、または Git SHA を含めたい場合は、ビルド成果物に Git 情報を埋め込んでください
完全な構成

コンテナの ``DD_ENVDD_SERVICEDD_VERSION` 環境変数、および対応する Docker ラベルを設定することにより、統合サービスタグ付けの全範囲を取得します。

Dockerfile には、serviceversion の値を指定できます。

ENV DD_SERVICE <SERVICE>
ENV DD_VERSION <VERSION> 

LABEL com.datadoghq.tags.service="<SERVICE>"
LABEL com.datadoghq.tags.version="<VERSION>" 

env はデプロイ時に決定される可能性が高いため、後で環境変数を注入してラベルを付けることができます。

docker run -e DD_ENV=<ENV> -l com.datadoghq.tags.env=<ENV> ...

デプロイ時にすべてを設定することもできます。

docker run -e DD_ENV="<ENV>" \
           -e DD_SERVICE="<SERVICE>" \
           -e DD_VERSION="<VERSION>" \ 
           -l com.datadoghq.tags.env="<ENV>" \
           -l com.datadoghq.tags.service="<SERVICE>" \
           -l com.datadoghq.tags.version="<VERSION>" \ 
           ...
部分的構成

サービスが Datadog 環境変数を必要としない場合 (例えば、Redis、PostgreSQL、NGINX などのサードパーティソフトウェアや、APM によってトレースされないアプリケーション)、Docker ラベルを使用できます。

com.datadoghq.tags.env
com.datadoghq.tags.service
com.datadoghq.tags.version 

完全な構成で説明したように、これらのラベルは Dockerfile で設定するか、コンテナを起動するための引数として設定できます。

コンテナ化された環境での APM データに対する自動バージョンタグ付け
この機能は、Application Performance Monitoring (APM) データに対してのみ有効です。

APM で version タグを使用してデプロイを監視したり、自動障害デプロイ検出を通じて不良なコードデプロイを特定したりできます。

APM データの場合、Datadog は次の優先順位で version タグを設定します。手動で version を設定した場合、Datadog がその version 値をオーバーライドすることはありません。

優先順位バージョン値
1{バージョン値}
2{image_tag}_{first_7_digits_of_git_commit_sha}
3{image_tag} または {first_7_digits_of_git_commit_sha} (どちらか一方のみ利用可能な場合)

要件:

  • Datadog Agent バージョン 7.52.0 以上
  • サービスがコンテナ化された環境で動作しており、新しいバージョンのデプロイを追跡するには image_tag で十分な場合、これ以上の構成は不要です
  • サービスがコンテナ化された環境で実行されていない場合、または Git SHA を含めたい場合は、ビルド成果物に Git 情報を埋め込んでください
ECS Fargate 上で Fluent Bit や FireLens を使用する場合、統合サービスタグ付けはメトリクスとトレースに対してのみ利用可能で、ログ収集には対応していません。
完全な構成

各サービスのコンテナのランタイム環境で、DD_ENVDD_SERVICEDD_VERSION (自動バージョンタグ付けでオプション) 環境変数と対応する Docker ラベルを設定して、統合サービスタグ付けの全範囲を取得します。たとえば、ECS タスク定義を通じて、この構成をすべて 1 か所で設定できます。

"environment": [
  {
    "name": "DD_ENV",
    "value": "<ENV>"
  },
  {
    "name": "DD_SERVICE",
    "value": "<SERVICE>"
  },
  {
    "name": "DD_VERSION",
    "value": "<VERSION>"
  }
   
],
"dockerLabels": {
  "com.datadoghq.tags.env": "<ENV>",
  "com.datadoghq.tags.service": "<SERVICE>",
  "com.datadoghq.tags.version": "<VERSION>"
}
ECS Fargateでは、これらのタグを Datadog Agent コンテナではなく、アプリケーションコンテナに追加する必要があります。
部分的構成

サービスが Datadog 環境変数を必要としない場合 (たとえば、Redis、PostgreSQL、NGINX などのサードパーティソフトウェアや、APM によってトレースされないアプリケーション)、ECS タスク定義で Docker ラベルを使用できます。

"dockerLabels": {
  "com.datadoghq.tags.env": "<ENV>",
  "com.datadoghq.tags.service": "<SERVICE>",
  "com.datadoghq.tags.version": "<VERSION>"
}
コンテナ化された環境での APM データに対する自動バージョンタグ付け
この機能は、Application Performance Monitoring (APM) データに対してのみ有効です。

APM で version タグを使用してデプロイを監視したり、自動障害デプロイ検出を通じて不良なコードデプロイを特定したりできます。

APM データの場合、Datadog は次の優先順位で version タグを設定します。手動で version を設定した場合、Datadog がその version 値をオーバーライドすることはありません。

優先順位バージョン値
1{バージョン値}
2{image_tag}_{first_7_digits_of_git_commit_sha}
3{image_tag} または {first_7_digits_of_git_commit_sha} (どちらか一方のみ利用可能な場合)

要件:

  • Datadog Agent バージョン 7.52.0 以上
  • サービスがコンテナ化された環境で動作しており、新しいバージョンのデプロイを追跡するには image_tag で十分な場合、これ以上の構成は不要です
  • サービスがコンテナ化された環境で実行されていない場合、または Git SHA を含めたい場合は、ビルド成果物に Git 情報を埋め込んでください

非コンテナ化環境

サービスのバイナリまたは実行可能ファイルを構築したりデプロイしたりする方法に応じて、環境変数を設定するためのオプションを利用できる場合があります。ホストごとに 1 つ以上のサービスを実行する可能性があるため、Datadog では、これらの環境変数の範囲を単一プロセスに限定することが推奨されています。

トレースログRUMリソースSynthetic テストStatsD メトリクス、またはシステムメトリクスのサービスのランタイムから直接送信されるすべてのテレメトリーの構成の単一ポイントを形成するには、次のいずれかを実行します。

  1. 実行可能ファイルのコマンドで環境変数をエクスポートします。

    DD_ENV=<env> DD_SERVICE=<service> DD_VERSION=<version> /bin/my-service
    
  2. または、ChefAnsible、または別のオーケストレーションツールを使用して、サービスの systemd または initd コンフィギュレーションファイルに DD 環境変数を設定します。サービスプロセスが開始すると、その変数にアクセスできるようになります。

    統合サービスタグ付けのトレースを構成する場合

    1. DD_ENVDatadog SDKを構成することにより、env の定義が、トレースを生成しているアプリケーションに近くなるようにしてください。この方法では、env タグがスパンメタデータのタグから自動的に取得されるようになります。

    2. DD_VERSION でスパンを構成することにより、SDK に属するサービスに該当するすべてのスパンにバージョンを追加します (一般的に DD_SERVICE)。したがって、サービスにより外部サービスの名前でスパンが作成された場合、それらのスパンには version がタグとして追加されません。

      バージョンがスパンに存在する限り、それらのスパンから生成されるトレースメトリクスにはそれが追加されます。バージョンは、コード内で手動で追加できます。または、Datadog SDK によって自動的に追加されます。構成されているなら、それらは、トレースデータと StatsD メトリクスに envservice、および version のタグを付けるために、APM および DogStatsDクライアントによって使用されます。有効にされている場合、Datadog SDK はこれらの変数の値をログに取り込みます。

      : スパンごとに 1 つのサービスのみ可能です。また、一般にトレースメトリクスでもサービスは単一サービスです。ただし、ホストのタグで異なるサービスが定義されている場合、その構成されたサービスタグは、そのホストから発行されたすべてのトレースメトリクスに表示されます。

    接続されているログとトレースを使用している場合、Datadog SDK が自動ログ取り込みをサポートしているなら、それを有効にしてください。その場合、Datadog SDK はenvservice、および version をログに自動的に取り込むため、他の場所でこれらのフィールドを手動で構成する必要はありません。

    接続された RUM とトレースを使用する場合、初期化ファイルの service フィールドにブラウザアプリケーションを指定し、env フィールドに環境を定義し、version フィールドにバージョンを記載します。

    RUM アプリケーションを作成する際に、envservice の名前を確認します。

    接続された Synthetic ブラウザのテストとトレースをご利用の場合、Integration Settings ページAPM Integration for Browser Tests のセクションでヘッダー送信先 URL を指定してください。

    ワイルドカードとして * を使用することができます (例: https://*.datadoghq.com)。

    カスタム StatsD メトリクスには、付加のみという形でタグが追加されます。たとえば、env に異なる 2 つの値がある場合、メトリクスには両方の環境がタグ付けされます。同じ名前のタグが他のタグをオーバーライドする順序はありません。

    サービスが DD_ENVDD_SERVICEDD_VERSION にアクセスできる場合、DogStatsD クライアントは対応するタグをカスタムメトリクスに自動的に追加します。

    : .NET および PHP 用の Datadog DogStatsD クライアントは、この機能をサポートしていません。

    インフラストラクチャーメトリクスに envservice のタグを追加できます。コンテナ化されていない環境の場合、サービスメトリクスのタグ付けは Agent レベルで構成されます。

    この構成はサービスのプロセスを呼び出すたびに変更されるわけではないので、version を追加することは推奨されません。

    ホスト毎の単一サービス

    Agent のメインコンフィギュレーションファイルに、以下の構成を適用します。

    env: <ENV>
    tags:
      - service:<SERVICE>
    

    この設定により、Agent が送信するすべてのデータに対して envservice のタグ付けの一貫性が保証されます。

    ホスト毎の複数のサービス

    Agent のメインコンフィギュレーションファイルに、以下の構成を適用します。

    env: <ENV>
    

    CPU、メモリ、ディスク I/O のメトリクスに一意の service タグをプロセスレベルで取得するには、Agent の構成フォルダ (process.d/conf.yaml の下の conf.d フォルダなど) でプロセスチェックを構成します。

    init_config:
    instances:
        - name: web-app
          search_string: ["/bin/web-app"]
          exact_match: false
          service: web-app
        - name: nginx
          search_string: ["nginx"]
          exact_match: false
          service: nginx-web-app
    

    : Agent のメイン構成ファイルでグローバルに service タグが設定されている場合、プロセスメトリクスには 2 つのサービスがタグ付けされます。これによりメトリクスの解釈に混乱を招く可能性があるため、service タグはプロセスチェックの構成でのみ設定することをお勧めします。

サーバーレス環境

AWS Lambda 関数については、タグを使った Lambda のテレメトリー接続方法を参照してください。

OpenTelemetry

OpenTelemetry を使用する場合、以下のリソース属性 を、対応する Datadog 規則にマッピングします。

OpenTelemetry 規約Datadog 規約
deployment.environment 1env
deployment.environment.name 2env
service.nameservice
service.versionversion

1: deployment.environmentOpenTelemetry セマンティック規約 v1.27.0 で非推奨となっており、代わりに deployment.environment.name を使うことが推奨されています。 2: deployment.environment.name は Datadog Agent 7.58.0 以上および Datadog Exporter v0.110.0 以上でサポートされています。

Datadog 固有の環境変数 ( DD_SERVICEDD_ENVDD_VERSION など) は、OpenTelemetry の構成においてデフォルトではサポートされていません。

環境変数を使用してリソース属性を設定するには、OTEL_RESOURCE_ATTRIBUTES に適切な値を設定します。

export OTEL_RESOURCE_ATTRIBUTES="service.name=my-service,deployment.environment=production,service.version=1.2.3"

アプリケーションコードでリソース属性を設定するには、必要な属性を指定して Resource を作成し、TracerProvider に関連付けます。

Python を使った例を次に示します。

from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider

resource = Resource(attributes={
   "service.name": "<SERVICE>",
   "deployment.environment": "<ENV>",
   "service.version": "<VERSION>"
})
tracer_provider = TracerProvider(resource=resource)

OpenTelemetry Collector からリソース属性を設定するには、Collector の設定ファイルで変換プロセッサー (transform processor)を使用します。変換プロセッサーを使用すると、収集したテレメトリデータの属性を Datadog エクスポーターに送信する前に、属性に変更を加えることができます。

processors:
  transform:
    trace_statements:
      - context: resource
        statements:
          - set(attributes["service.name"], "my-service")
          - set(attributes["deployment.environment"], "production")
          - set(attributes["service.version"], "1.2.3")
...

参考資料