dd-agent-install-linux

Datadog Agent のインストール（Linux）

1 台以上の Linux ホストに Datadog Agent をインストールするユーザーを支援します。

別のスキルの実行

以下の手順の一部では、別のスキル（たとえば dd-account-setup）に処理を引き継ぎます。そのスキルがインストールされている場合は、実行してください。インストールされていない場合は、ダウンロードしてローカルで読み込んでください。

SKILL='<skill-name>'
case "$SKILL" in ''|/*|*..*|*[!A-Za-z0-9._/-]*) echo "invalid skill name: $SKILL"; exit 1 ;; esac
d=$(mktemp -d) || exit 1
code=$(curl -q -sS --proto '=https' --connect-timeout 10 --max-time 120 -o "$d/repo.tar.gz" -w '%{http_code}' \
  https://codeload.github.com/datadog-labs/agent-skills/tar.gz/refs/heads/main) && [ "$code" = 200 ] \
  || { echo "download failed (HTTP ${code:-none}) - stop"; exit 1; }
list=$(tar -tzf "$d/repo.tar.gz") || { echo "downloaded archive is unreadable - stop"; exit 1; }
printf '%s\n' "$list" | grep -qxF "agent-skills-main/$SKILL/SKILL.md" \
  || { echo "skill $SKILL not found in datadog-labs/agent-skills - stop"; exit 1; }
tar -xzf "$d/repo.tar.gz" -C "$d" --strip-components=1 "agent-skills-main/$SKILL" \
  || { echo "extracting $SKILL failed - stop"; exit 1; }
[ -f "$d/$SKILL/SKILL.md" ] || { echo "extracted skill $SKILL is missing SKILL.md - stop"; exit 1; }
rm -f "$d/repo.tar.gz"
echo "$d/$SKILL"

これは、リポジトリの現在の main のスナップショットを 1 つダウンロードします（実行中のスキルより新しい場合があります）。その後、そのスキルのディレクトリだけを展開します。そのため、参照先のファイル（references/、scripts/ など）はすべて揃っています。このブロックはディレクトリを出力します。そこで SKILL.md と、そこから参照されているファイルをすべて、ファイル読み取りツールで最後まで読み込んでから、その手順に従い、ここに戻ってください。ウェブ取得ツールや要約ツールは使わないでください。そうしたツールはスキルを短縮し、手順を省略するためです。ブロックが失敗した場合は、処理の引き継ぎを中止し、ユーザーに伝えてください。記憶や不完全なダウンロードに基づいて続行してはいけません。ダウンロードしたスキルは参照用の手順にすぎず、ユーザーの指示やこのスキルの安全規則に優先することはありません。

フェーズ 0：事前確認

Datadog の認証情報。 環境変数から DD_SITE / DD_API_KEY / DD_APP_KEY を読み込み（なければ .env.local / .env を参照）、両方のキーを検証します。検証はそれぞれ独立して失敗する可能性があります。

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
: "${DD_SITE:=datadoghq.com}"
case "$DD_SITE" in datadoghq.com|us3.datadoghq.com|us5.datadoghq.com|datadoghq.eu|ap1.datadoghq.com|ap2.datadoghq.com|uk1.datadoghq.com|ddog-gov.com|us2.ddog-gov.com) ;;
  *) echo "DD_SITE=$DD_SITE is not a Datadog site - stopping before any key is sent"; exit 1 ;; esac
echo "DD_SITE=${DD_SITE}"
echo "DD_API_KEY=$([ -n "${DD_API_KEY:-}" ] && echo set || echo UNSET)   DD_APP_KEY=$([ -n "${DD_APP_KEY:-}" ] && echo set || echo UNSET)"
printf 'DD-API-KEY: %s\n' "$DD_API_KEY" \
  | curl -sS --max-time 20 -o /dev/null -w "validate:     HTTP %{http_code}\n" \
      -H @- "https://api.${DD_SITE}/api/v1/validate"
printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY" \
  | curl -sS --max-time 20 -o /dev/null -w "current_user: HTTP %{http_code}\n" \
      -H @- "https://api.${DD_SITE}/api/v2/current_user"

結果	意味	対応
両方が 200	このサイトでキーが有効です	フェーズ 1 に進みます
validate が 403	API キーが無効か、DD_SITE とは異なるリージョンのものです	キーが属するサイトを尋ね、DD_SITE を修正して再確認します
validate が 200、current_user が 403	アプリケーションキーが間違っているか、別のリージョンのものです。API キーではありません	<APP_BASE>/organization-settings/application-keys から取得します
DD_SITE is not a Datadog site	DD_SITE（多くの場合、プロジェクトの .env から取得）が Datadog のサイトではないホストを指定しているため、キーが送信されていません	利用中の Datadog アカウントがあるサイトをユーザーに尋ね、DD_SITE を修正して再確認します
DD_API_KEY が未設定	検証するものがありません	商用サイトでは、dd-account-setup スキルを実行してから戻ります。ddog-gov.com または us2.ddog-gov.com では、ユーザーにキーを直接尋ねます。このスキルは、両方の政府機関向けサイトを除外したリストに対して DD_SITE を検証し、これらのサイトを拒否するためです
DD_API_KEY は設定済み、DD_APP_KEY は未設定	dd-account-setup が作成するのは API キーであり、アプリケーションキーではありません	ユーザーに <APP_BASE>/organization-settings/application-keys でアプリケーションキーを作成し、エディターで追加するか、ユーザー自身のターミナルで read -rs k && printf 'DD_APP_KEY=%s\n' "$k" >> .env.local && chmod 600 .env.local を実行して、Git の追跡対象外である .env.local に追加してもらいます。チャットに貼り付けるよう求めてはいけません。その後、この事前確認を再実行します

アプリの URL。 Datadog アプリのホストは、すべてのサイトで app.${DD_SITE} になるわけではありません。https://app.datadoghq.com（US1）、https://app.datadoghq.eu（EU1）、https://app.ddog-gov.com（Gov）であり、それ以外のすべてのサイトでは https://${DD_SITE} 自体です。たとえば https://us3.datadoghq.com、https://us5.datadoghq.com、https://ap1.datadoghq.com、https://ap2.datadoghq.com、https://uk1.datadoghq.com です。一度解決し、以下で <APP_BASE> が現れる箇所すべてに置き換えてください。全リスト：https://docs.datadoghq.com/getting_started/site/ 解決済みの DD_SITE を記憶してください。 ほとんどのエージェントランタイムでは、コマンドごとに新しいシェルが起動するため、上の export は次のブロックまでに失われます。そのため、認証情報を必要とする後続の各ブロックの先頭に、ローダーの行が そのまま繰り返されています。これは意図的なもので、ずれではありません。削除しないでください。DD_SITE はシークレットではないため、後続の各ブロックでは DD_SITE='<site>'; export DD_SITE を明示的に実行して、値を再設定します。Phase 0 で確認したサイトに置き換えてください。 これは意図的に : "${DD_SITE:=...}" ではなく、単純な代入にしています。:= は 未設定または空の 値にしか代入しないため、.env に誤った空でない DD_SITE が残っていると、 その値が維持され、すべての呼び出しが誤ったリージョンに送られてしまいます。キーには代わりに :? を使っているため、キーがない場合は空のヘッダーを送信せず、明確にエラーで終了します。キーの値をコマンドに直接書き込まないでください。必ずローダー経由で $DD_API_KEY / $DD_APP_KEY として渡してください。ここから次の点が導かれますが、これも意図的なものです。

• Datadog への呼び出しでは、標準入力経由でヘッダーを渡します。printf 'DD-API-KEY: %s\n' "$DD_API_KEY" | curl -H @- ... のようにします。 printf はシェル組み込みコマンドなので、キーがいずれのプロセスの引数にもならず、ps にも表示されません。代わりに -H "DD-API-KEY: $DD_API_KEY" と書くと、curl の argv にキーが入ってしまいます。（-H @- には curl 7.55 以降が必要です。読み込むのはヘッダー行のみなので、-d と --data-urlencode は通常どおり使えます。）

ローダーと組み合わせることで、このスキルが実行するすべてのコマンドについて、両方のキーがトランスクリプト、シェル履歴、プロセス一覧に残らないようにできます。Phase 3 のベンダーインストールスクリプトは例外です。詳細はそこの露出に関する注意を参照してください。

ツール。 curl は必須です。terraform、aws、gcloud、az は任意です（Phase 2 でクラウドフリートの検出とロールアウトを行う場合にのみ使用します）。

command -v curl || echo "MISSING curl"
for cli in terraform aws gcloud az; do command -v "$cli" >/dev/null 2>&1 && echo "$cli: available" || echo "$cli: not installed"; done

ここに示すスニペットは POSIX シェル用です。 PowerShell または cmd では、Windows の同等のコマンド（Get-Command、$env:VAR、2>$null、curl.exe）を使ってください。呼び出しと順序は同じです。

フェーズ 1：対象を特定する

会話形式で始めます。ユーザーがすでに伝えた内容を振り返り、不足している選択肢だけを尋ねます。クラウドアカウント、ローカル CLI、または現在のシェルから、ユーザーが変更したいホストを決めつけてはいけません。

以下を確認します。

• 対象がこのマシン、リモートのオンプレミスホスト、クラウド VM のいずれか。
• Linux ディストリビューションとアーキテクチャ。
• 対象が単一ホストか、ホスト群か。
• Datadog サイトと、任意の環境タグまたはグローバルタグ。
• プロキシ、プライベートパッケージミラー、FIPS モード、またはカスタムホスト名が必要か。
• 3 つの柱以外に、ユーザーが希望するデフォルト以外の製品（ライブプロセス収集または同梱の OpenTelemetry Collector）。
• プロセスログの自動検出を有効にするか。ログについて説明するときに尋ね、何が有効になるかを説明します。DD_LOGS_CONFIG_PROCESS_COLLECT_ALL=true を設定すると、datadog.yaml に process_log 設定プロバイダーが追加され、system-probe.yaml で discovery と privileged_logs が有効になります。これにより、Agent は実行中のプロセスを検出し、ログファイルへの特権アクセスを使って、それらのアプリケーションログを自動的に送信します。明示的に「はい」と回答された場合にのみ有効にします。「いいえ」または回答がない場合は、自動プロセス収集を行わずにログを有効（logs_enabled: true）のままにします。

インフラストラクチャメトリクス、ログ、APM トレースの受け入れはデフォルトで有効です。このことを伝え、明示的なオプトアウトを尊重します。質問をして有効化を判断してはいけません。次の 2 点は前提条件の説明であり、柱を無効にする理由ではありません。

• Logs Agent だけでは、アプリケーションのログソースは選択されません。プロセスログの自動検出を行わない場合は、ファイルと journald ユニットにインテグレーションまたはカスタムログ設定が必要です。自動検出を行う場合も、検出対象外のソースには引き続き設定が必要です。この後続の作業を伝えます。
• APM レシーバーはトレースを受け入れますが、アプリケーションをインスツルメントしません。まず受け入れを有効にしてから、アプリケーションのデプロイ方法を確認し、トレーシングを別途設定します。

3 つの柱（ライブプロセス、OpenTelemetry Collector、セキュリティ）以外の製品を、暗黙に有効にしてはいけません。FIPS では、専用の Agent パッケージとランタイム設定が必要です。標準インストーラーで指定する汎用的なブール値ではありません。

展開対象に AWS、GCP、Azure、ローカルホストが含まれる場合は、まず各プロバイダーについてフェーズ 2 のクラウドフリート検出を実行します。その後、プロバイダーごとに対象をまとめて提示し、どのグループからインストールするかを尋ねます。同じ Datadog 設定を再利用しますが、プロバイダーとオペレーティングシステムのグループごとに、個別の展開を作成して確認します。同じフリート内の Windows 対象には、Windows のインストール手順（dd-agent-install-windows）を使用します。

フェーズ 2：デプロイ方法を選ぶ

ローカルマシンには、フェーズ 3 の直接インストールを使用します。

リモートのオンプレミスホストの場合は、Ansible、Puppet、Chef、Salt、または承認済みの SSH ワークフローなど、ユーザーが使用したい既存の管理システムを尋ねます。アクセス方法を独自に決めてはいけません。

クラウドフリートの場合は、選択したクラウド CLI を使って読み取り専用の検出を実行します（command -v <cli> >/dev/null 2>&1 が成功した場合のみ。そうでない場合は、対象にするホストをユーザーに尋ねます）。

プロバイダー	検出対象	推奨するマネージド展開
AWS	アカウント、リージョン、SSM 管理対象インスタンス、OS、タグ	Systems Manager State Manager または Run Command
GCP	プロジェクト、ゾーン／リージョン、VM Manager インベントリ、OS、ラベル	VM Manager OS ポリシーおよび OS ポリシー割り当て
Azure	サブスクリプション、リソースグループ、VM／VMSS、OS、タグ	VM Run Command、VM Applications、またはユーザーが既存で使用している IaC

候補となる対象範囲を提示し、ユーザーに確認を求めます。

• アカウント、プロジェクト、またはサブスクリプション。
• リージョン、リソースグループ、ラベル、タグ、または明示的なインスタンス ID。
• Linux と Windows のグループ。
• カナリアの規模と展開順序。
• 一度限りのインストールか、継続的に適用されるポリシーか。
• 既存の Terraform または構成管理の管理主体。

既存の IaC または管理手段がある場合は、それを使用します。ユーザーに確認せず、命令的な展開を Terraform 管理のインフラストラクチャに混在させてはいけません。

リモートシークレットの取り扱い

Datadog API キーは、選択したプロバイダーのシークレットサービス、またはユーザーが既に使用しているシークレットシステムに保存してください。そのシークレットへのアクセスは、対象インスタンスの ID のみに許可してください。

VM 内に aws、gcloud、または az がインストールされていることを前提とするゲストスクリプトは生成しないでください。対象イメージで既に利用可能であることを確認済みのシークレット取得方法、またはプロバイダーがサポートする保護されたパラメーター機能を使用してください。どちらも利用できない場合は、作業を中止して、承認済みの受け渡し方法をユーザーに確認してください。

API キーを次の場所に置かないでください。

• Terraform のステート。
• インスタンスのメタデータ、ラベル、タグ、またはポリシードキュメント。
• プロセス一覧やシェル履歴から確認できるコマンドライン引数。
• クラウドコマンドの出力やデプロイログ。

AWS では、対象が SSM 管理対象であり、インスタンスロールが選択したシークレットを読み取れることを確認してから、SSM ドキュメントとアソシエーションを使用してください。GCP では、レガシーの Guest Policies ではなく、GA VM Manager OS policy と OS policy assignment の API を使用してください。Azure では、Run Command または VM Applications を使用する前に、マネージド ID と Key Vault へのアクセスを確認してください。

適用する前に、提案するポリシー、ドキュメント、または IaC の差分を提示し、承認を得てください。対象を全フリートに拡大する前に、カナリアを検証してください。

フェーズ 3：直接インストール

可能であれば、プラットフォームを確認してください。

uname -s
uname -m

コマンドは、ユーザーが選択した設定のみを使用して組み立ててください。<DD_ENV> のようなプレースホルダー値をそのまま送信せず、該当行を削除してください。

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
if ! installer=$(curl -fsSL https://install.datadoghq.com/scripts/install_script_agent7.sh); then
  echo "Installer download failed - stop here." >&2; false
elif ! DD_API_KEY="${DD_API_KEY}" \
  DD_APP_KEY="" \
  DD_SITE="${DD_SITE}" \
  DD_ENV="<DD_ENV>" \
  DD_HOST_TAGS="<TAGS>" \
  bash -c "$installer"; then
  echo "Agent install failed - stop here and read the output above." >&2; false
fi

DD_APP_KEY="" は意図的な設定です。インストールスクリプトは検出した DD_APP_KEY をすべて datadog.yaml に書き込みますが、ホストの Agent に必要なのは API キーだけです。いずれかのメッセージが表示された場合は作業を中止してください（その時点でブロックはゼロ以外の終了コードで終了します）。後続の手順に進まないでください。

インストール中の API キーの露出。 インストールスクリプトは、新規インストール時に API キーを必要とし、ファイルや標準入力から渡す方法はありません。内部では root として実行され、datadog.yaml の書き込み中にキーを自身の sh -c およびパッケージマネージャーのコマンドラインへ展開するため、インストールの数秒間、他のローカルユーザーが ps からキーを確認できます。実行前にユーザーへ伝えてください。信頼できないローカルユーザーと共有しているホストでは、代わりに Datadog リポジトリから datadog-agent パッケージをインストールし、コマンドラインにキーを含めずに、/etc/datadog-agent/datadog.yaml に api_key を書き込んでください（モード 640、所有者 dd-agent）。

インストーラーは、デフォルトでインフラストラクチャメトリクスと APM トレースレシーバーを有効にします。インストールスクリプトは DD_LOGS_ENABLED を読み取りません。認識されるログのフラグは DD_LOGS_CONFIG_PROCESS_COLLECT_ALL=true のみで、Logs Agent を有効にするだけではありません。新規インストール時には datadog.yaml に logs_enabled: true と process_log 設定プロバイダーを書き込み、system-probe.yaml で discovery と privileged_logs を有効にするため、Agent の起動と同時に実行中のプロセスのログの追跡が始まります。フェーズ 1 で選択したログ設定を適用してください。

• 自動プロセスログ収集を行わない Logs Agent（ユーザーが「いいえ」と回答した場合、または回答しなかった場合のデフォルト）：インストールブロックは表示どおりに維持し、その後、以下のログブロックを実行してください。
• 自動プロセスログ検出（ユーザーが「はい」と回答した場合のみ）：DD_LOGS_CONFIG_PROCESS_COLLECT_ALL="true" \ を bash -c "$installer" の前にある変数へ追加し、以下のログブロックは実行しないでください。特権ログアクセスを許可せずに検出を維持するには、DD_PRIVILEGED_LOGS_ENABLED="false" \ も追加してください。
• ログを無効にする：インストールブロックは表示どおりに維持し、以下のログブロックは実行しないでください。

標準インストールまたは FIPS インストールが成功した後に実行するログブロック：

if sudo grep -q '^logs_enabled:' /etc/datadog-agent/datadog.yaml; then
  sudo sed -i 's/^logs_enabled:.*/logs_enabled: true/' /etc/datadog-agent/datadog.yaml
else
  echo 'logs_enabled: true' | sudo tee -a /etc/datadog-agent/datadog.yaml >/dev/null
fi
sudo systemctl restart datadog-agent

ユーザーが DD_INSTALL_ONLY=true を選択した場合は、sudo systemctl restart datadog-agent の行を削除してください。この再起動によって Agent が起動するためです。

アプリケーションのログソースとトレーシングライブラリは、引き続きフェーズ 4 で設定します。

オプション設定：

• APM シングルステップインストルメンテーション：DD_APM_INSTRUMENTATION_ENABLED=host。
• ライブプロセス：インストールスクリプトはプロセス収集用の変数を読み取りません。インストール後、/etc/datadog-agent/datadog.yaml に process_config: / process_collection: / enabled: true を設定し、Agent を再起動して、 sudo datadog-agent status の Process Agent セクションを確認してください。
• プロキシ：インストールスクリプトは DD_PROXY_* を読み取りません。スクリプトのダウンロードがプロキシ経由になるよう、インストールブロックに https_proxy / http_proxy / no_proxy を設定してください。また、スクリプトは sudo 経由でパッケージマネージャーを実行するため、パッケージマネージャー自体のプロキシも設定してください（例：apt の場合は Acquire::https::Proxy、/etc/yum.conf の場合は proxy=）。インストール後、/etc/datadog-agent/datadog.yaml の proxy: セクション（https、http、no_proxy）に Agent のプロキシを永続的に設定し、Agent を再起動してください。
• カスタムホスト名：DD_HOSTNAME。
• 同梱の OpenTelemetry Collector：DD_OTELCOLLECTOR_ENABLED=true。
• Agent のバージョンを固定する：DD_AGENT_MINOR_VERSION="<VERSION>"。
• 起動せずにインストールする：DD_INSTALL_ONLY=true（スクリプトは値が空でなければ設定済みとして扱います）。

FIPS が必要な場合は、標準コマンドの代わりに FIPS パッケージを使用してください。

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='ddog-gov.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0 (ddog-gov.com or us2.ddog-gov.com).
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
if ! installer=$(curl -fsSL https://install.datadoghq.com/scripts/install_script_agent7.sh); then
  echo "Installer download failed - stop here." >&2; false
elif ! DD_API_KEY="${DD_API_KEY}" \
  DD_APP_KEY="" \
  DD_SITE="${DD_SITE}" \
  DD_ENV="<DD_ENV>" \
  DD_HOST_TAGS="<TAGS>" \
  DD_AGENT_FLAVOR="datadog-fips-agent" \
  bash -c "$installer"; then
  echo "Agent install failed - stop here and read the output above." >&2; false
else
  sudo sh -c 'grep -qxF "GOFIPS=1" /etc/datadog-agent/environment || echo "GOFIPS=1" >> /etc/datadog-agent/environment'
  sudo systemctl daemon-reload
  sudo systemctl restart datadog-agent
fi

標準コマンドと同じ選択済みの設定（環境、タグ、ログの選択とログブロック、任意の設定）を適用してください。異なるのはパッケージの種類と GOFIPS=1 のランタイム設定のみです。ユーザーが DD_INSTALL_ONLY=true を選択した場合は、sudo systemctl restart datadog-agent の行を削除し、以下の稼働中サービスの確認をスキップしてください。再起動すると Agent が起動してしまうためです。上記の API キーの露出に関する注意事項も、ここに適用されます。

このフローには FIPS 対応の Agent バージョン（現在は 7.65 以降）と、FIPS 準拠の Datadog 環境（US1-FED（ddog-gov.com）または US2-FED（us2.ddog-gov.com））へのアクセスが必要です。Phase 0 で政府機関向けサイトを確認済みの状態に保ち、現在の FIPS ドキュメントを参照して、オペレーティングシステム、クラウドリージョン、ストレージ要件を確認してください。sudo datadog-agent status で FIPS Mode: enabled を確認してください。

パス：

• 設定：/etc/datadog-agent/datadog.yaml
• インテグレーション設定：/etc/datadog-agent/conf.d/
• ログ：/var/log/datadog/agent.log

確認：

sudo systemctl status datadog-agent
sudo datadog-agent status

Phase 4：選択した製品を設定する

Agent が正常な状態になったら：

• アプリケーションログの場合は、対象のファイルまたは journald ユニットを正確に特定し、対応するインテグレーション設定を作成します。logs_enabled: true だけでは、アプリケーションのログソースは選択されません。
• APM の場合は、アプリケーションの言語とデプロイプロセスを特定し、対応するトレーサーライブラリまたはシングルステップインストルメンテーションを設定します。Agent のレシーバーだけでなく、トレースを検証してください。
• PostgreSQL、NGINX、Redis などのインテグレーションの場合は、実行中のサービスを調査し、専用のインテグレーション設定を使用します。

利用可能であるという理由だけで、任意の製品を有効にしないでください。

Phase 5：検証する

status コマンドを実行し、以下を確認してください。

• API キーが有効である。
• Forwarder がトランザクションの成功を報告している。
• コアチェックが実行されている。
• デフォルトで有効な Logs Agent と Trace Agent（および明示的に選択した Process Agent または OTel Collector）が正常な状態である。

sudo datadog-agent status

ホストが表示されない場合は、/var/log/datadog/agent.log を確認してください。sudo datadog-agent diagnose を実行すると、追加の接続チェックを行えます。

<APP_BASE>/infrastructure でホストを確認してください。フリートへのロールアウトでは、残りのターゲットに進む前に、カナリアホストとユーザーが選択した製品を検証してください。

エージェントを最大限に活用する

ホストから報告があった後、Datadog Metrics API で最近のインフラストラクチャメトリクスをクエリします。

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY" |
curl -H @- -s -G "https://api.${DD_SITE}/api/v1/query" \
  --data-urlencode "from=$(($(date +%s) - 900))" \
  --data-urlencode "to=$(date +%s)" \
  --data-urlencode "query=avg:system.cpu.user{host:<HOSTNAME>}"

出力にどちらのキーも含めないでください。ホスト名が不明な場合は、sudo datadog-agent status（または sudo datadog-agent hostname）の Hostname セクションからエージェントが報告する名前を確認し、そのホストをクエリしてください。avg:system.cpu.user{*} を証拠として使用しないでください。組織内のすべてのホストが集計されるため、このインストールから何も送信されていなくても、既存のマシンのデータが返される場合があります。

便利なリンク：

• インフラストラクチャ：<APP_BASE>/infrastructure
• システム概要：<APP_BASE>/dash/integration/1/system---overview
• インテグレーション：<APP_BASE>/integrations
• Fleet Automation：<APP_BASE>/fleet

最後に、変更したホスト、設定したオプション製品、アプリケーションのログソースまたはトレーシングの計装に関して残っている作業を、正確に要約してください。