「Agent は入れたのに、Datadog にデータが届かない（ログやトレース、場合によってはメトリクスも）。PoC の現場では、ときどき出会う壁です。
2025年9月11日、Datadog 日本オフィスで開催されたオフラインのハンズオンに参加し、この“最初の壁”をどう乗り越えるかを実機で確認してきました。
この記事では、当日の流れを参加者目線で振り返りながら、つまずきやすいポイントと解決のコツを書き残します。

※ 本記事は 2025/09/11 時点の内容に基づいています。

勉強会について

テーマは「仮想顧客と PoC を進める想定で、導入したはずなのに Datadog にデータが届かない状態を解消する」。座学で要点を押さえたあと、用意された環境で Agent とアプリ（notes-app 相当）を操作し、原因を切り分けて復旧まで進めました。オフラインならではのテンポ感で、講師の方に画面を見てもらいながら手早く試行錯誤できたのが良かったです。

最初の手がかりは“動いていない”でした

まずは状態確認から始めます。端末でプロセスを見てみると、Datadog Agent が動いていませんでした。
PoC ではここで焦らず、「ほんとうに動いているか」「どのプロセスがどのポートを使っているか」を最初に確かめるのが近道だと改めて感じます。


psでDatadog Agentが未稼働であることを確認
ps で Datadog Agent が未稼働と判明。ここが起点でした。

導入のワンライナーは強い味方

今回は UI のガイドに沿って Agent をセットアップしました。APM をオンにすると、必要な変数がコマンドに自動で含まれます。PoC ではまずこの方法で“正しい初期状態”を素早く作ってしまうのが効率的です。


Install AgentsでAPMをONにしてインストール
Install Agents で APM を ON。ワンライナーに反映されるのが便利でした。

ログが語ること：DNS とポート競合

それでもデータが来ないときは、ログを素直に読みます。
agent.log には name resolution のエラー、trace-agent.log には 8126 の bind 失敗。
つまり「外へ出られていない」か「ポートがふさがっている」か、あるいはその両方です。


agent.logでname resolutionエラーを確認
agent.log の name resolution エラー。まずはネットワークを疑います。

trace-agent.logで8126のbind競合を確認
trace-agent.log の 8126 競合。ローカルの受け口が重なっていました。

まずはポートの競合をほどく

検証では、Trace Agent の受信ポートを一時的に 8126 → 8129 へ切り替えました。
設定を反映してから /info を叩くと、Receiver が 8129 に更新されていることが確認できます。復旧の途中経過を数値や API で確かめられるのは、とても心強いです。

# datadog.yaml の一例（環境によりパスは異なります）
apm_config:
  enabled: true
  receiver_port: 8129

sudo systemctl restart datadog-agent


datadog-agentを再起動し、statusでactive(running)を確認
datadog-agent を再起動し、status で active (running) を確認。


/infoでReceiverがlocalhost:8129に切り替わったことを確認
/info で Receiver が localhost:8129 に切り替わったことを確認。

アプリ側も一緒に動かす

Agent のポートを変えたら、アプリのトレーサにも同じポートを伝える必要があります。今回は DD_AGENT_PORT=8129 を指定してアプリを再起動しました。ここを忘れると、いつまでもデータが来ないので要注意です。

# 例（Python ddtrace-run）
export DD_AGENT_PORT=8129
DD_SERVICE=notes DD_ENV=dev ddtrace-run python3 -m notes_app.app

Receiverポート変更時はトレーサ側でDD_AGENT_PORT（またはDD_TRACE_AGENT_URL）を更新する必要がある旨の説明
Receiver ポート変更に合わせ、トレーサ側でも DD_AGENT_PORT を更新する必要があります。

restart_notesでDD_AGENT_PORT=8129を設定し、アプリを再起動
restart_notes で DD_AGENT_PORT=8129 をセットしてアプリを再起動。

出口を開ける：UFW と DNS

最後はネットワークです。UFW のポリシーが deny (outgoing) になっていて、外向きの通信が落ちていました。HTTPS（443）と DNS（53）を許可して Agent を再起動すると、ようやく画面にデータが流れ込みます。PoC の初動では、まずこの 2 つを通すだけでも前に進みやすくなります。


ufw status verbose で deny (outgoing) が有効な状態
UFW の既定が deny (outgoing)。これがボトルネックでした。

ufw allow out 443/53 を適用後、許可が反映された状態
443（HTTPS）と 53（DNS）を許可して再起動。疎通が戻りました。
sudo ufw allow out 443
sudo ufw allow out 53
sudo systemctl restart datadog-agent

届いたことを、ちゃんと確かめる

復旧の最終確認は UI で行いました。
今回は トレース（APM）とログで到達を確認しています。環境によってはメトリクスやダッシュボードの更新も併せて見ると安心です。
ここまで行けば、「導入したのに見えない」はひとまず解消です。


APM Spans（Before）: notes のトレースがまだ表示されていない状態


APM Spans（After）: notes サービスのトレースが到達している状態
APM Spans の Before / After。復旧後は notes のトレースが並びます。


Log Explorer に notes.app のログが到達している状態
Log Explorer にもログが流入。調査のときに心強い材料になります。

ログ収集の最小構成（メモ）

今回の環境では、Agent 全体の logs_enabled: true を有効化し、対象アプリのファイルを 1 本だけ取り込みました。PoC の段階では、まずは“見るべきログを最小構成で流す”くらいが扱いやすいと感じます。

# /etc/datadog-agent/conf.d/notes.d/conf.yaml
logs:
  - type: file
    path: "/root/lab/apm-tutorial-python/app.log"
    service: "notes.app"

終わってみて

今回の 3 時間で得た一番の学びは、切り分けの順番でした。プロセスが動いているか、ポートが競合していないか、アプリと Agent の設定が揃っているか、そして外へ出られるか。順番に当てていけば、原因は必ずどこかで顔を出します。PoC の評価観点（SLO や合格基準）を意識しつつ、まずは“見える状態”を最短で作る——その後にダッシュボードや運用設計を重ねていくのが、実務では現実的だと感じました。

おわりに

この記事が、これから Datadog の PoC を始める方の「最初の壁」を越える手助けになれば嬉しいです。
次はダッシュボードの型やアラート文面の作り込み、Watchdog/エラー追跡の使いどころも試して、またレポートします。