DB監視ツールの選び方と主なツール【MySQL・PostgreSQL】

MySQL や PostgreSQL の監視ツールを探すと、サーバー監視の製品一覧はたくさん見つかりますが、DB をどこまで見られるのか、どれが自分の環境に合うのかは分かりにくいままです。この記事では DB の監視に絞って主なツールを 3 つの系統に分け、それぞれ何が見られるか、費用はどう決まるか、どんな状況に合うかを整理します。料金と機能は 2026 年 11 月時点で各社の公式サイトを確認したものです。

データベース監視ツールでできること

監視ツールの仕事は、値を集める、保存してグラフにする、条件に当てはまったら通知する、の 3 つです。どのツールもこの 3 つは備えているので、違いが出るのは主に次の点です。

1 つめは DB の中をどこまで見られるかです。CPU やディスクなどサーバーの値だけを取るツールもあれば、接続数やレプリケーションの状態などの DB の統計を取るもの、クエリ 1 つずつの実行時間や実行計画まで記録するものもあります。

2 つめは誰が監視の仕組みを運用するかです。自分たちでサーバーを立てて運用するのか、クラウドや SaaS の事業者に任せるのかで、費用のかかり方と手間が変わります。

3 つめは費用の決まり方です。ホスト (監視対象のサーバー) の台数、送るデータの量、DB の vCPU 時間など、ツールによって課金の単位が違います。同じ規模でも、どの単位で数えるかによって請求額の伸び方が変わります。

監視項目そのものについてはデータベース監視とはで説明しています。この記事では「何で見るか」を扱います。

選ぶ前に決めておくこと

ツールの比較に入る前に、次の 4 点を自分の環境について書き出しておくと、候補がかなり絞れます。

DB はどこで動いているか (Amazon RDS や Cloud SQL などのマネージドサービスか、自前のサーバーか、複数のクラウドにまたがるか)
何を見たいか (止まっていないかだけか、遅いクエリまで追いたいか、注文数のような業務データも見たいか)
監視の仕組みを誰が運用するか (監視サーバーを保守できる人がいるか)
DB サーバーにエージェント (値を集めて送るための常駐プログラム) を入れられるか

マネージドサービスでは DB サーバーに直接ソフトを入れられないため、エージェントは別のサーバーに置いて DB にネットワーク越しに接続する形になります。この構成に対応しているかも、ツールごとに確かめてください。

3 つの系統の違い

主なツールは OSS (オープンソースソフトウェア) を自分で運用するもの、クラウドに最初から付いているもの、SaaS として契約するもの、の 3 つに分けられます。

系統	主なツール	ライセンス費用	運用の手間	向いている状況
OSS を自前で運用	Zabbix、Prometheus + exporter、PMM	かからない	監視サーバーの構築・保守・更新が要る	運用できる人がいる、オンプレミスがある、費用を抑えたい
クラウド標準	Amazon CloudWatch、Google Cloud Monitoring	基本の値は無料、詳細な機能は従量課金	少ない	DB がそのクラウドのマネージドサービスにある
SaaS	Datadog、New Relic、Mackerel	ホスト数やデータ量に応じて課金	少ない (エージェントの導入と設定は要る)	複数の環境をまとめて見たい、監視サーバーを持ちたくない

以下、系統ごとに主なツールを見ていきます。

OSS の監視ツール

Zabbix

Zabbix はサーバー・ネットワーク・アプリケーションをまとめて監視できる OSS です。2026 年 11 月時点の最新は 7.4 で、長期サポート版は 7.0 LTS です。次の長期サポート版 8.0 LTS は 2026 年第 4 四半期に予定されています (公式サイトより)。

MySQL 用には「MySQL by Zabbix agent」「MySQL by Zabbix agent 2」「MySQL by ODBC」のテンプレートがあり、稼働状況、接続数、スレッド数、InnoDB のバッファプールや行ロック待ち、スロークエリ数、DB サイズ、レプリケーションの状態と遅延などを取れます。PostgreSQL 用のテンプレートもあります。

Zabbix の特徴の 1 つが ODBC 監視です。db.odbc.select というアイテムで任意の SQL を実行し、結果の 1 行目・1 列目の値を監視値として取り込めます。注文数や処理待ちのジョブ数のような業務データを監視したい場合に使える方法です。

監視サーバーと、その設定や履歴を保存する DB を自分で運用する必要があります。監視対象が多い会社や、オンプレミスのサーバーとまとめて見たい会社に向いています。使い方の詳細は Zabbix で DB を監視するで扱っています。

Prometheus と exporter

Prometheus は値を時系列で集めて保存する OSS です。DB の値は exporter と呼ばれる小さなプログラムが DB に接続して取り出し、Prometheus が定期的に取りに行きます。グラフには Grafana、通知には Alertmanager を組み合わせるのが一般的です。

MySQL には mysqld_exporter (MySQL 5.6 以降、MariaDB 10.3 以降)、PostgreSQL には postgres_exporter があります。どちらも監視用のユーザーに必要な権限が README に書かれています。

-- mysqld_exporter 用のユーザー (README の例)
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'127.0.0.1';

-- postgres_exporter 用のユーザー (PostgreSQL 10 以降)
GRANT pg_monitor TO postgres_exporter;

すでに Kubernetes やアプリの監視に Prometheus を使っている会社なら、同じ仕組みに DB を足すのが自然です。反対に、DB のためだけに Prometheus・Grafana・Alertmanager の 3 つを立てて保守するのは、小さなチームには負担になりやすい構成です。

Percona Monitoring and Management (PMM)

PMM は Percona 社が公開している、DB に特化した OSS の監視ツールです。MySQL、PostgreSQL、MongoDB を主な対象とし、2026 年 11 月時点の最新は 3.10.0 です (公式ドキュメントより)。PMM Server と、監視対象の側に置く PMM Client (pmm-agent を含む) で構成されます。

サーバー全体の値だけでなく、クエリ 1 つずつの性能まで掘り下げられるのが特徴です。DB の性能調査を自分たちで行いたいが、商用の SaaS は使いにくい、という場合の候補になります。

クラウド標準の監視

Amazon CloudWatch (RDS・Aurora)

Amazon RDS と Aurora を使っているなら、CloudWatch に CPU 使用率、空きメモリ、接続数、空きストレージ、読み書きの遅延などの値が最初から送られています。AWS のサービスが標準で送るこれらの基本の値は無料で、アラームは標準解像度なら 1 つあたり月 0.10 ドル (米国東部、無料枠 10 個) です (2026 年 11 月時点、公式サイトより)。

クエリ単位の分析は CloudWatch Database Insights で行います。Performance Insights は 2026 年に提供を終え、Database Insights に置き換わりました。Database Insights には Standard モード (既定で有効、詳細な値を 7 日間無料で保存) と Advanced モード (プロビジョンドのインスタンスで 1 vCPU 時間あたり 0.0125 ドル) があります。Advanced モードでは、クエリごとの統計、スロークエリの分析、PostgreSQL のロックの分析などが使えます (2026 年 11 月時点、公式サイトより)。

AWS の中で完結しているなら、まずは CloudWatch のアラームを正しく設定するところから始めるのが費用の面でも合理的です。具体的なメトリクスとアラームの設定は RDS・Aurora の監視で説明しています。

Google Cloud Monitoring (Cloud SQL)

Cloud SQL の値は Cloud Monitoring に送られ、アラートポリシーで通知できます。クエリ単位の分析には Query insights があり、負荷の大きいクエリ、待機の内訳 (CPU、I/O、ロック待ち)、実行時間のパーセンタイル、実行計画のサンプルを確認できます。

Query insights に追加料金はかかりません。保存期間は Enterprise エディションで 7 日、Enterprise Plus エディションで 30 日です。Enterprise エディションでは値が Cloud Monitoring に保存されるため、Monitoring API の料金がかかります (2026 年 11 月時点、公式ドキュメントより)。

クラウド標準の監視は導入の手間がほとんどかからない一方、そのクラウドの外にある DB は基本的に対象外です。複数のクラウドやオンプレミスに DB が分かれている場合は、画面と通知の設定が分散します。

SaaS の監視ツール

Datadog

Datadog はインフラ、アプリケーション、ログなどを 1 つの画面で見られる SaaS です。DB については Database Monitoring という製品があり、PostgreSQL、MySQL、MariaDB、SQL Server、Oracle、MongoDB などに対応しています。正規化したクエリごとの性能の履歴、個々の実行のサンプル、実行計画を確認できます。利用には Datadog Agent の導入が必要です。

Database Monitoring の料金は、DB ホスト 1 台あたり月 70 ドル (年払い)、月払いと従量では 84 ドルです (2026 年 11 月時点、公式サイトより)。インフラの監視 (Infrastructure Pro は 1 ホスト月 15 ドル、年払い) などは別の製品として料金が決まっています。

アプリの監視や分散トレースとあわせて、「アプリのどの処理がどのクエリを呼んで遅くなったか」まで追いたい会社に向いています。詳しくは Datadog の解説を参照してください。

New Relic

New Relic もアプリケーション、インフラ、ログをまとめて扱う SaaS です。PostgreSQL、MySQL、SQL Server の連携 (インテグレーション) があり、クエリ性能の監視にも対応しています。PostgreSQL のクエリ単位の値は pg_stat_statements を使って集めます。

料金はデータの取り込み量と利用者数で決まります。毎月 100GB までの取り込みと 1 人のフルプラットフォームユーザーが無料で、それを超える取り込みは 1GB あたり 0.40 ドルです (2026 年 11 月時点、公式サイトより)。ホスト数ではなくデータ量で課金されるため、小さく始めて試しやすい一方、ログなどを大量に送ると費用が増えます。

Mackerel

Mackerel は日本の会社が提供しているサーバー監視の SaaS で、画面とドキュメントが日本語です。MySQL と PostgreSQL にはそれぞれ公式のプラグインがあり、MySQL ではコマンドの実行回数、接続数、InnoDB の行ロック待ちやバッファプール、PostgreSQL では状態ごとの接続数、コミット数、キャッシュと読み込みのブロック数、デッドロック数などを取れます。

料金はスタンダードプランで 1 ホストあたり月 2,180 円 (税込、ホストメトリック 200 個まで) で、5 台まで使えるフリープランもあります (2026 年 11 月時点、公式サイトより)。日本語で運用したい小さなチームや、ホスト単位で費用を見積もりたい会社に向いています。

状況別の選び方

ここまでの内容を、よくある状況ごとにまとめます。どれか 1 つに決める必要はなく、組み合わせて使う会社も多くあります。

状況	まず検討したいもの	理由
AWS の RDS・Aurora だけを使っている	CloudWatch のアラーム + Database Insights	基本の値はすでに集まっていて、追加の仕組みが要らない
Google Cloud の Cloud SQL だけを使っている	Cloud Monitoring + Query insights	同上
オンプレミスのサーバーが多く、運用できる人がいる	Zabbix	サーバーやネットワークとまとめて見られ、ライセンス費用がかからない
すでに Prometheus と Grafana がある	mysqld_exporter / postgres_exporter	既存の監視基盤に DB を足すだけで済む
DB の性能調査を自分たちで深く行いたい	PMM、Datadog Database Monitoring	クエリ単位まで掘り下げられる
アプリと DB をまとめて見たい	Datadog、New Relic	アプリの処理とクエリを結びつけて追える
日本語で、ホスト単位の費用で始めたい	Mackerel	日本語の画面とドキュメント、ホスト単位の料金

導入する前に確かめたいこと

どのツールを選んでも、次の点は導入前に確かめておくと後で困りません。

まず、監視用の DB ユーザーの権限です。多くのツールは PROCESS や REPLICATION CLIENT (MySQL)、pg_monitor (PostgreSQL) を必要とします。アプリ用のユーザーを使い回さず、監視専用のユーザーを作り、書き込みの権限は付けないでください。

次に、監視そのものの負荷です。取得の間隔を短くしすぎたり、重い集計クエリを監視に組み込んだりすると、監視が本番の負荷になります。特に業務データを SQL で数える場合は、インデックスが効くかを確かめ、可能ならレプリカに対して実行します。

3 つめは、費用が何に比例して増えるかです。ホスト単位の課金はサーバーを増やすと、データ量の課金はログを増やすと、vCPU 時間の課金はインスタンスを大きくすると請求額が増えます。半年後の構成を想像して見積もってください。

最後に、業務データの監視はどのツールでも自動では始まらない点です。Zabbix の ODBC 監視のように SQL の結果を取り込む仕組みを持つツールはありますが、どのテーブルの何を数えるか、どこからを異常とするかは自分で決める必要があります。基準の決め方はアラートの閾値の決め方で説明しています。

業務データの監視まで続けるには

ここで挙げたツールのどれかで、サーバーと DB の統計を監視し、アラートを設定するのが出発点です。業務データについては cron で SQL を定期的に実行して結果を記録する、監視ツールの SQL 実行の機能に組み込む、といった方法で少しずつ監視を足していけます。

業務データの監視は AI に任せる方法もあります。Scandock は、接続文字列を登録すると AI がテーブルの構成と実データを読み、注文数や決済の成否、ジョブの滞留のような数字も含めて、何をどの間隔で監視するかを決めるサービスです。PostgreSQL、MySQL、Amazon RDS、Cloud SQL などに対応し、監視は読み取り専用のユーザーで行うため、DB サーバーにエージェントを入れる必要はありません。上のツールでサーバーと DB の状態を見ながら、業務の数字の監視を任せる、という組み合わせもできます。