データベース監視

RDS のメトリクスを取るだけと何が違うのか

インテグレーションで RDS や自前の Postgres からメトリクスを集めると、接続数や CPU、ディスク I/O といった「DB という箱」の状態は見えます。見えないのは、その箱の中でどのクエリが時間を食っているかです。Datadog の Database Monitoring (DBM) はこの部分を担い、公式ドキュメントでは、過去にさかのぼれるクエリ性能メトリクス、実行計画、ホストレベルのメトリクスを 1 か所で見て DB の問題を切り分ける機能と説明されています (2026 年 9 月時点・出典: Database Monitoring)。これが無いと、「DB の CPU が高い」というアラートの後に、DB へ接続して統計ビューを手で読む作業が待っています。あると、遅いクエリと時間の占有率が一覧に並び、インフラ監視の CPU グラフと同じ時間軸で「その時刻に何が走っていたか」を照合できます。

見えるものは 3 つ - クエリの性能推移、実行サンプル、実行計画

DBM の画面のうち、クエリを追う中心は 3 つです。Query Metrics は正規化クエリ (パラメーターの違いをまとめた同じ形のクエリ) ごとの性能を時系列で示し、最も時間を消費するクエリを特定し、チーム / クラスター / ホストなど任意の軸で絞れます。Query Samples はある時刻に実際に走っていたクエリを示し、各実行を平均と比べて、まれだが極端に遅い実行や外れ値を見つけ、ユーザーやアプリ、接続元ホストに帰属させます。Explain Plans は DB の実行計画を段階ごとに示し、大きなテーブルへの逐次スキャンのような高コストな操作と、計画の経時変化を追えます (2026 年 9 月時点・出典: Database Monitoring)。

このほか、DB ホストを一覧する Databases ページ、改善機会を優先順位つきで示す Recommendations ページ、自分のテーブルから業務指標を集める custom_queries があります。

対応データベースとホスティング形態

対応するのは Postgres、MySQL、Oracle、SQL Server、MongoDB、Amazon DocumentDB、ClickHouse の 7 系統で、それぞれセルフホスト版とマネージドクラウド版が対象です (2026 年 9 月時点・出典: Database Monitoring)。手順書はデータベースとホスティング形態の組み合わせごとに分かれており、Postgres を例に取ると、対応バージョンは 9.6 から 18 まで、ホスティングはセルフホスト、Amazon RDS、Amazon Aurora、Google Cloud SQL、Google AlloyDB、Azure、Heroku、Supabase の 8 種が並びます (2026 年 9 月時点・出典: Setting up Postgres)。

自分の DB がこの表に無い場合も、インテグレーションのメトリクス収集は別に用意されていることがあるので、両者を分けて確認してください。

APM のクエリ表示との役割差

APM を入れていると、トレースの中に DB へのクエリがスパンとして現れ、「どのクエリに何ミリ秒かかったか」が見えます。ではなぜ DBM が別に要るのか。APM が見ているのはアプリ側から見た待ち時間で、DB の内部で何が起きたかは映りません。公式ドキュメントも、Query Metrics は更新行数や返却行数のような APM では捕捉されない DB レベルの指標を示すと書いています (2026 年 9 月時点・出典: Database Monitoring)。逆に DBM だけでは、そのクエリをどのサービスが呼んだかは DB 側の情報からしか推定できません。Databases ページの各ホスト詳細には呼び出し元サービスが表示されるので、アプリ → DB は APM、DB → アプリは DBM、と行き来する使い方になります。課金も APM はホストとスパン量、DBM は DB ホスト単位と別建てなので、DB の遅さだけを追う段階なら DBM を先に入れる選択も成り立ちます。

課金は DB ホスト単位 - 正規化クエリ 200 の割当

課金単位はデータベースホストです。Datadog 料金ページでは、DB ホスト 1 台あたりの月額として年契約の単価と、それより高い月契約・オンデマンドの単価が示され、各ホストに正規化クエリ 200 本の割当が付きます (出典: Datadog Pricing)。正規化クエリとは、パラメーターだけが違う同じ形のクエリをまとめたもので、公式の課金ドキュメントは、追跡対象として設定された正規化クエリの総数に基づく課金があると書いています (2026 年 9 月時点・出典: Pricing (Billing))。DB ホストは監視中の一意な台数を毎時記録して数え、方式はインフラ監視のホストと同じです。注意点は、DB ホストがアプリの動くホストとは別に数えられ、インフラ監視を契約済みでも DBM の対象にした DB の台数分が上乗せになることです。SKU 全体の読み方は料金体系の読み解き方へ。本記事は課金の仕組みを解説するものです。具体的な単価や料金は Datadog 公式の料金ページで確認してください。

有効化に何が要るか

前提は 2 つです。1 つはインフラ監視を契約し、標準の Datadog Agent を設置済みであること。料金ページの FAQ は、その状態なら DBM を使えると答えています (2026 年 8 月時点・出典: Datadog Pricing)。もう 1 つは DB 側の設定で、公式ドキュメントの手順は「データベースを設定し、Agent をインストールする」の 2 段から成り、データベースとホスティング形態の組み合わせごとに手順書が分かれます (2026 年 9 月時点・出典: Database Monitoring)。Agent が DB に接続して統計を読む方式なので、アプリのコードに手を入れる計装は要りません。DB 側の設定は DB ごとの手順書に従うため、DB の管理者と「Agent が何を読むか」を先に合意しておくと導入が滞りません。クエリのパラメーターは Agent 側で難読化され、料金ページは全クエリデータからの個人情報の自動難読化を機能として挙げています。

遅いクエリを特定する順序

DBM を活かすには、アプリ側の遅さから DB 側の待ち、実行計画へと降りる順序を決めておくと迷いません。

この順序の要点は 2 つです。1 つは、DB 側から入らないこと。DB の CPU が高くても、利用者が遅いと感じているエンドポイントに繋がらない調査は優先度を誤ります。もう 1 つは、実行計画を最後に見ること。計画は答えを与えてくれますが、どのクエリを直すかが決まっていない段階で開くと読む量が膨れます。「誰が困っているか → どのクエリか → なぜ遅いか」の順に絞れば、DBM の 3 画面はそのまま調査の 3 段階に対応します。