Percona Monitoring and Management (PMM) 導入ガイド：MySQL と PostgreSQL の詳細な監視 – ITFROMZERO

Table of Contents

クイックスタート：5分で監視システムを構築

データベースの状態をすぐに確認する必要がありますか？ここでは、Docker を使用して PMM Server を構築し、最初のデータベースをシステムに接続する最短の方法を紹介します。

1. PMM Server の起動

# 永続データ保存用のボリュームを作成
docker volume create pmm-data

# PMM Server コンテナを起動
docker run -d \
  -p 80:80 -p 443:443 \
  --name pmm-server \
  --restart always \
  -v pmm-data:/srv \
  percona/pmm-server:2

2. データベースノードへの PMM Client のインストール

# Ubuntu/Debian の場合
wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
dpkg -i percona-release_latest.generic_all.deb
apt update
apt install pmm2-client

3. クライアントをサーバーに接続

# <PMM_SERVER_IP> をサーバーの IP アドレスに置き換えてください
pmm-admin config --server-insecure-tls --server-url=https://admin:admin@<PMM_SERVER_IP>

実行後、http://<PMM_SERVER_IP> にアクセスしてください。デフォルトのユーザー名/パスワードは admin/admin です。これで準備完了です！

なぜ Prometheus + Grafana を自前で構築せずに PMM を選ぶのか？

以前は、深夜2時にデータベースが「重く」なるたびに、手当たり次第に SHOW PROCESSLIST を叩いていました。一般的なデータベース監視システムを Prometheus、Grafana、そして個別の Exporter を組み合わせて自前で構築するのは、ダッシュボードの設定に非常に時間がかかります。

Percona の PMM は、いわば高級な「インスタントラーメン」のようなものです。CPU や RAM のチャートから、詳細なクエリ分析（Query Analytics – QAN）まで、すべてが統合されています。ダッシュボードの設計に2日かける代わりに、わずか10分で包括的な観測システムを手に入れることができます。

PMM のアーキテクチャの仕組み

PMM は非常に洗練されたクライアント・サーバーモデルで動作します：

PMM Server: VictoriaMetrics を使用したデータ処理センター。Grafana によるチャート表示とアラート管理を行います。
PMM Client: データベースサーバー上で直接動作します。システムメトリクスを収集し、軽量なエージェントを通じてスローログを解析します。

MySQL と PostgreSQL の詳細設定

クライアントを接続した後、PMM が詳細なデータの収集を開始できるように、特定のデータベースを登録する必要があります。

MySQL の場合：

安全性を確保するため、適切な権限を持つ専用ユーザーを作成しましょう：

CREATE USER 'pmm'@'localhost' IDENTIFIED BY 'hijouni_muzukashii_password';
GRANT SELECT, PROCESS, REPLICATION CLIENT, RELOAD, BACKUP_ADMIN ON *.* TO 'pmm'@'localhost';

PMM にノードを追加します：

pmm-admin add mysql --username=pmm --password=hijouni_muzukashii_password --query-source=perfschema

PostgreSQL の場合：

PostgreSQL でクエリを「読み解く」には、pg_stat_statements 拡張機能が必要です。postgresql.conf ファイルを編集してください：

shared_preload_libraries = 'pg_stat_statements'
track_io_timing = on
track_functions = all

Postgres を再起動し、追加コマンドを実行します：

pmm-admin add postgresql --username=postgres --password=your_pass --query-source=pgstatstatements

Query Analytics (QAN)：究極の「武器」

これは PMM の最も価値のある機能です。6ヶ月間使用してみて、パフォーマンス問題の80%はハードウェアではなく、インデックス不足のクエリや過剰な Join にあることに気づきました。

Query Analytics セクションでは、最もリソースを消費しているクエリの一覧が表示されます。以下の指標に注目してください：

Latency: クエリの平均レスポンス時間。
Rows Examined vs Sent: 1行を取得するために100万行をスキャンしている場合、間違いなくすぐにインデックスを貼る必要があります。
Query Count: 特定の期間内にクエリが実行された頻度。

自動アラート（Alerting）の設定

Web サイトのダウンを顧客からの連絡で知るような事態は避けましょう。PMM には強力な Integrated Alerting システムが備わっています。

Contact Points: Slack、Telegram、またはメールへの通知を設定します。
Alert Rules: 「MySQL Down」や「High CPU usage」などの既存テンプレートを使用します。
しきい値の設定: 例えば、CPU 使用率が5分間連続で85%を超えた場合、PMM が自動的にアラートを送信します。

本番運用6ヶ月を経て得られた実践的な経験

監視システム自体が負担にならないよう、これまでの実践的な経験に基づき、以下の3つの重要なポイントに注意してください：

1. クライアントリソースの最適化

PMM Client の CPU 使用率は通常1%未満です。しかし、トラフィックが非常に多い（毎秒10,000リクエスト以上）データベースの場合、詳細なログ収集がディスク I/O を増加させる可能性があります。ディスク負荷を軽減するために、slow_query_log よりも performance_schema の使用を優先してください。

2. データ保持ポリシー (Retention)

監視データは急速に蓄積され、1ヶ月で数十GBに達することもあります。詳細なデータは15〜30日間保持するように設定することをお勧めします。これにより、監視サーバーのディスクが予期せず一杯になるのを防げます。

3. ダッシュボードのセキュリティ

PMM ダッシュボードには、設定やクエリ内容に関する機密情報が含まれています。ポート 80/443 を公共のインターネットに公開しないでください。PMM Server は内部ネットワーク (VPN) 内に配置するか、厳格な IP ホワイトリストを使用すべきです。

要約すると、PMM は無料でありながら、データベース管理者にとって非常に大きな価値をもたらすツールです. 受動的な対応から能動的な管理へと移行し、勘ではなく実際の数値に基づいてトラブルシューティングを行うことができます。