インフラ監視

インフラ監視で見えるもの

Datadog のインフラ監視は 4 つの見え方で構成されています。監視対象のホストを一覧する Infrastructure List、環境全体を 1 画面に敷き詰めて色と形で状態を示す Host Map (コンテナ版のマップもあります)、環境中のコンテナをリアルタイムに見る Containers View、そしてホスト上で動く個々のプロセスまで降りる Processes View です (2026 年 8 月時点・出典: Datadog Infrastructure ドキュメント)。ホストマップはグループ化・フィルタ・表示メトリクスを切り替えられるため、「リージョン別に CPU の色分けで並べる」といった見方が数クリックで作れます。台数が数十を超えると一覧では追えなくなるので、マップを既定の入口にすると全体の異常が目に入りやすくなります。

標準で集まるメトリクスの範囲

Datadog Agent を入れたホストからは、既定で有効なコアチェックとして CPU・ディスク・IO・メモリ・ネットワーク・NTP・稼働時間などのシステムメトリクスが集まります (2026 年 8 月時点・出典: Getting Started with the Agent)。これらはホスト単位の料金の範囲内で、アプリケーション独自の数値を送るカスタムメトリクスは別枠の割当 (Pro でホストあたり 100 個・Enterprise で 200 個をアカウント全体で合算) として扱われます。「OS の基本値はホスト課金に含まれ、自前の数値は割当で数える」という線引きを押さえておくと、後からの課金の読み違いを防げます。

監視間隔と粒度

公式ドキュメントには、Agent が 15〜20 秒ごとに 75〜100 個のシステムレベルメトリクスを収集できると記載されています (2026 年 8 月時点・出典: Getting Started with the Agent)。分単位ではなく秒単位の粒度なので、数十秒だけ発生したスパイクも波形として残ります。収集したメトリクスの保持は Pro・Enterprise とも 15 か月で、直近の障害調査だけでなく「去年の同じ時期はどうだったか」という季節比較にも使えます (無料プランは保持 1 日です)。粒度と保持は監視製品の地味な差ですが、原因調査で「その瞬間のデータが残っているか」を分けるのはここです。

CloudWatch と二重に監視する構成の損得

AWS 上のインスタンスは、標準で 5 分間隔のメトリクスが CloudWatch へ送られ、詳細モニタリングを有効にすると 1 分間隔になります (2026 年 8 月時点・出典: AWS EC2 ドキュメント)。追加のメトリクスを集めるには CloudWatch 側でもエージェントの導入が案内されています。一方 Datadog Agent は前述のとおり 15〜20 秒間隔で、メモリを含む OS 内部の値を既定で収集します。両方を全面的に使うと、同じホストに対して監視の投資が二重になり、アラートも二重に鳴ります。整理の軸は「調査と通知の一次面をどちらに置くか」です。Datadog を一次面にするなら、CloudWatch 側は AWS サービスの自動復旧 (オートスケールの発動条件など) に必要な最小限のアラームに絞る、という役割分担にすると重複が削れます。逆に Datadog へ載せるホストを絞る判断は次の節のとおりです。

コンテナ・Kubernetes の扱い

コンテナは Containers View でリアルタイムに監視でき、課金上はホスト料金に含まれる割当 (Pro でホストあたり 5 コンテナ・Enterprise で 10 コンテナ) を超えた分が 1 コンテナ月あたり 1 ドル (2026 年 8 月時点・年契約・US リージョン) で加算されます (出典: Datadog 料金ページ)。また、公式の課金ドキュメントはホストの定義に Kubernetes のノードを含めています。つまり Kubernetes クラスタでは「ノード数 = ホスト数」が基本線で、その上で 1 ノードに高密度に載せたコンテナが割当を超えると追加課金が生じます。ポッドを小さく大量に敷き詰める設計はインフラ効率こそ良いものの、監視費用はコンテナ数に感応する、という綱引きを見積もりに織り込んでください。

何台から Datadog に載せるかの判断軸

無料プランはホスト 5 台まで・メトリクス保持 1 日という条件で、有料の Pro はホストあたり月 15 ドル (2026 年 8 月時点・年契約・US リージョン) です。

判断軸として使えるのは台数そのものより「横断調査の頻度」です。数台のサーバーを 1 人で見ていて、障害調査が単一ホストで完結するうちは、クラウド標準の監視で足りる場面が多いはずです。ホストをまたいだ調査 (どの層が原因かの切り分け) が月に何度も発生するようになったら、1 台 15 ドルと調査にかかる人件費を天秤にかける段階です。全台一括ではなく、本番の中核系から載せて範囲を広げる進め方なら、途中で費用対効果を測り直せます。

最初の一歩はホストマップから

導入直後にダッシュボードを作り込む前に、まずホストマップを開いて環境全体を眺めることをおすすめします。グループ化の軸 (環境・ロール・リージョンなど) を切り替えながら見ると、「どの粒度で監視画面を分けるべきか」が実感としてつかめます。その粒度がそのまま、後で作るダッシュボードの構成やアラートの張り方の設計に写ります。逆にここを飛ばして個別グラフを量産すると、見るための画面ではなく並べただけの画面になりがちです。インフラ監視はモニターとアラートの土台でもあるので、マップで環境の形を把握したら、次は要となるホストの通知づくりへ進むのが自然な順路です。