ライブラリのローカル挿入

Admission Controller のアプローチでは、Agent は Kubernetes Admission Controller を使用して Kubernetes API へのリクエストをインターセプトし、指定されたインスツルメンテーションライブラリを挿入するために新しいポッドを変異させます。

Kubernetes Admission Controller の詳細については、Kubernetes Admission Controllers リファレンスをご覧ください。

要件

• Kubernetes v1.14+
• Java、Python、NodeJS については Datadog Cluster Agent v7.40+、.NET、Ruby については Datadog Cluster Agent v7.44+。
• Datadog Admission Controller が有効になっている。注: Helm chart v2.35.0 以降では、Cluster Agent で Datadog Admission Controller がデフォルトでアクティブになります。
• Python の場合、現時点では uWSGI アプリケーションはサポートされていません。
• Ruby の場合、ライブラリ挿入のサポートはベータ版です。インスツルメンテーションは、現時点では Ruby on Rails または Hanami アプリケーションに対してのみサポートされています。
• サポートされているアーキテクチャを持つ Linux 上にデプロイされた Java、JavaScript、Python、.NET、または Ruby のアプリケーション。言語ごとにサポートされているアーキテクチャの完全なリストについては、対応するコンテナレジストリを確認してください。

コンテナレジストリ

Datadog は、インスツルメンテーションライブラリのイメージを gcr.io、Docker Hub、AWS ECR で公開しています。

Datadog Cluster Agent の構成にある DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_CONTAINER_REGISTRY 環境変数は、Admission Controller が使用するレジストリを指定します。デフォルト値は、gcr.io/datadoghq です。

ローカルコンテナレジストリでイメージをホストしている場合は、docker.io/datadog、public.ecr.aws/datadog、または他の URL に変更することで、別のレジストリからトレーシングライブラリを引き出すことができます。

インスツルメンテーションライブラリの挿入の構成

Datadog にトレースを送信したい Kubernetes アプリケーションに対して、Java、JavaScript、Python、.NET または Ruby のインスツルメンテーションライブラリを自動的に挿入するように Datadog Admission Controller を構成します。大まかに言うと、これには次の手順が含まれます。詳細は以下で説明します。

1. Datadog Admission Controller を有効にして、ポッドを変異させます。
2. ポッドにアノテーションを付けて、どのインスツルメンテーションライブラリを挿入するか選択します。
3. 統合サービスタグ付けにより、ポッドにタグを付け、Datadog のテレメトリーを結び付け、一貫したタグでトレース、メトリクス、ログをシームレスにナビゲートします。
4. 新しい構成を適用します。

ステップ 1 - Datadog Admission Controller を有効にして、ポッドを変異させます

デフォルトでは、Datadog Admission Controller は、特定のラベルでラベル付けされたポッドのみを変異させます。ポッドの変異を有効にするには、ポッドのスペックにラベル admission.datadoghq.com/enabled: "true" を追加します。

注: Datadog Admission Controller で、Cluster Agent で clusterAgent.admissionController.mutateUnlabelled (または DD_ADMISSION_CONTROLLER_MUTATE_UNLABELLED) を true に設定すると、このポッドラベルがなくても挿入設定を有効にすることが可能です。

構成方法の詳細については、Datadog Admission Controller のページをご覧ください。

例:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    ...
...
template:
  metadata:
    labels:
        admission.datadoghq.com/enabled: "true" # Admission Controller を有効にしてこのデプロイメントに含まれる新しいポッドを変異させます
  containers:
  -  ...

ステップ 2 - ライブラリ挿入のためにポッドにアノテーションを付ける

ライブラリ挿入用のポッドを選択するには、ポッドの仕様で、アプリケーション言語に対応する以下のアノテーションを付けます。

利用可能なライブラリのバージョンは、各コンテナレジストリ、および各言語のトレーサーソースレジストリに記載されています。

• Java
• Javascript
• Python
• .NET
  • 注: .NET ライブラリ挿入の場合、アプリケーションコンテナが musl ベースの Linux ディストリビューション (Alpine など) を使用している場合は、ポッドアノテーションに -musl というサフィックスを持つタグを指定する必要があります。例えば、ライブラリバージョン v2.29.0 を使用する場合は、コンテナタグ v2.29.0-musl を指定します。
• Ruby

注: ライブラリのバージョン X を使用してインストルメンテーションを行ったアプリケーションで、ライブラリ挿入を使用して同じトレーサーライブラリのバージョン Y を使用してインストルメンテーションを行う場合、トレーサーは中断されません。むしろ、最初にロードされたライブラリのバージョンが使用されます。ライブラリ挿入は実行前にアドミッションコントローラレベルで行われるため、手動で構成されたライブラリよりも優先されます。

例えば、Java ライブラリを挿入するには

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    ...
...
template:
  metadata:
    labels:
        admission.datadoghq.com/enabled: "true" # Admission Controller を有効にしてこのデプロイメントに含まれる新しいポッドを変異させます
    annotations:
        admission.datadoghq.com/java-lib.version: "<CONTAINER IMAGE TAG>"
  containers:
  -  ...

ステップ 3 - 統合サービスタグ付けによるポッドへのタグ付け

統合サービスタグ付けを使用すると、Datadog のテレメトリーを結びつけ、一貫したタグでトレース、メトリクス、ログをシームレスにナビゲートすることができます。デプロイメントオブジェクトとポッドテンプレートの両方の仕様に、統合サービスタグ付けを設定します。 以下のラベルを使用して、統合サービスタグを設定します。

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

注: ユニバーサルサービスタグ付けに必要な環境変数 (DD_ENV、DD_SERVICE、DD_VERSION) をポッドテンプレートの仕様で設定する必要はありません。これは、Admission Controller がライブラリにタグ値を挿入する際に環境変数として伝搬させるためです。

例:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    tags.datadoghq.com/env: "prod" # 統合サービスタグ - デプロイメント環境タグ
    tags.datadoghq.com/service: "my-service" # 統合サービスタグ - デプロイメントサービスタグ
    tags.datadoghq.com/version: "1.1" # 統合サービスタグ - デプロイメントバージョンタグ
...
template:
  metadata:
    labels:
        tags.datadoghq.com/env: "prod" # 統合サービスタグ - ポッド環境タグ
        tags.datadoghq.com/service: "my-service" # 統合サービスタグ - ポッドサービスタグ
        tags.datadoghq.com/version: "1.1" # 統合サービスタグ - ポッドバージョンタグ
        admission.datadoghq.com/enabled: "true" # Admission Controller を有効にしてこのデプロイメントに含まれる新しいポッドを変異させます
    annotations:
        admission.datadoghq.com/java-lib.version: "<CONTAINER IMAGE TAG>"
  containers:
  -  ...

ステップ 4 - 構成を適用する

新しい構成が適用されると、ポッドはインスツルメンテーションを受ける準備が整います。

ライブラリ挿入が成功したことを確認する

ライブラリ挿入は、ポッド内の専用 init コンテナの挿入を利用します。 挿入が成功すると、ポッド内に datadog-lib-init という init コンテナが作成されるのが確認できます。

または、kubectl describe pod <my-pod> を実行すると、datadog-lib-init init コンテナがリストアップされます。

インスツルメンテーションは、Datadog へのテレメトリーの送信も開始します (例えば、APM へのトレースなど)。

インストールに関する問題のトラブルシューティング

アプリケーションポッドの起動に失敗した場合、kubectl logs <my-pod> --all-containers を実行してログを出力し、以下の既知の問題と比較してください。

.NET のインストールに関する問題

dotnet: error while loading shared libraries: libc.musl-x86_64.so.1: cannot open shared object file: No such file or directory

• 問題: dotnet ライブラリバージョンのポッドアノテーションには -musl サフィックスが含まれていたが、アプリケーションコンテナは glibc を使用する Linux ディストリビューションで実行されている。
• 解決策: dotnet ライブラリのバージョンから -musl サフィックスを削除してください。

Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /datadog-lib/continuousprofiler/Datadog.Linux.ApiWrapper.x64.so)

• 問題: アプリケーションコンテナは musl-libc を使用する Linux ディストリビューション (例えば Alpine) で動作するが、ポッドアノテーションに -musl というサフィックスが含まれていない。
• 解決策: dotnet ライブラリのバージョンに -musl サフィックスを追加してください。

Agent とお客様のサービスの両方が、現実または仮想のホスト上で実行されている場合、Datadog は execve の呼び出しをオーバーライドするプリロードライブラリを使用することで、トレーシングライブラリを挿入します。新しく開始されたプロセスは全て傍受され、指定されたインスツルメンテーションライブラリがサービスに挿入されます。

要件

• 最近の Datadog Agent v7 のインストール

注: arm64 での挿入、Alpine Linux のコンテナイメージでの musl による挿入はサポートされていません。

プリロードライブラリのインストール

1. Agent が実行していることを確認します。

2. 次のコマンド セットのいずれかを使用してライブラリをインストールします。ここで、<LANG> は java、js、dotnet、python または all のいずれかです。

   Ubuntu、Debian、またはその他の Debian ベースの Linux ディストリビューションの場合:

   sudo apt-get update
   sudo apt-get install datadog-apm-inject datadog-apm-library-<LANG>
   

   CentOS、RedHat、または yum/RPM を使用するその他のディストリビューションの場合:

   sudo yum makecache
   sudo yum install datadog-apm-inject datadog-apm-library-<LANG>
   

3. コマンド dd-host-install を実行します。

4. 終了して新しいシェルを開き、プリロードライブラリを使用します。

言語とアプリをインストールする

1. Java アプリケーションの場合、JDK または JRE がインストールされていることを確認します。

   sudo apt install openjdk-17-jdk -y
   

   NodeJS アプリケーションの場合、NodeJS がインストールされていることを確認します。

   curl -sL https://deb.nodesource.com/setup_16.x | sudo -E bash -
   sudo apt install nodejs -y
   

   .NET アプリケーションの場合、.NET ランタイムがインストールされていることを確認します。

   Python アプリケーションの場合、Python がインストールされていることを確認します。

   sudo apt install python -y
   

2. まだの場合は、アプリをインストールします。

挿入の構成

以下の環境変数がライブラリの挿入を構成します。これらはコマンドラインから export (export DD_CONFIG_SOURCES=BASIC) やシェルの構成、あるいは起動コマンドで渡すことができます。

DD_CONFIG_SOURCES

ライブラリ挿入のオン・オフを切り替え、構成を読み込む場所を指定します。オプションで、複数の値をセミコロンで区切って、複数の可能な場所を示します。エラーにならずに戻ってきた最初の値が使用されます。構成は、構成ソースにまたがってマージされることはありません。有効な値は次のとおりです。

• BLOB:<URL> - <URL> にある Blob ストア (S3 互換) から構成を読み込みます。
• LOCAL:<PATH> - ローカルファイルシステム上の <PATH> にあるファイルから読み込みます。
• BASIC - エクスポートされた値またはデフォルト値を使用します。
• OFF - デフォルト。挿入を行いません。
  BLOB または LOCAL の設定について詳しくは、構成ソースの供給を参照してください。

DD_LIBRARY_INJECT

FALSE に設定すると、ライブラリ挿入を完全にオフにすることができます。
デフォルト: TRUE

DD_INJECT_DEBUG

デバッグ情報をログに記録する場合は TRUE または 1 に設定します。
デフォルト: FALSE

DD_OUTPUT_PATHS

デバッグログを書き込む場所をカンマで区切ったリスト。
デフォルト: stderr

構成ソースの供給

BLOB または LOCAL を構成ソースに指定した場合は、etc/<APP_NAME>/config.json または .yaml に JSON または YAML ファイルを作成し、JSON として:

{
    "version": 1,
    "service_language": "<LANG>",
    "tracing_enabled": true,
    "log_injection_enabled": true,
    "health_metrics_enabled": true,
    "runtime_metrics_enabled": true,
    "tracing_sampling_rate": 1.0,
    "tracing_rate_limit": 1,
    "tracing_tags": ["a=b", "foo"],
    "tracing_service_mapping": [
        { "from_key": "mysql", "to_name": "super_db"},
        { "from_key": "postgres", "to_name": "my_pg"}
    ],
    "tracing_agent_timeout": 1,
    "tracing_header_tags": [
        {"header": "HEADER", "tag_name":"tag"}
    ],
    "tracing_partial_flush_min_spans": 1,
    "tracing_debug": true,
    "tracing_log_level": "debug",
}

または YAML として構成を提供します:

---
version: 1
service_language: <LANG>
tracing_enabled: true
log_injection_enabled: true
health_metrics_enabled: true
runtime_metrics_enabled: true
tracing_sampling_rate: 1.0
tracing_rate_limit: 1
tracing_tags:
- a=b
- foo
tracing_service_mapping:
- from_key: mysql
  to_name: super_db
- from_key: postgres
  to_name: my_pg
tracing_agent_timeout: 1
tracing_header_tags:
- header: HEADER
  tag_name: tag
tracing_partial_flush_min_spans: 1
tracing_debug: true
tracing_log_level: debug

service_language に以下のいずれかの値を設定します。

• java
• node
• dotnet
• python

このコンフィギュレーションファイルでは、version の値は常に 1 です。これは、コンテンツのバージョンではなく、使用する構成スキーマのバージョンを指しています。

次の表は、挿入構成値が対応するトレーシングライブラリ構成オプションにどのように対応するかを示しています。

挿入構成に記載されていないトレーサーライブラリの構成オプションは、プロパティや環境変数を通して、通常の方法で使用することができます。

基本構成設定

構成ソースに BASIC を指定した場合、以下の YAML 設定と同等となります。

---
version: 1
tracing_enabled: true
log_injection_enabled: true
health_metrics_enabled: true
runtime_metrics_enabled: true
tracing_sampling_rate: 1.0
tracing_rate_limit: 1

サービスの起動

起動コマンドでプリロードライブラリの構成を指定し、サービスを起動します。

Java アプリの例:

DD_CONFIG_SOURCES=BASIC java -jar <SERVICE_1>.jar &
DD_CONFIG_SOURCES=LOCAL:/etc/<SERVICE_2>/config.yaml;BASIC java -jar <SERVICE_2>.jar &

Node アプリの例:

DD_CONFIG_SOURCES=BASIC node index.js &
DD_CONFIG_SOURCES=LOCAL:/etc/<SERVICE_2>/config.yaml;BASIC node index.js &

.NET アプリの例:

DD_CONFIG_SOURCES=BASIC dotnet <SERVICE_1>.dll &
DD_CONFIG_SOURCES=LOCAL:/etc/<SERVICE_2>/config.yaml;BASIC dotnet <SERVICE_2>.dll &

Python アプリの例:

DD_CONFIG_SOURCES=BASIC python <SERVICE_1>.py &
DD_CONFIG_SOURCES=LOCAL:/etc/<SERVICE_2>/config.yaml;BASIC python <SERVICE_2>.py &

アプリケーションを実行すると、テレメトリーデータが生成され、APM のトレースとして見ることができます。

Agent がホスト上で実行しており、サービスがコンテナで実行している場合、Datadog はコンテナ作成を傍受し、Docker コンテナを構成することでトレーシングライブラリを挿入します。

新しく開始されたプロセスはすべて傍受され、指定されたインスツルメンテーションライブラリがサービスに挿入されます。

要件

• 最近の Datadog Agent v7 のインストール
• Docker Engine

注: arm64 での挿入、Alpine Linux のコンテナイメージでの musl による挿入はサポートされていません。

プリロードライブラリのインストール

1. Agent が実行していることを確認します。

2. 次のコマンド セットのいずれかを使用してライブラリをインストールします。ここで、<LANG> は java、js、dotnet、python または all のいずれかです。

   Ubuntu、Debian、またはその他の Debian ベースの Linux ディストリビューションの場合:

   sudo apt-get update
   sudo apt-get install datadog-apm-inject datadog-apm-library-<LANG>
   

   CentOS、RedHat、または yum/RPM を使用するその他のディストリビューションの場合:

   sudo yum makecache
   sudo yum install datadog-apm-inject datadog-apm-library-<LANG>
   

3. コマンド dd-host-container-install を実行します。

Docker 挿入の構成

/etc/datadog-agent/inject/docker_config.yaml を編集し、以下の挿入用の YAML 構成を追加します。

---
config_sources: BASIC
library_inject: true
log_level: debug
output_paths:
- stderr

config_sources

ライブラリ挿入のオン・オフを切り替え、構成が保存される場所をセミコロンで区切った順序付きリストで指定します。エラーにならずに戻ってきた最初の値が使用されます。構成は、構成ソースにまたがってマージされることはありません。有効な値は次のとおりです。

• BLOB:<URL> - <URL> にある Blob ストア (S3 互換) から構成を読み込みます。
• LOCAL:<PATH> - ローカルファイルシステム上の <PATH> にあるファイルから読み込みます。
• BASIC - デフォルトのプロパティセットを使用し、追加の構成の検索を停止します。
• OFF - デフォルト。挿入を行いません。
  BLOB または LOCAL の設定について詳しくは、構成ソースの供給を参照してください。

library_inject

false に設定すると、ライブラリの挿入を完全に無効にすることができます。
デフォルト: true

log_level

何が起こっているかについての詳細な情報をログに記録する場合は debug に、それよりもはるかに少ない情報をログに記録する場合は info に設定します。

output_paths

ログを書き込む 1 つまたは複数の場所のリスト。
デフォルト: stderr

オプション: env

Docker で動作するコンテナ、例えば dev、prod、staging などの DD_ENV タグを指定します。
デフォルト なし。

構成ソースの供給

BLOB または LOCAL を構成ソースに指定した場合は、そこに JSON または YAML ファイルを作成し、JSON として:

{
    "version": 1,
    "service_language": "<LANG>",
    "tracing_enabled": true,
    "log_injection_enabled": true,
    "health_metrics_enabled": true,
    "runtime_metrics_enabled": true,
    "tracing_sampling_rate": 1.0,
    "tracing_rate_limit": 1,
    "tracing_tags": ["a=b", "foo"],
    "tracing_service_mapping": [
        { "from_key": "mysql", "to_name": "super_db"},
        { "from_key": "postgres", "to_name": "my_pg"}
    ],
    "tracing_agent_timeout": 1,
    "tracing_header_tags": [
        {"header": "HEADER", "tag_name":"tag"}
    ],
    "tracing_partial_flush_min_spans": 1,
    "tracing_debug": true,
    "tracing_log_level": "debug",
}

または YAML として構成を提供します:

---
version: 1
service_language: <LANG>
tracing_enabled: true
log_injection_enabled: true
health_metrics_enabled: true
runtime_metrics_enabled: true
tracing_sampling_rate: 1.0
tracing_rate_limit: 1
tracing_tags:
- a=b
- foo
tracing_service_mapping:
- from_key: mysql
  to_name: super_db
- from_key: postgres
  to_name: my_pg
tracing_agent_timeout: 1
tracing_header_tags:
- header: HEADER
  tag_name: tag
tracing_partial_flush_min_spans: 1
tracing_debug: true
tracing_log_level: debug

service_language に以下のいずれかの値を設定します。

• java
• node
• dotnet
• python

このコンフィギュレーションファイルでは、version の値は常に 1 です。これは、コンテンツのバージョンではなく、使用する構成スキーマのバージョンを指しています。

次の表は、挿入構成値が対応するトレーシングライブラリ構成オプションにどのように対応するかを示しています。

挿入構成に記載されていないトレーサーライブラリの構成オプションは、プロパティや環境変数を通して、通常の方法で使用することができます。

基本構成設定

構成ソースに BASIC を指定した場合、以下の YAML 設定と同等となります。

---
version: 1
tracing_enabled: true
log_injection_enabled: true
health_metrics_enabled: true
runtime_metrics_enabled: true
tracing_sampling_rate: 1.0
tracing_rate_limit: 1

コンテナへの統合サービスタグ付けの指定

環境変数 DD_ENV、DD_SERVICE、DD_VERSION がサービスコンテナイメージで指定されている場合、それらの値はコンテナからのテレメトリーにタグ付けするために使用されます。

指定がない場合は、DD_ENV は /etc/datadog-agent/inject/docker_config.yaml コンフィギュレーションファイルに設定されている env 値を使用します (もしある場合)。DD_SERVICE と DD_VERSION は、Docker イメージの名前から取得します。my-service:1.0 という名前のイメージは、DD_SERVICE が my-service で、 DD_VERSION が 1.0 でタグ付けされています。

サービスの起動

Agent を起動し、通常通りコンテナ化されたサービスを起動します。

アプリケーションを実行すると、テレメトリーデータが生成され、APM のトレースとして見ることができます。

Agent とサービスが同じホストの別々の Datadog コンテナで実行している場合、Datadog はコンテナ作成を傍受し、Docker コンテナを構成することでトレーシングライブラリを挿入します。

新しく開始されたプロセスはすべて傍受され、指定されたインスツルメンテーションライブラリがサービスに挿入されます。

要件

• Docker Engine

注: arm64 での挿入、Alpine Linux のコンテナイメージでの musl による挿入はサポートされていません。

プリロードライブラリのインストール

Ubuntu、Debian、またはその他の Debian ベースの Linux ディストリビューションの場合:

1. Datadog の deb リポジトリをシステムにセットアップし、Datadog のアーカイブキーリングを作成します。

   sudo sh -c "echo 'deb [signed-by=/usr/share/keyrings/datadog-archive-keyring.gpg] https://apt.datadoghq.com/ stable 7' > /etc/apt/sources.list.d/datadog.list"
   sudo touch /usr/share/keyrings/datadog-archive-keyring.gpg
   sudo chmod a+r /usr/share/keyrings/datadog-archive-keyring.gpg
   
   curl https://keys.datadoghq.com/DATADOG_APT_KEY_CURRENT.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
   curl https://keys.datadoghq.com/DATADOG_APT_KEY_382E94DE.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
   curl https://keys.datadoghq.com/DATADOG_APT_KEY_F14F620E.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
   

2. ローカルの apt リポジトリを更新し、ライブラリをインストールします。

   sudo apt-get update
   sudo apt-get install datadog-apm-inject datadog-apm-library-<LANG>
   

   ここで <LANG> は java、js、dotnet、python または all のいずれかです。

3. コマンド dd-container-install を実行します。

CentOS、RedHat、または yum/RPM を使用するその他のディストリビューションの場合:

1. 以下の内容で /etc/yum.repos.d/datadog.repo と呼ばれるファイルを作成して、システム上に Datadog の Yum リポジトリをセットアップします。

   [datadog]
   name = Datadog, Inc.
   baseurl = https://yum.datadoghq.com/stable/7/x86_64/
   enabled=1
   gpgcheck=1
   repo_gpgcheck=1
   gpgkey=https://keys.datadoghq.com/DATADOG_RPM_KEY_CURRENT.public https://keys.datadoghq.com/DATADOG_RPM_KEY_FD4BF915.public https://keys.datadoghq.com/DATADOG_RPM_KEY_E09422B3.public
   

   注: dnf のバグにより、RedHat/CentOS 8.1 では 1 の代わりに repo_gpgcheck=0 を設定してください。

2. yum キャッシュを更新して、ライブラリをインストールします。

   sudo yum makecache
   sudo yum install datadog-apm-inject datadog-apm-library-<LANG>
   

   ここで <LANG> は java、js、dotnet、python または all のいずれかです。

3. コマンド dd-container-install を実行します。

Docker 挿入の構成

/etc/datadog-agent/inject/docker_config.yaml を編集し、以下の挿入用の YAML 構成を追加します。

---
library_inject: true
log_level: debug
output_paths:
- stderr
config_sources: BASIC

config_sources

ライブラリ挿入のオン・オフを切り替え、構成が保存される場所をセミコロンで区切った順序付きリストで指定します。エラーにならずに戻ってきた最初の値が使用されます。構成は、構成ソースにまたがってマージされることはありません。有効な値は次のとおりです。

• BLOB:<URL> - <URL> にある Blob ストア (S3 互換) から構成を読み込みます。
• LOCAL:<PATH> - ローカルファイルシステム上の <PATH> にあるファイルから読み込みます。
• BASIC - デフォルトのプロパティセットを使用し、追加の構成の検索を停止します。
• OFF - デフォルト。挿入を行いません。
  BLOB または LOCAL の設定について詳しくは、構成ソースの供給を参照してください。

library_inject

false に設定すると、ライブラリの挿入を完全に無効にすることができます。
デフォルト: true

log_level

何が起こっているかについての詳細な情報をログに記録する場合は debug に、それよりもはるかに少ない情報をログに記録する場合は info に設定します。

output_paths

ログを書き込む 1 つまたは複数の場所のリスト。
デフォルト: stderr

オプション: env

Docker で動作するコンテナ、例えば dev、prod、staging などの DD_ENV タグを指定します。
デフォルト なし。

構成ソースの供給

BLOB または LOCAL を構成ソースに指定した場合は、そこに JSON または YAML ファイルを作成し、JSON として:

{
    "version": 1,
    "service_language": "<LANG>",
    "tracing_enabled": true,
    "log_injection_enabled": true,
    "health_metrics_enabled": true,
    "runtime_metrics_enabled": true,
    "tracing_sampling_rate": 1.0,
    "tracing_rate_limit": 1,
    "tracing_tags": ["a=b", "foo"],
    "tracing_service_mapping": [
        { "from_key": "mysql", "to_name": "super_db"},
        { "from_key": "postgres", "to_name": "my_pg"}
    ],
    "tracing_agent_timeout": 1,
    "tracing_header_tags": [
        {"header": "HEADER", "tag_name":"tag"}
    ],
    "tracing_partial_flush_min_spans": 1,
    "tracing_debug": true,
    "tracing_log_level": "debug",
}

または YAML として構成を提供します:

---
version: 1
service_language: <LANG>
tracing_enabled: true
log_injection_enabled: true
health_metrics_enabled: true
runtime_metrics_enabled: true
tracing_sampling_rate: 1.0
tracing_rate_limit: 1
tracing_tags:
- a=b
- foo
tracing_service_mapping:
- from_key: mysql
  to_name: super_db
- from_key: postgres
  to_name: my_pg
tracing_agent_timeout: 1
tracing_header_tags:
- header: HEADER
  tag_name: tag
tracing_partial_flush_min_spans: 1
tracing_debug: true
tracing_log_level: debug

service_language に以下のいずれかの値を設定します。

• java
• node
• dotnet
• python

このコンフィギュレーションファイルでは、version の値は常に 1 です。これは、コンテンツのバージョンではなく、使用する構成スキーマのバージョンを指しています。

次の表は、挿入構成値が対応するトレーシングライブラリ構成オプションにどのように対応するかを示しています。

挿入構成に記載されていないトレーサーライブラリの構成オプションは、プロパティや環境変数を通して、通常の方法で使用することができます。

基本構成設定

構成ソースに BASIC を指定した場合、以下の YAML 設定と同等となります。

---
version: 1
tracing_enabled: true
log_injection_enabled: true
health_metrics_enabled: true
runtime_metrics_enabled: true
tracing_sampling_rate: 1.0
tracing_rate_limit: 1

Agent の構成

コンテナを起動する Docker コンポーズファイルでは、Agent に以下の設定を使用し、${DD_API_KEY} に自分の Datadog API キーをしっかり設定します。

    container_name: dd-agent
    image: datadog/agent:7
    environment:
      - DD_API_KEY=${DD_API_KEY}
      - DD_APM_ENABLED=true
      - DD_APM_NON_LOCAL_TRAFFIC=true
      - DD_LOG_LEVEL=TRACE
      - DD_DOGSTATSD_NON_LOCAL_TRAFFIC=true
      - DD_AC_EXCLUDE=name:datadog-agent
      - DD_SYSTEM_PROBE_ENABLED=true
      - DD_PROCESS_AGENT_ENABLED=true
      - DD_APM_RECEIVER_SOCKET=/opt/datadog/apm/inject/run/apm.socket
    volumes:
      - /opt/datadog/apm:/opt/datadog/apm
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /proc/:/host/proc/:ro
      - /sys/fs/cgroup/:/host/sys/fs/cgroup:ro
      - /sys/kernel/debug:/sys/kernel/debug
    cap_add:
      - SYS_ADMIN
      - SYS_RESOURCE
      - SYS_PTRACE
      - NET_ADMIN
      - NET_BROADCAST
      - NET_RAW
      - IPC_LOCK
      - CHOWN
    security_opt:
      - apparmor:unconfined

コンテナへの統合サービスタグ付けの指定

環境変数 DD_ENV、DD_SERVICE、DD_VERSION がサービスコンテナイメージで指定されている場合、それらの値はコンテナからのテレメトリーにタグ付けするために使用されます。

指定がない場合は、DD_ENV は /etc/datadog-agent/inject/docker_config.yaml コンフィギュレーションファイルに設定されている env 値を使用します (もしある場合)。DD_SERVICE と DD_VERSION は、Docker イメージの名前から取得します。my-service:1.0 という名前のイメージは、DD_SERVICE が my-service で、 DD_VERSION が 1.0 でタグ付けされています。

Docker 上で Agent を起動する

dd-agent コンテナは、どのサービスコンテナよりも先に起動する必要があります。以下を実行します。

docker-compose up -d dd-agent

サービスの起動

通常通り、コンテナ化されたサービスを起動します。

アプリケーションを実行すると、テレメトリーデータが生成され、APM のトレースとして見ることができます。