Datadog Database Monitoring実装手順：監視ユーザー権限とexplain plan収集、APM連携

アプリのレイテンシが跳ねたとき、犯人がデータベースだという見当はすぐ付きます。困るのはその先で、どのクエリが何秒使い、どのテーブルを何行なめたのかが手元に無い。Database Monitoring（以下DBM）は、この空白をクエリ単位の実測で埋める機能です。ただし有効化には、監視専用ユーザーの作成、統計情報の収集設定、explain実行用の関数配置という3つの下ごしらえが要ります。この記事では、Datadog公式ドキュメント（2026年8月16日時点）の記述に沿って、PostgresとMySQLでの前提設定、explain planへ降りる調査手順、APMトレースからクエリを特定する伝播モードの設定、そしてDBMを見送るべき場面までを整理します。

まとめ：DBMで先に決める監視ユーザーと接続経路、伝播モードの3点

先に固めるのは3点です。ひとつ目は接続経路。Agentはデータベースへ直接つなぐ必要があり、プロキシやロードバランサ、接続プーラー越しの構成は公式に対象外とされています。PgBouncerを全経路に噛ませているなら、Agent用のバイパス経路の用意が先です。

ふたつ目は監視ユーザーの権限です。読み取りだけ与えれば動く機能ではありません。Postgresならpg_monitorの付与とdatadogスキーマ作成、MySQLならREPLICATION CLIENTとPROCESSの付与に加え、explain実行用のストアドプロシージャの配置が要ります。ここを飛ばすと、クエリ一覧は出るのに実行計画が空欄のままで止まる。

3つ目が伝播モードの選択です。「遅いクエリ」が分かるのと「誰が呼んだか」が分かるのは別の話で、後者にはトレーサ側のDD_DBM_PROPAGATION_MODE設定が要ります。この3点を先に決めておけば、有効化の手戻りはほぼ消えます。

DBMがAPMやインフラ監視と分ける守備範囲と対応エンジンの範囲

DBMは独立した監視製品ではなく、既存のAgent構成の上に載る追加のインテグレーションです。製品全体の中での位置づけはDatadogとは何かで扱うため、ここでは守備範囲と対応範囲に絞ります。

クエリ単位の性能とインフラメトリクス監視の間に残る空白の埋め方

データベースの監視は従来ふたつに割れていました。ホスト側のメトリクスと、アプリ側のトレースです。前者は「混んでいる」ことしか言わず、後者は「このリクエストの中で遅かった」ことしか言いません。

抜けているのは、データベース全体を横断してクエリを正規化し、種類ごとに合計時間と実行回数を積み上げる視点でした。DBMが埋めるのがここです。収集対象は正規化クエリの性能メトリクス、実行時の詳細を含むクエリサンプル、explain plan、ホストおよびデータベース固有のメトリクスで、指標にはレイテンシ・実行回数・走査行数が含まれます。1回3秒のレポート系より、1回8ミリ秒で毎分4万回走るクエリの方が総時間を食っている、という逆転はここでしか見えません。監視データの種類はAPM（アプリケーション性能監視）とはにまとめました。

PostgresやMySQLなど対応エンジンと接続経路の制約を確認する

対応エンジンは自前構築とマネージドにまたがります。

Amazon DocumentDBとClickHouseも対象です。対応版はPostgresが9.6から18まで、MySQLが5.6・5.7・8.0以上。MariaDBは10.5から11.1が挙がるものの既知の制限が明記されているため、本番採用前に自分の版で試してください。Agent側は7.36.1以上が前提です。

いちばん引っかかるのが接続経路です。ドキュメントは、プロキシ・ロードバランサ・接続プーラーを経由した接続を対象外としています。DBMはセッションの実行状態やホスト単位の統計を読むため、接続が別インスタンスへ振り分けられると連続した観測になりません。PgBouncerやProxySQL、RDS Proxyを標準経路にしている構成では、Agentだけが直接届く経路を確保してください。

監視ユーザーとサーバ設定でつまずくDBM有効化の3つの前提条件

ここが実装の本体です。詰まるのは決まってサーバ側パラメータ、権限、explain用オブジェクトの3つになります。

統計情報の収集設定でPostgresとMySQLに求められるサーバ側の変更

DBMはデータベース自身の統計機構の上に成り立ちます。それが止まっていれば、Agentがいくら接続してもクエリは並びません。

Postgresではpostgresql.confのshared_preload_libraries = pg_stat_statementsとtrack_activity_query_size = 4096が必須です。前者は再起動が要るのでメンテナンス枠の確保が先。後者は既定の1024のままだと長いSQLが尻切れになります。推奨はpg_stat_statements.track = ALL、pg_stat_statements.max = 10000、track_io_timing = onの3つ。

MySQL側はperformance_schema = ONが起点です。加えてmax_digest_lengthとperformance_schema_max_digest_length、performance_schema_max_sql_text_lengthをいずれも4096へ引き上げます。consumerはevents-statements-currentとevents-waits-currentのONが必須で、events-statements-history-longのONが推奨。RDSやAuroraではパラメータグループ側での変更となり、再起動が伴います。

datadogユーザーへ与える権限とexplain用の関数を作る手順

次に監視専用ユーザーを作ります。アプリ用の既存ユーザーを流用すると、DBMが読む統計ビューへの権限をアプリ側に付けて回ることになるため、分けてください。

PostgresではCREATE USER datadog WITH password ...で作成し、15以上ならALTER ROLE datadog INHERITのうえでGRANT pg_monitor TO datadogを与えます。さらに監視対象の各データベースでdatadogスキーマを作り、explain実行用のexplain_statement関数と列統計を読むcolumn_statistics関数を置く。複数あるのに1つにしかスキーマを作らない取りこぼしが多い箇所です。

MySQLでは次の権限を付けます。

• REPLICATION CLIENT：レプリケーション状態とサーバ全体の状態を読む
• PROCESS：実行中のセッションを一覧する
• SELECT ON performance_schema：クエリの実行統計と待機イベントを読む
• SELECT ON mysql.innodb_index_stats：索引の統計を読む

explain planの収集には、datadogスキーマにexplain_statementプロシージャを置いたうえで、監視したい各スキーマにも同名のプロシージャを作成し実行権限を渡す必要があります。「datadogスキーマにだけ作って終わり」にすると、アプリのスキーマのクエリだけ実行計画が出ません。

Agent側のdbm有効化と直接接続が必須になる構成上の制約と例外

データベース側が整ったら、Agentのインテグレーション設定のinstancesに次の要素を書きます。

1. dbm: true（この1行が無いと通常のメトリクス収集にとどまる）
2. host（MySQLではlocalhostでなく127.0.0.1かソケット指定が推奨）
3. portとusername
4. password（ENC[...]形式でシークレット管理へ逃がす）

hostの書き方は地味に効きます。MySQLでlocalhostと書くとクライアントがUnixソケットへ倒れる挙動があり、意図した経路とずれる。パスワードは平文で置かず、Agentのシークレット機構経由にします。配布方式やdatadog.yamlの構成はDatadog Agent導入の実装手順、まだAgentを入れていない段階ならDatadogの使い方を先に通してください。

設計上の上限もひとつ。1つのAgentが監視するインスタンス数は30までが推奨です。数十台のデータベースを踏み台1台へ集約すると、この線を超えて収集が遅延します。ログとの相関を取るならPostgres側のlog_line_prefixを指定形式へ揃える必要があり、パースと属性設計はDatadogログ収集の3経路とパイプライン設計の領分です。

スロークエリをexplain planまで降ろす追跡手順と収集の仕組み

収集が始まると、今度は画面の使い方が問題になります。最初に開くと数百行の正規化クエリが並ぶだけで手が止まる。降り方の順序を決めておけば早く着きます。

正規化クエリの一覧から実行サンプルへ降りていく調査の順序と基準

公式ガイドが示す順序は明快です。Database MonitoringページのQuery metricsタブでNormalized QueryのテーブルをPercent timeで並べ替える。次にSamplesタブで個別の実行サンプルを見る。そこからExplain Plansをドロップダウンで選び、Durationでソートして重いものを開く。最後にSample DetailsのList Viewを読む流れです。

入口をPercent timeにするのが要点です。平均レイテンシで並べると、月次バッチのような「遅いが滅多に走らない」ものが先頭に来ます。なおDBMはリテラル値を除いた形でクエリをまとめるため、WHERE id = 1とWHERE id = 2は同じ1行に集約される。INリストの要素数を可変で組み立てていると別の正規化形として散るので、プレースホルダを使う実装の方が相性は良くなります。

explain planが空欄になる原因と収集を通すための2つの経路

いちばん多い相談がこれです。クエリの一覧と実行回数は出ているのに、実行計画だけが表示されない。原因はほぼ権限まわりに集中します。確認は3段で、対象スキーマにexplain_statementが存在するか、datadogユーザーがそれを実行できるか、そのクエリがサンプルとして捕捉されているか。MySQLでconsumerのevents-statements-currentがOFFのままだと、3つ目で止まります。

Postgresにはもうひとつの経路があります。auto_explain拡張を有効にすると、条件に合致したクエリ（たとえば実行1秒超）の実行計画をデータベース側が自動で出力し、Datadogがそれを該当クエリと関連トレースへ紐付ける。Agentが後からEXPLAINを撃ち直す方式と違い、実際に遅かったその実行時点の計画が取れるのが差です。統計値の変動でプランが揺れる環境では、この経路が向きます。

実行計画のどこを読んで索引の追加と実装側の修正を切り分けるのか

計画が出たら読む順序を固定します。List Viewは各ステップの操作種別、対象テーブル、コスト見積もりを並べるので、上からコストの跳ねている行を探すだけで済む。判断は3つに分かれます。1つ目、単一テーブルの全走査にコストが集中しているなら、絞り込み条件の列に索引が無い典型で、索引追加が効きます。2つ目、走査行数と返した行数の乖離が極端なら、索引はあるが選択性が低いか、関数を噛ませて索引が効かない書き方になっている。この場合はSQLの書き換えが先です。3つ目、計画は妥当なのに合計時間が大きいなら、クエリではなく呼び出し回数の問題で、修正先はアプリケーション側。索引を足しても総時間はほとんど動きません。これを見分けるにはリクエスト側の文脈が要り、そこで次章の伝播設定が効いてきます。

APMトレースからクエリを特定する伝播モードの設定と選び分け方

DBM単体では、重いクエリを発行しているのがどのサービスのどの処理なのかが分かりません。データベースから見えるのはSQLとセッションだけだからです。この結び付けを担うのが、SQLコメントとしてトレース情報を運ぶ伝播の仕組みになります。

DD_DBM_PROPAGATION_MODEで切り替わる3つの伝播モードの差

モードは3つです。

切り替えは環境変数DD_DBM_PROPAGATION_MODEで行います。言語ごとの書き方もあり、Javaはシステムプロパティ-Ddd.dbm.propagation.mode=full、Node.jsは初期化時のdbmPropagationMode、Rubyはcomment_propagation、Goは登録時のWithDBMPropagation()。Pythonは環境変数のみで、psycopg2とasyncpgが対象です。

対応の広さはエンジンで差が出ます。PostgresとMySQLはGo・Java・.NET・Node.js・PHP・Python・Rubyと揃う一方、SQL ServerはGo・Java・.NETに限られ、しかもGoはserviceのみ。OracleはGoとJavaで、こちらもGoはservice止まりです。dd-traceの導入と自動計装はDatadog APM導入の実装手順で扱っています。

fullを選ぶ前に確認するプリペアドステートメントと往復の増加

fullは便利ですが、無条件に選ぶものではなく前提条件が3つ付きます。

ひとつ目がプリペアドステートメントです。JavaのPostgresとMySQL向けでは、1.44以上のトレーサでDD_DBM_TRACE_PREPARED_STATEMENTS=trueを指定すると対応します。裏を返せば、古いトレーサでプリペアドステートメント主体の実装だと、コメントが載らず紐付けが成立しません。ORMを使っていればほぼこの経路です。

ふたつ目が実行コストです。SQL ServerとOracleに対するJavaのfullでは、追加のラウンドトリップが発生する旨が明記されています。常用はservice、調査期間だけfullという運用も現実的でしょう。3つ目がRDS Proxyとの相性で、伝播を有効にすると接続ピニングが増える可能性が挙げられています。まず1サービスで有効化して挙動を見る順序をおすすめします。

APMトレースとクエリを往復して遅延の所在を切り分ける実務の流れ

伝播が効くと画面の往復が成立します。トレース上のデータベーススパンからView in DBMでクエリの統計側へ移動でき、逆にDBM側のサンプルからView Traceで元のリクエストへ戻れる。これで判定できるのが前章の3つ目です。総時間の大きいクエリからトレースへ飛び、同じクエリが1トレース内に何十本も並んでいれば、原因は索引ではなく発行箇所にあると即断できます。1本しか呼ばれていないのに総時間が大きいなら、打ち手はキャッシュ層や集計の事前計算へ切り替わる。

検知の自動化まで進めるなら、正規化クエリのレイテンシや実行回数にモニターを置きます。閾値の決め方と評価ウィンドウの設計はDatadogモニターのタイプ選定と閾値設計にまとめました。versionタグを揃えておくと、デプロイ直後の劣化検知から切り戻し判断まで一本の線でつながります。

DBMを採用してよい条件と導入を見送るべき2つの場面の切り分け

ここは条件を付けて言い切ります。DBMは全システムに要る機能ではなく、障害の出方と体制で採否が分かれます。

採用してよい条件はクエリ起因の障害が繰り返し起きているかどうか

採用してよいのは、次に心当たりがある場合です。過去半年でデータベース起因と疑われる遅延やタイムアウトが複数回起きている。原因の特定に毎回、スロークエリログの掘り起こしから半日以上かかっている。そして、すでにDatadogでAPMかインフラ監視を運用している。

最後の条件は効きます。DBMは既存のAgent構成にインテグレーションを足す形で入るため、別ツールの契約を増やさずに済む。伝播を有効にすればAPMのトレースと直結し、アプリ側の実装問題とデータベース側の索引問題を同じ画面で切り分けられます。

逆に、性能問題が一度も起きていない段階での先回り導入は優先順位が下がります。DBMはデータベースホスト単位での別課金になる構造で、台数の多い環境ほど費用が効いてくる。まずは本番の主系1台に絞って入れ、上位クエリを実際に改善できたかで拡大の可否を決めてください。金額は改定されるため、契約前にDatadogの料金ページで時点を確認します。

マネージドの標準機能で足りる規模と運用を外部へ預ける判断の基準

見送るべき場面はふたつあります。1つ目は、データベースが1〜2台でRDSやCloud SQLの標準機能に収まっている規模。RDSにはPerformance Insightsが付属し、待機イベントと上位クエリを見るだけなら追加費用なしで足りる範囲があります。DBMが効くのは複数台を横断して比較したいときや、APMトレースとの結合が要るときです。

2つ目は、統計収集のためのサーバ側パラメータ変更に踏み切れない場合。shared_preload_librariesの変更は再起動を伴い、performance_schemaの有効化もメモリ消費が増えます。再起動枠が取れない、あるいはメモリに余裕が無いインスタンスでは、Agentだけ入れてもクエリは並ばず設定作業だけが残ります。

導入後に効いてくるのは人の側です。上位クエリが並んでも、索引を足す判断とデプロイを回す担当がいなければリストは動きません。目安は月に1回、上位10本を見て2〜3本に手を入れる時間が確保できるかどうか。開発と並行してチューニングまで回せない体制であれば、保守運用・内製化支援のように監視設定と一次切り分けを外部へ預け、修正方針の決定だけを社内に残す分担も選べます。可視化そのものより、見えた後に誰が直すかを先に決めてください。

よくある質問

DBMの導入検討で問い合わせの多い論点を5つ挙げます。

Datadog DBMはAPMだけでは何が足りないのですか？

APMが記録するのは、アプリが発行したSQLの実行時間だけです。データベース全体で同じクエリが何回走り合計で何秒使ったかは見えません。DBMは正規化クエリ単位で性能メトリクスとサンプル、explain planを持ちます。両方を伝播設定でつなげば、原因が索引にあるのか呼び出し回数にあるのかを切り分けられます。

接続プーラー経由でもDBMは動きますか？

公式ドキュメントは、プロキシ・ロードバランサ・接続プーラーを経由しない直接接続を必須としています。PgBouncerやRDS Proxyを標準経路にしている環境では、Agent専用に直接届く経路を用意してください。アプリ側の接続はプーラー経由のままで構いません。

explain planが表示されないときは何を疑えばよいですか？

順に3つ確認します。対象スキーマにexplain_statementの関数またはプロシージャがあるか。監視ユーザーがそれを実行できるか。そのクエリがサンプルとして捕捉されているか。MySQLではconsumerのevents-statements-currentがOFFだとサンプル自体が取れません。Postgresではauto_explain経由の収集も選べます。

サーバの再起動なしでDBMを有効にできますか？

Postgresでshared_preload_librariesへの追加は再起動を伴い、MySQLのperformance_schema有効化も同様です。ユーザー作成、スキーマと関数の配置、Agent側のdbm: true設定は無停止で進められます。再起動が要る部分だけをメンテナンス枠に寄せてください。

伝播モードはfullとserviceのどちらを選ぶべきですか？

常用はserviceから始めて問題ありません。サービス単位でどこが負荷を掛けているかは把握できます。個別のトレースまで辿る必要が出た調査期間だけfullへ上げる運用が扱いやすい。fullにはプリペアドステートメントの前提条件が付きます。

関連記事

• Datadogとは何か？機能やメリット、導入の背景：製品全体の中でDBMの位置づけを確認したいとき
• Datadog APM導入の実装手順｜dd-trace自動計装：伝播設定の前提となるトレーサの導入
• Datadog Agent導入の実装手順｜3方式とdatadog.yaml：DBM設定を書くAgentの配布と構成
• Datadogモニターのタイプ選定と閾値設計：クエリ性能の劣化を検知する通知の設計
• APM（アプリケーション性能監視）とは：監視データの種類と計装の考え方の整理