Datadog Agent

Agent は何を集めて何を送るか

Datadog Agent は監視対象のホストで動き続ける常駐プログラムで、CPU・メモリ・ディスクといったホストのメトリクスとイベントを定期的に収集し、Datadog へ送信します。設定を追加すれば、同じ Agent がログの収集、APM のトレースの受け取り、動作中プロセスの情報収集も担います。データの種類ごとに別の収集ソフトを入れて回るのではなく、1 台につき 1 つの Agent が入口をまとめて引き受ける構造です。公式ドキュメントには参考値として、Agent 7.34.0 を AWS の c5.xlarge インスタンスで動かした場合に CPU 使用率が平均約 0.08%・メモリ使用量が約 130 MB (RSS) だったという実測が載っています (2026 年 8 月時点・出典: Datadog Agent ドキュメント)。監視対象への負荷はかなり小さい部類ですが、同じページには、旧世代の Agent 6.15.0 でログ収集を有効にした場合に CPU 負荷が上がる実測も記載されており (前述の 7.34.0 とは別条件の測定)、完全にゼロとは見なせません。

インストールの基本 - 主要 OS からコンテナまで

インストール手順は環境ごとに用意されており、公式ドキュメントは Amazon Linux をはじめとする Linux 各ディストリビューション・Windows・macOS のほか、Docker・Kubernetes・Amazon ECS などのコンテナ環境、Heroku や AWS Lambda 向けの導入方法を提供しています (2026 年 8 月時点)。数台のサーバーなら配布されるインストールコマンドを 1 台ずつ実行すれば済みますが、台数が増えるなら Ansible・Chef・Puppet・SaltStack といった構成管理ツール用の公式レシピで配る形が現実的です。導入後のアップグレードや設定変更をブラウザ上からまとめて行う Fleet Automation という管理機能もあり、公式は大規模環境でのインストール・更新の管理にこれを推奨しています。

構成ファイルと状態確認コマンド

Agent の中心となる設定ファイルは datadog.yaml で、データの送信先リージョンを決める site などの基本設定をここに書きます。導入直後にまず覚えておきたいのが状態確認コマンドです。

sudo datadog-agent status

出力の Running Checks 欄には、有効化したインテグレーションごとの実行回数・収集したメトリクス数・平均実行時間が並びます。ここに警告やエラーが出ていなければ、そのチェックは正しく動いています。サービスとしての起動・停止は、Linux では service datadog-agent start / stop、Kubernetes では Agent の Pod を削除すると自動的に再スケジュールされる、というように環境ごとの流儀があります (出典: Agent Commands)。

エージェントレス連携との使い分け

Datadog はクラウド事業者とのインテグレーションを備えており、AWS・Google Cloud・Azure・vSphere などは Agent を入れなくても、クラウド側の API が公開する計測値を取り込んで監視できます。では Agent はいつ必須になるのか。境界線は「ホストの外から見える情報か、内側に入らないと見えない情報か」です。クラウドの API が返すのはインスタンス単位の使用率のように外側から観測できる値までで、OS 内のプロセスの一覧、アプリケーションのトレース、ホスト上のログファイルの収集は Agent の仕事になります。実務では、まずクラウドインテグレーションで環境全体を薄く覆い、深く見たいホストにだけ Agent を入れる、という二段構えが組みやすい形です。ただし、エージェントレスで取り込んだ VM も課金対象のホストとして数えられる点は、次の節のとおり見積もりの前提に置いてください。

ホスト課金との関係 - Agent の台数だけでは決まらない

Agent というソフトウェア自体には、2026 年 8 月時点の公式料金表に対応する課金項目がありません。課金が発生するのはインフラ監視などのプロダクト側で、単位は「ホスト数」です。ここで誤解しやすいのが数える範囲で、公式の課金ドキュメントは、Agent を入れたインスタンスに加えて、AWS・Google Cloud・Azure・vSphere のインテグレーション経由で監視している VM もホストとして数えると明記しています (Agent 入りの VM が二重に数えられることはありません)。台数は毎時カウントされ、月末に当月の計測値から上位 1% を除いた最大値 (高水位) が請求の基準になります。オートスケールによる短時間の増加は請求に響きにくい一方、月の途中で恒常的に台数が増えると、その水準がその月の請求を決めます (出典: Datadog 課金ドキュメント)。

詳しい料金の読み解き方は料金体系の解説記事にまとめています。

バージョン管理と更新の落とし穴

2026 年 8 月時点の現行メジャーバージョンは Agent 7 で、公式はマイナー・パッチリリースのたび、少なくとも月 1 回の更新を推奨しています。監視ソフトは「動いているから触らない」が起こりやすい領域ですが、更新を長く放置すると、新しく使いたい機能やインテグレーションが要求するバージョンに届かず、いざというときに一足飛びの大きなアップグレードを強いられます。かといって全台一斉更新は、Agent 側に不具合があった場合に監視そのものを失うため、一部のホストで先に更新して様子を見てから残りへ広げる段階更新が安全です。台数が多い環境では、リモートアップグレードに対応した Fleet Automation を使うか、構成管理ツール側でバージョンを「最新」ではなく明示的な番号で固定し、更新を意図的な作業として扱うのが落とし穴を避ける近道です。

止めるとき・外すときの後始末

Agent の停止は Linux なら service datadog-agent stop で、アンインストールの手順は OS ごとに公式ドキュメントが用意されています。課金との関係で知っておきたいのは、データを送らなくなったホスト (インフラリストで INACTIVE と表示される状態) は課金対象から外れ、一覧から消えるまでに最大 2 時間ほどかかる、という公式記載です。ただし前の節で述べたとおり、請求は当月の高水位で決まるため、月の途中で Agent を外しても、その月の請求額がすぐに下がるとは限りません。検証のために一時的に多数のホストで Agent を動かす場合は、外した時期と請求の計測方式をセットで覚えておくと、翌月の請求書を見て慌てずに済みます。