Datadog Agentが沈黙した夜に：現場のテックリードが伝授する「即時復旧」の解剖学
システムが悲鳴を上げているのに、Datadogのダッシュボードが冷徹なまでの静寂を保っている――。これはオブザーバビリティの敗北であり、我々エンジニアにとって最も屈辱的な瞬間です。
「データが飛んでこない」。その原因は往々にして、複雑な分散アーキテクチャのどこかにある見えない壁です。今日は、Datadog Agentが沈黙した際に、迷わず最短距離で「正解」にたどり着くための現場の知見を授けます。
—
1. 現場の眼：ログが語る「真実」の場所
まずは深呼吸して、Agentのバイタルサインを確認しましょう。マニュアルに載っているコマンドを打つ前に、以下の場所を直撃します。
- Linux (systemd): `journalctl -u datadog-agent –since “1 hour ago” –no-pager`
- Agent内部ログ: `/var/log/datadog/agent.log`
ここで重要なのは、ログを「眺める」のではなく「エラーの種別」でフィルタリングすることです。
- `403 Forbidden`: APIキーの無効化、または組織のスコープ外。
- `429 Too Many Requests`: インジェスト制限。タグの付与過多やメトリクスのカーディナリティ爆発が原因。
- `i/o timeout`: ネットワーク層の遮断。
隠れた神コマンド：`datadog-agent status`
単なる起動確認ではありません。このコマンドの出力にある “Collector” と “Forwarder” のセクションを見てください。「何が送信に失敗したか」だけでなく、「現在どれだけのペイロードがキューに溜まっているか」というBacklogサイズまで見通すのが、真のプロです。
—
2. ネットワークの深層：見えない壁を突破する
多くの現場で、プロキシやファイアウォールの設定ミスが時間を奪います。
プロキシ設定のベストプラクティス
`datadog.yaml` の `proxy` セクションは、単に記述するだけでなく、環境変数との優先順位を理解してください。
/etc/datadog-agent/datadog.yaml
proxy:
http: http://proxy.example.com:3128
https: http://proxy.example.com:3128
# 重要: 内部通信用アドレスは除外する（疎通確認のノイズを減らす）
no_proxy:
- localhost
- 127.0.0.1
- 169.254.169.254 # AWSメタデータサービス等
ネットワーク疎通確認の極意
`curl` でエンドポイントを叩く際、`-v` オプションはもちろんのこと、DNS解決のレイテンシを疑ってください。
Agentが通信する全エンドポイントへの疎通チェック
curl -v https://app.datadoghq.com/intake/
ここでタイムアウトする場合、セキュリティチームに「Datadogのアウトバウンド許可リスト」を突きつける前に、`mtr` コマンドでパケットロスが発生しているホップ数を確認しましょう。
—
3. 生産性を極限まで高める「テックリードの装備品」
推奨プラグイン・ツール
- VSCode “YAML” (by Red Hat): DatadogのYAMLスキーマを紐付ければ、設定ミスを記述前に検知できます。
- datadog-agent-helper (自作スクリプト): チームで設定ファイルを共有する際、`datadog.yaml` を読み込んで「機密情報(API KEY)をマスクしてSlackに投げる」小さなスクリプトを共有しておくのが、事故を防ぐ鉄則です。
設定の共有化：GitOpsの原則
設定ファイルは絶対に手動で編集してはいけません。`datadog.yaml` を含む全ての構成ファイルをIaC (Ansible/Terraform) で管理し、CI上で `datadog-agent check config` を走らせる。これが「なぜか設定が反映されない」という不毛な議論を撲滅する唯一の方法です。
—
4. プロのベストプラクティス構成例
チーム開発でトラブルを最小化するための `datadog.yaml` の構成案です。
運用を楽にするための構成
api_key: ENC[AES256_GCM,data:…] # シークレット管理ツールで暗号化推奨
site: datadoghq.com # 日本リージョンなら ap1.datadoghq.com
ログ収集の爆発を防ぐ最強の設定
logs_enabled: true
logs_config:
# ログが多すぎる場合、特定のパターンを除外するフィルタリングを徹底
processing_rules:
- type: exclude_at_match
name: filter_health_checks
pattern: ‘GET /healthz’
ネットワークの安定化
forwarder_timeout: 20
—
最後に：トラブルシューティングは「観察」である
障害が起きたとき、慌ててAgentを再起動するエンジニアは二流です。
まず、「何が起きていないか」を特定してください。
メトリクスは届いているのか？ログだけが止まっているのか？それともAPMトレースだけが消えたのか？
オブザーバビリティとは、ツールを入れることではありません。「システムが沈黙した瞬間に、その沈黙の理由を即座に言語化できる能力」のことです。
この記事を読んだ皆さんは、明日から「Agentが動かない」と焦る必要はありません。ログを読み、ネットワークを透視し、IaCで確実に管理する。その一歩先にある「ノイズのない快適な運用」を目指してください。
健闘を祈ります。