統合サービスタグ付けは、3 つの予約済みタグである env、service、version を使用して Datadog テレメトリを結び付けます。
これら 3 つのタグを使用すると、次のことができます。
統合サービスタグ付けには、Datadog Agent のセットアップが必要です。
統合サービスタグ付けには、予約済みタグの新しいコンフィギュレーションに対応するトレーサーのバージョンが必要です。詳細は、言語別のセットアップ手順をご覧ください。
統合サービスタグ付けには、タグの構成に関する知識が必要です。タグの構成方法がわからない場合は、コンフィギュレーションに進む前に、タグの概要およびタグの付け方のドキュメントをお読みください。
統合サービスタグ付けのコンフィギュレーションを開始するには、環境を選択します。
コンテナ化環境では、env、service、version は、Datadog Agent コンフィギュレーションファイルの環境変数または標準ラベルを介して設定されます。Agent は収集されたデータを特定のコンテナに関連付けるため、これらのタグのコンフィギュレーションはコンテナのメタデータ内に置くことができます。
コンテナ化環境で統合サービスタグ付けをセットアップするには
オートディスカバリーを有効にします。これにより、Datadog Agent は特定のコンテナで実行されているサービスを自動的に識別し、そのサービスからデータを収集して、環境変数を env、service、version タグにマッピングできます。
Docker を使用している場合は、Agent がコンテナの Docker ソケットにアクセスできることを確認してください。これにより、Agent は環境変数を検出し、それを標準タグにマッピングできます。
以下に詳述する完全なコンフィギュレーションまたは部分的なコンフィギュレーションのいずれかに基づいて環境を構成します。
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']
ポッドレベルのメトリクスを構成するには、次の標準ラベル (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_ENV、DD_SERVICE、DD_VERSION を挿入するために使用できます。
ポッドごとに複数のコンテナがある場合は、コンテナごとに標準ラベルを指定できます。
tags.datadoghq.com/<container-name>.env
tags.datadoghq.com/<container-name>.service
tags.datadoghq.com/<container-name>.version
Kubernetes ステートメトリクスを構成するには:
コンフィギュレーションファイルで join_standard_tags を true に設定します。
同じ標準ラベルを親リソース (デプロイなど) のラベルのコレクションに追加します。
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>"
APM トレーサーおよび 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']
コンテナの DD_ENV、DD_SERVICE、DD_VERSION 環境変数と対応する Docker ラベルを設定して、統合サービスタグ付けの全範囲を取得します。
service と version の値は Dockerfile で指定できます。
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 で設定するか、コンテナを起動するための引数として設定できます。
コンテナのランタイム環境で、DD_ENV、DD_SERVICE、DD_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>"
}
]
サービスが Datadog 環境変数を必要としない場合 (たとえば、Redis、PostgreSQL、NGINX などのサードパーティソフトウェアや、APM によってトレースされないアプリケーション)、ECS タスク定義で Docker ラベルを使用できます。
"dockerLabels": {
"com.datadoghq.tags.env": "<ENV>",
"com.datadoghq.tags.service": "<SERVICE>",
"com.datadoghq.tags.version": "<VERSION>"
}
サービスのバイナリまたは実行可能ファイルをどのように構築およびデプロイするかによって、環境変数を設定するためのオプションをいくつか利用できる場合があります。ホストごとに 1 つ以上のサービスを実行する可能性があるため、これらの環境変数のスコープを単一プロセスにすることをお勧めします。
トレース、ログ、StatsD メトリクスのサービスのランタイムから直接送信されるすべてのテレメトリーのコンフィギュレーションの単一ポイントを形成するには、次のいずれかを実行します。
実行可能ファイルのコマンドで環境変数をエクスポートします。
DD_ENV=<env> DD_SERVICE=<service> DD_VERSION=<version> /bin/my-service
または、Chef、Ansible、または別のオーケストレーションツールを使用して、サービスの systemd または initd コンフィギュレーションファイルに DD 環境変数を設定します。これにより、サービスプロセスが開始されると、その変数にアクセスできるようになります。
統合サービスタグ付けのトレースを構成する場合
DD_ENV で APM トレーサーを構成し、トレースを生成しているアプリケーションに env の定義を近づけます。このメソッドを使用すると、env タグをスパンメタデータのタグから自動的に取得できます。
DD_VERSION でスパンを構成して、トレーサーに属するサービス (通常は DD_SERVICE) に属するすべてのスパンにバージョンを追加します。これは、サービスが外部サービスの名前でスパンを作成する場合、そのスパンはタグとして version を受信しないことを意味します。
バージョンがスパンに存在する限り、そのスパンから生成されたメトリクスをトレースするために追加されます。バージョンは、手動でコード内に追加するか、APM トレーサーによって自動的に追加できます。構成すると、少なくともこれらは APM および Dogstatsd クライアントによって使用され、トレースデータと StatsD メトリクスに env、service、version でタグ付けします。有効にすると、APM トレーサーはこの変数の値もログに挿入します。
**注: スパンごとに 1 つのサービスしか存在できません。**トレースメトリクスには、通常、単一のサービスもあります。ただし、ホストのタグで異なるサービスが定義されている場合、その構成されたサービスタグは、そのホストから発行されたすべてのトレースメトリクスに表示されます。
接続されたログとトレースを使用している場合、APM トレーサーでサポートされている場合は、自動ログ挿入を有効にします。APM トレーサーは、自動的に env、service、version をログに挿入するため、他の場所でこれらのフィールドを手動で構成する必要がなくなります。
注: PHP Tracer は、ログの統合サービスタグ付けのコンフィギュレーションをサポートしていません。
タグは、カスタム statsd メトリクスの付加のみの方法で追加されます。たとえば、env に 2 つの異なる値がある場合、メトリクスは両方の環境でタグ付けされます。1 つのタグが同じ名前の別のタグをオーバーライドする順序はありません。
サービスが DD_ENV、DD_SERVICE、DD_VERSION にアクセスできる場合、DogStatsD クライアントは対応するタグをカスタムメトリクスに自動的に追加します。
注: .NET および PHP 用の Datadog DogStatsD クライアントは、まだこの機能をサポートしていません。
インフラストラクチャーのメトリクスには env と service も追加することができます。
非コンテナ環境におけるサービスメトリクスのタグ付けコンフィギュレーションは、Agent と密接な関係にあります。
このコンフィギュレーションによってサービスプロセスの各呼び出しが変更されないことを考慮すると、version をコンフィギュレーションに追加することは推奨されません。
Agent のメインコンフィギュレーションファイルに、以下のコンフィギュレーションを適用します。
env: <ENV>
tags:
- service:<SERVICE>
この設定により、Agent が送信するすべてのデータに対する env と service のタグ付けの一貫性が保証されます。
Agent のメインコンフィギュレーションファイルに、以下のコンフィギュレーションを適用します。
env: <ENV>
プロセスチェックを構成して、CPU、メモリー、ディスクの処理レベルの入出力メトリクスで一意の service タグを取得することができます。
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 タグはプロセスチェックのコンフィギュレーションのみで構成することをお勧めします。
このページ
