スマートスタイル TECH BLOG

データベース＆クラウド技術情報

Percona Monitoring and Managementの新機能の紹介

1529約8分

はじめに

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を選択する場合

mysqld-exporterでpullを選択する場合

pmm-admin listコマンドで表示されるMetrics Modeで、どちらのモードが選択されているかを確認することができます。
以下の例ではnode_exporterはpush, mysqld_exporterはpullが選択されています。
なお、スロークエリログは常にPMM ClientからPMM Serverへpushされます。

コレクターの無効化

PMM2.15.0からpmm-adminコマンドのフラグに--disable-collectorsが追加されました。これにより、任意のコレクターを無効にできるようになりました。
選択できるコレクターは各エクスポーターの公式リポジトリ(node_exporter,mysqld_exporter)から確認ができます。

コレクターを無効にすることで、不要なメトリクスを収集しないようにすることができます。
例えば、PMM Serverの要件としてデータ保持期間を1週間としたとき、1つのDB毎に約1GBのストレージが必要とドキュメントに記載があります。
監視対象のDB数に対してストレージが足りない場合は、不要なメトリクスを収集するコレクターを無効にすることで、ストレージのサイズを抑えることができます。

また、PMMでMySQLを監視していると以下のエラーが頻繫に出力されることがあります。

これはそれぞれ監視対象のDBにTOKUDBエンジンが存在しない場合とpt-heartbeatが使用されていない場合に出力されます。
こちらのバグチケットで報告されています。
また、MySQL8.0を監視している場合は、information_schemaのテーブル名の変更されたことにより、エラーが出力されるバグが報告されていましたが、PMM2.15.1で解消されました。

原因となっているコレクターは以下の2つです。
– collect.heartbeat
– collect.engine_tokudb_status

このコレクターを無効にすることで、エラーメッセージは出力されなくなります。
複数指定する場合は以下のように,で区切ります。

ログを確認すると先ほどのエラーが出力されなくなっています。

まとめ

本記事で紹介した３つの機能について振り返ります。

MySQL Group Replication Summaryダッシュボードについては、Percona XtraDB Cluster/Galera Cluster関連のダッシュボードと比較すると、グラフの数は少ないですが、Overviewではクラスターの状態が一目でわかるようにまとめられています。

PrometheusからVictoriaMetricsへの変更については、pull/pushの選択以外にも、Perconaのblog記事ではメモリ使用率とディスク使用量がPrometheusよりも少なくなったとも報告されています。PMMのパフォーマンスに問題を抱えている場合はPMM2.12.0以上にバージョンアップするといいかもしれません。

コレクターの無効化は、リリースノートによると関連する機能の1つの目のステップであり、将来的にはメトリクスごとにデータの収集間隔を柔軟に変更できるようにする機能が予定されているそうです。監視対象に合わせてより細かくPMMをカスタマイズすることができるようになりそうです。

今後もPMMの新機能には注目していきたいと思います。

Percona

 

Percona
 
Return Top