Datadog Agentのブラックボックスを暴く：データロストを根絶し、監視基盤を「物理法則」レベルで掌握する
オブザーバビリティの神髄は、ツールが「沈黙」した瞬間にこそ宿る。
Datadog Agentがデータを吐かない。この事態に直面したとき、多くのエンジニアは管理画面のステータスを眺め、祈りを捧げるか、適当にサービスを再起動する。
だが、真のアーキテクトは違う。彼らはAgentの内部パイプライン、OSのカーネル境界、そしてネットワークの暗部を瞬時に透視する。本稿では、Agentが沈黙する際の「解剖学」と、それを二度と繰り返さないための設計思想を伝授する。
—
1. 脳内地図：Agentのデータパイプラインを理解せよ
Agentは単なるフォワーダーではない。コレクター（Collector）が収集したデータを、内部キュー（Forwarder）に詰め込み、バッファリングし、レートリミットを制御しながらHTTPS(443)で送信する「非同期データパイプライン」だ。
データが消える場所は決まっている。
1. Collector層: Checkがタイムアウトしている（CPU/メモリ不足）。
2. Forwarder層: 送信キューが溢れている（バックプレッシャー）。
3. Network層: 送信先の遮断、または証明書検証の失敗。
迷わず叩くべき「心臓部」のログ
`/var/log/datadog/agent.log` を眺めるのは素人のやることだ。まずはここを叩け。
1. ヘルスチェックの強制実行。これで反応がなければプロセス自体が死んでいる
datadog-agent status | grep -A 20 “Collector”
2. キューの詰まりを可視化（ここが極端に大きい場合はバックプレッシャー）
ドキュメントにはないが、Agentの内部メトリクスを叩くのが最速
curl -s http://localhost:5001/telemetry | jq ‘.metrics.forwarder’
—
2. ネットワークの断絶を「物理」で特定する
プロキシやファイアウォール越しの場合、TCPコネクションの確立すらままならないことが多い。Agentのログに `x509: certificate signed by unknown authority` や `dial tcp: i/o timeout` と出たら、証明書ストアか経路のどちらかが死んでいる。
究極の疎通確認スクリプト
`curl` で叩くだけでは不十分だ。Agentが使用するHTTPSスタックと同一の環境でテストせよ。
!/usr/bin/env python3
import socket
import ssl
Agentがデータ送信を試みるエンドポイント
HOST = “app.datadoghq.com”
PORT = 443
def check_connection():
context = ssl.create_default_context()
try:
with socket.create_connection((HOST, PORT), timeout=5) as sock:
with context.wrap_socket(sock, server_hostname=HOST) as ssock:
print(f”[OK] SSL Handshake successful to {HOST}”)
except Exception as e:
print(f”[ERROR] Network/TLS failure: {e}”)
check_connection()
Tips: プロキシ環境下では、`datadog.yaml` の `proxy` 設定だけでなく、システムレベルの `HTTPS_PROXY` 環境変数が継承されているかを確認せよ。systemdで実行している場合、ユニットファイルの `Environment=` 指定が正義だ。
—
3. メモリ消費とパフォーマンスの「最適化ハック」
Agentのメモリ使用量が異常に増える場合、「高カーディナリティのメトリクス」が犯人だ。IDやタイムスタンプをタグに含めるような馬鹿げた設計は、Agentのインメモリー・ハッシュマップを飽和させ、OOM Killerの標的にする。
対策：カーディナリティ・コントローラー
`datadog.yaml` で、メトリクスの送信量を制限し、高すぎるカーディナリティを排除する。
内部ハッシュマップの肥大化を防ぐための最終防衛ライン
dogstatsd_non_local_traffic: false
1秒間に処理するメトリクスの最大値を制限（過負荷時のバックプレッシャー制御）
dogstatsd_packet_buffer_size: 1024
—
4. 完全自動復旧：オートヒーリング・パイプライン
Agentがハングアップしたとき、人間がSSHログインして再起動するのは、インフラエンジニアの恥だ。
我々は、Agent自身のヘルスを監視し、自律的に回復する「ウォッチドッグ」を構築する。
systemdの神髄（ユニットファイル設定）:
[Service]
プロセスが異常終了したら即座に再起動
Restart=always
RestartSec=5
メモリ上限を設定し、暴走を物理的に止める
MemoryMax=1G
プロセスが応答不能になったら SIGKILL を送る
WatchdogSec=30
さらに、`datadog-agent` のAPIを叩いて、特定のチェックがN分以上動いていない場合にサービスをリスタートさせる独自のスクリプトを `crontab` に仕込んでおくのが「上級者の嗜み」だ。
—
最後に：オブザーバビリティの哲学
Agentがデータを送れないとき、それは「監視システム自体の死」ではなく、「監視システムが発した最初の異常信号」である。
「なぜデータが届かないのか？」という問いを、単なるトラブルシューティングで終わらせてはならない。それは、あなたのプラットフォームが限界に達したという、システムからの警告だ。
我々アーキテクトにとって、トラブルは排除すべき対象ではなく、システムをより強固にするための「インプット」に過ぎない。
Datadogの内部を掌握せよ。そして、監視される側から、監視を支配する側へ回れ。
それが、真のエンジニアリングというものだ。