こんにちは！開発現場で「あれ、Datadogにデータが届いてない……？」と冷や汗をかいた経験はありませんか？
深夜の障害対応、あるいは新しい環境の構築中。ダッシュボードを開いてもグラフが真っ黒なまま。そんな時、多くのエンジニアは「どこが間違っているんだ？」と迷宮入りしがちです。
でも、安心してください。Datadog Agentがデータを送信できない原因は、実は「見るべき場所」さえ知っていれば、9割がた数分で特定できます。
今回は、数々の修羅場をくぐり抜けてきたオブザーバビリティ・アーキテクトの私が、Datadog Agentの通信の仕組みから、泥臭いログの追い方、そしてネットワークの壁を突破する方法まで、現場で本当に役立つ知見をすべて伝授します。
これをマスターすれば、もう「データが消えたミステリー」に怯える必要はありませんよ。
—
1. そもそもDatadog Agentは何をしているのか？（超基礎の確認）
トラブルシューティングに入る前に、Agentの「本質」を理解しましょう。
Datadog Agentは、単なる「プログラムの監視」ではありません。あなたのサーバー（ホスト）の奥深くに常駐し、CPUやメモリのメトリクスをかき集め、ログをテールし、APM（アプリケーションパフォーマンス監視）のトレースデータをバッファリングし、最終的にHTTPS（ポート443）でDatadogのクラウドへ送り出す「小さな郵便配達員」です。
この郵便配達員が途中で迷子になったり、宛先を間違えたり、途中の門番（ファイアウォール）に止められたりしているのが、「データが反映されない」という現象の正体です。
—
2. 【最重要】まずどこを見るべきか？ ログファイルの場所と読み方
データが届かない時、管理画面をいくらリロードしても解決しません。見るべきはローカルのログです。OSごとに以下の場所を確認してください。
各OSのログ格納場所
- Linux (Ubuntu / RHEL 等): `/var/log/datadog/agent.log`
- Windows: `C:\ProgramData\Datadog\logs\agent.log`
- macOS (Homebrew): `~/.datadog-agent/logs/agent.log`（またはホスト環境による）
🚨 現場で使える「怪しいログ」の見分け方
`agent.log` を開いたら、以下のキーワードで `grep`（または検索）してください。
sudo tail -f /var/log/datadog/agent.log | grep -E “ERROR|WARN|connection refused|timeout|403|401”
ここでよく遭遇する「絶望のメッセージ」と、その意味を翻訳しておきます。
1. `Invalid API key`（APIキーが無効）
- 原因: 設定ファイルのAPIキーが間違っている、またはコピペの際に余計なスペースが入っている。
2. `Connection refused` / `No route to host`（接続拒否・ルートなし）
- 原因: ネットワーク、ファイアウォール、またはプロキシの設定ミスで、Datadogのクラウドに物理的に届いていない。
3. `x509: certificate signed by unknown authority`（証明書エラー）
- 原因: 社内のプロキシやセキュリティ製品（SSLインスペクション等）が通信の中身を書き換えているため、ルート証明書が信頼されていない。
—
3. ネットワークの壁を突破する：プロキシとファイアウォールの確認
データ送信トラブルの圧倒的な原因は、ネットワーク層にあります。Datadog Agentが通信するために必要な「条件」を整理しましょう。
① 宛先とポートの解放
Datadog Agentは、原則として外向き（Outbound）のHTTPS（ポート443）のみを使用します。イン側のポートを開ける必要はありません（ここ、よく誤解されます！）。
- 接続先エンドポイント: `.datadoghq.com` （※リージョンによって異なります。日本リージョンなら `.ap1.datadoghq.com` など）
② ファイアウォール・セキュリティグループのチェック
サーバーから直接、Datadogのエンドポイントへ疎通ができるか、`curl` コマンドで確認してみましょう。
APIキーのエンドポイントに対して疎通確認（USリージョンの例）
curl -v https://api.datadoghq.com/api/v1/validate -H “DD-API-KEY: あなたのAPIキー”
もしここで `Connection timed out` になるなら、セキュリティグループ（AWS）、NACL、あるいはOSのファイアウォール（`iptables` や `ufw`）が外向きの通信をブロックしています。
③ プロキシ環境下での設定（ここに注意！）
社内ネットワークなどでプロキシが必須の環境では、Agentにも「プロキシの通り道」を教えてあげる必要があります。
メインの設定ファイルである `datadog.yaml`（通常 `/etc/datadog-agent/datadog.yaml` にあります）を開き、以下のセクションを設定します。
/etc/datadog-agent/datadog.yaml の設定例
proxy:
host: “proxy.example.com”
port: 3128
# 認証が必要な場合
# user: “username”
# password: “password”
# 社内独自の証明書を使っている場合などでSSL検証をスキップしたい時（非推奨だが緊急避難として）
# skip_ssl_validation: false
設定を変更した後は、必ずAgentを再起動してください。
- Linux: `sudo systemctl restart datadog-agent`
- Windows (PowerShell): `Restart-Service datadog-agent`
—
4. 最終兵器：Agentの「健康診断」コマンドを使う
「どこに問題があるか分からない！」という時は、Datadog Agentに標準搭載されている最強の診断ツールを使いましょう。
以下のコマンドを叩くだけです。
sudo datadog-agent status
このコマンドを実行すると、Agentの現在の健康状態がターミナルいっぱいに表示されます。ここで見るべきポイントは上部の「Collector」と「JMX / Checks」、そして一番下にある「Connectivity Diagnostics（接続診断）」です。
もし接続に問題があれば、このステータス画面が「どこで失敗したか」を赤字で懇切丁寧に教えてくれます。まずはこのコマンドを打つ習慣をつけるだけで、トラブルシューティングのスピードが3倍に跳ね上がりますよ。
—
まとめ：トラブルシューティングの黄金律
Datadog Agentがデータを送信できない時のアプローチを、もう一度おさらいしましょう。
1. 焦らず `agent.log` を開く（エラーの正体を直視する）
2. APIキーとリージョンを確認する（ケアレスミスを疑う）
3. ネットワーク・プロキシの壁を疑う（`curl` や `datadog-agent status` で疎通テスト）
これらを順番に行えば、原因が特定できないトラブルはありません。
「オブザーバビリティ（可観測性）」を担保するツール自身がブラックボックスになっていては本末転倒ですよね。仕組みを正しく理解し、手際よくトラブルをシュリンクできるようになると、インフラを触るのがもっと楽しく、エキサイティングになりますよ。
あなたのシステムの健康が、無事にDatadogに届くことを祈っています！