はじめに
Percona社が開発したモニタリングツールPercona Monitoring and Management (以下 PMM)には様々な機能があり、これまでもいくつか紹介をしてきました。
PMMは約1ヶ月に１回の頻度で新バージョンがリリースされます。本記事では、弊社が注目した新機能を紹介していきたいと思います。
前提
本記事のコマンドや図などはPMM最新リリース2.15.1をDockerで構築した場合を前提に記載しております。
また、記事内の図は一部簡略化しております。
MySQL Group Replication Summaryダッシュボード
PMM2.10.0からMySQL Group Replication Summaryダッシュボードが追加され、Group Replicationもモニタリングできるようになりました。
PMM2.10.0以上のバージョンであれば特別な設定をすることなく利用可能です。
MySQL Group Replication Summaryダッシュボードでは、クラスターの各ノードのステータスを確認したり、レプリケーションの遅延などを確認できます。
グラフ一覧と説明
| グラフ名 | 説明 |
|---|---|
| Group Replication Service States | 各ノードのステータス(MEMBER_STATE)の変移 |
| PRIMARY Service | ステータスがPRIMARYのノードの変移 |
| Replication Group Members | グループメンバーのネットワークと現在のステータスの一覧 |
| Replication Lag | SQLスレッドが適用中のトランザクションがプライマリでコミットされた時間と現在の時刻との時間差 |
| Transport Time | リレーログに最後に書き込まれたトランザクションの書き込まれた時間と、プライマリでコミットされた時間との時間差 |
| Replication Delay | SQLスレッドが最後に適用したトランザクションの適用が終了した時間と、プライマリでコミットされた時間との時間差 |
| Transaction Apply Time | SQLスレッドが最後に適用したトランザクションの適用に要した時間 |
| Transaction Time Inside the Local Queue | リレーログに最後に書き込まれたトランザクションの書き込みに要した時間 |
| Transaction Details | 各ノードの最後に適用したトランザクションのGTIDと適用に要した時間の一覧 |
| Checked Transactions | 競合がチェックされたトランザクションの数 |
| Transactions Row Validating | 認証に使用できるが、ガベージコレクションされていないトランザクションの数 |
| Applied Transactions | ローカルがグループから受信して適用したトランザクションの数 |
| Sent Transactions | ローカルからグループに送信されたトランザクションの数 |
| Received Transactions Queue | ローカルがレプリケーショングループから受信し、適用を待機しているトランザクションの数 |
| Rolled Back Transactions | ローカルで実行され、グループによってロールバックされたトランザクションの数 |
| Transactions in the Queue for Checking | 競合検出チェックを保留しているキュー内のトランザクションの数 |
| Detected Conflicts | 競合検出チェックに合格しなかったトランザクションの数 |
ダッシュボードはPerconaのPMMデモサイトからでも見ることができます。
Metrics Mode
PMM2.12.0でデータソースがPrometheusからVictoriaMetricsに変更されました。
もともとPMMはPMM ServerがPMM Clientに対し、データをPullしていましたが、これにより、PMM Clientで収集されたデータをPMM ClientからPMM Serverにpushすることができるようになりました。
このとき、PMM Clientは4200[0-9]ポートでLISTENしている必要がありました。
また、PMM Clientがモニタリング情報の登録などをする場合にはPMM Serverの443ポートに接続していました。
VictoriaMetricsに変更され、図のようにPMM ClientからPMM Serverに対して、収集したデータをpushできるようになりました。
push方式を選択することで、PMMの通信をPMM ClientからPMM Serverへの一方向にすることができます。Client側とServer側でそれぞれポート開放などの設定を行う必要がなくなります。
push/pullの選択方法
PMM2.12.0以降pushかpullかを選択することができるようになり、PMM2.14.0以降、デフォルトがpullからpushとなりました。
デフォルト以外を選択したい場合は--metrics-mode=pushまたは--metrics-mode=pullフラグを使用します。
node-exporterでpullを選択する場合
|
1 2 |
$ pmm-admin config --server-insecure-tls \ --server-url=https://admin:admin@<Server IP>:443 --metrics-mode=pull |
mysqld-exporterでpullを選択する場合
|
1 |
$ pmm-admin add mysql --username=pmm --password=pass --metrics-mode=pull |
pmm-admin listコマンドで表示されるMetrics Modeで、どちらのモードが選択されているかを確認することができます。
以下の例ではnode_exporterはpush, mysqld_exporterはpullが選択されています。
なお、スロークエリログは常にPMM ClientからPMM Serverへpushされます。
|
1 2 3 4 5 6 7 8 9 10 |
$ pmm-admin list Service type Service name Address and port Service ID MySQL db1-mysql 127.0.0.1:3306 /service_id/5f8587ab-b6a2-49cb-af41-bca86167f1b2 Agent type Status Metrics Mode Agent ID Service ID pmm_agent Connected /agent_id/4f27e73e-ce62-4ffd-ac69-efa13f335818 node_exporter Running push /agent_id/51949cd9-8853-4448-a793-92c51c5f0d19 mysqld_exporter Running pull /agent_id/399db81b-6e9d-4028-b42c-da7c253b75ef /service_id/5f8587ab-b6a2-49cb-af41-bca86167f1b2 mysql_slowlog_agent Running /agent_id/c075b120-4b0c-4255-952d-1add9e216181 /service_id/5f8587ab-b6a2-49cb-af41-bca86167f1b2 vmagent Running push /agent_id/0d163ff1-7813-4eb8-b727-2d067003b6ec |
コレクターの無効化
PMM2.15.0からpmm-adminコマンドのフラグに--disable-collectorsが追加されました。これにより、任意のコレクターを無効にできるようになりました。
選択できるコレクターは各エクスポーターの公式リポジトリ(node_exporter,mysqld_exporter)から確認ができます。
コレクターを無効にすることで、不要なメトリクスを収集しないようにすることができます。
例えば、PMM Serverの要件としてデータ保持期間を1週間としたとき、1つのDB毎に約1GBのストレージが必要とドキュメントに記載があります。
監視対象のDB数に対してストレージが足りない場合は、不要なメトリクスを収集するコレクターを無効にすることで、ストレージのサイズを抑えることができます。
また、PMMでMySQLを監視していると以下のエラーが頻繫に出力されることがあります。
|
1 2 |
Mar 22 10:07:19 node1 pmm-agent: #033[36mINFO#033[0m[2021-03-22T10:07:19.632+00:00] time="2021-03-22T10:07:19Z" level=error msg="Error scraping for collect.engine_tokudb_status: Error 1286: Unknown storage engine 'TOKUDB'" source="exporter.go:116" #033[36magentID#033[0m=/agent_id/0677b08b-f77c-45fe-9275-a4bf518a3efe #033[36mcomponent#033[0m=agent-process #033[36mtype#033[0m=mysqld_exporter Mar 22 10:07:19 node1 pmm-agent: #033[36mINFO#033[0m[2021-03-22T10:07:19.651+00:00] time="2021-03-22T10:07:19Z" level=error msg="Error scraping for collect.heartbeat: Error 1049: Unknown database 'heartbeat'" source="exporter.go:116" #033[36magentID#033[0m=/agent_id/0677b08b-f77c-45fe-9275-a4bf518a3efe #033[36mcomponent#033[0m=agent-process #033[36mtype#033[0m=mysqld_exporter |
これはそれぞれ監視対象のDBにTOKUDBエンジンが存在しない場合とpt-heartbeatが使用されていない場合に出力されます。
こちらのバグチケットで報告されています。
また、MySQL8.0を監視している場合は、information_schemaのテーブル名の変更されたことにより、エラーが出力されるバグが報告されていましたが、PMM2.15.1で解消されました。
原因となっているコレクターは以下の2つです。
– collect.heartbeat
– collect.engine_tokudb_status
このコレクターを無効にすることで、エラーメッセージは出力されなくなります。
複数指定する場合は以下のように,で区切ります。
|
1 2 |
$ pmm-admin add mysql --username=pmm --password=pass \ --disable-collectors='heartbeat,engine_tokudb_status' |
ログを確認すると先ほどのエラーが出力されなくなっています。
|
1 |
$ tail -f /var/log/messages | grep level=error |
まとめ
本記事で紹介した３つの機能について振り返ります。
MySQL Group Replication Summaryダッシュボードについては、Percona XtraDB Cluster/Galera Cluster関連のダッシュボードと比較すると、グラフの数は少ないですが、Overviewではクラスターの状態が一目でわかるようにまとめられています。
PrometheusからVictoriaMetricsへの変更については、pull/pushの選択以外にも、Perconaのblog記事ではメモリ使用率とディスク使用量がPrometheusよりも少なくなったとも報告されています。PMMのパフォーマンスに問題を抱えている場合はPMM2.12.0以上にバージョンアップするといいかもしれません。
コレクターの無効化は、リリースノートによると関連する機能の1つの目のステップであり、将来的にはメトリクスごとにデータの収集間隔を柔軟に変更できるようにする機能が予定されているそうです。監視対象に合わせてより細かくPMMをカスタマイズすることができるようになりそうです。
今後もPMMの新機能には注目していきたいと思います。
