Percona Monitoring and Management2 Advisor Checks 機能を使用して独自のチェックを開発する

この記事は最終更新から1年以上経過しています。内容が古くなっている可能性があります。

Percona Monitoring and Management2 Advisor Checks 機能を使用して独自のチェックを開発する

Percona Monitoring and Management 2(PMM2) では Security Threat Tool という監視対象サーバのセキュリティチェックを行い、結果をUIに表示する機能が実装されています。

PMM 2.27ではこのセキュリティチェック機能が「Advisor Checks」という名称に変更され、2.28 では 2.27の「Advisor Checks」を v1 として 「Advisor Checks v2」が実装されました。

現時点ではベータ版機能になりますが、今回はこの「Advisor Checks v2」を使用して独自のチェッカー機能の実装までの流れをご紹介します。

なお、PMM2の構築手順につきましては以下のURLをご確認ください。

目次

Advisor Checks の概要

「Advisor Checks」は以下の流れでチェックを行います。

チェック結果はアラートとして画面上に表示されます。

「Advisor Checks」という名称からも、本機能はセキュリティやパラメータチューニング、バージョンごとの推奨アドバイスを行うための機能になります。

Client(Victria Metricsクライアント)へクエリを実行した結果から得られる内容であれば何にでもチェックをかけられますので、node_exporterが提供する実績値を元にアドバイスも可能です。

node_exporterが提供するメトリックは多岐に渡りますので、例えば以下のチェックが考えられます。

  • データベースを起動した時点で過剰にリソースを使っていないか
  • 非推奨のOSバージョンを使っていないか
  • 推奨のカーネルパラメータが設定されているか

というようなデータベース・ソフトウェアにとどまらないチェックも可能です。

これによって、PMM2の監視対象サーバとしてデータベースを登録するだけで、独自に定義した必須・推奨パラメータに沿っているかわかりやすくなります。
例えばそれほどDBに詳しくないエンジニアが構築したデータベースもPMM2をみればどこを修正すればよいか一目瞭然になります。

Percona Platformを使用した Advisor Checks の実行

ここで、Percona Platform についてもご紹介しておきます。

PMM2の開発ベンダであるPercona社では、PMM2と自社プラットフォーム(Percona Platform)を連携させて自社の顧客向けに付加価値のあるサービスを提供しています。

事前定義済みのAdovisor Checks機能は、無償のBasic planでも一部利用することが可能です。詳しくは以下のリストをご確認ください。

https://docs.percona.com/percona-platform/advisors.html#how-to-get-more-advisors

PMM2をPercona Platformに参加させるための手順は以下URLにまとまっています。

https://docs.percona.com/percona-monitoring-and-management/how-to/integrate-platform.html#integrate-pmm-with-percona-platform

ドキュメントの手順に従い、Percona Platformアカウントを登録し、PMM2をPercona platformに接続すると、「Advisor Checks」のメニューにチェック項目が追加されます。

あとは、表示されている interval に従い、チェックが実行されます。

無償プランでもかなりの数のチェックが行われますので、PMM2からインターネットが接続可能であれば、まずはPercona Platformを使用して機能を試してみるのもよいかと思います。

Advisor Checks の設定ファイル

Advisor Checks の設定ファイルはYAMLフォーマットになります。

設定ファイルの完全な例はドキュメントをご確認ください。

それほど難しい内容ではありませんが、主要な設定値としてはqueriesscripts になるでしょう。

queries は、PMMサーバからクライアントに実行する一連のクエリ定義です。
クエリ定義はtype フィールド、 query フィールドから構成され、typeフィールドは、query フィールドがどの種別のクエリかを定義します。
MySQLに観点を絞ると、以下が現在設定できます。

type 説明
MYSQL_SHOW SHOW GLOBAL から始まるクエリ
MYSQL_SELECT SELECT … から始まるMySQLクエリ
METRICS_INSTANT MetricsQL(※PromQL互換のVictriaMetrics用クエリ)でInstant Queryを使用する
METRICS_RANGE MetricsQL(※PromQL互換のVictriaMetrics用クエリ)でRange Queryを使用する

MySQLのメトリックは MYSQL... を、OSのメトリックは METRICS_... を基本的には使用することになるでしょう。
集約や加工はクエリでも可能ですが、クライアント側(クエリ)でやったほうがよいか、サーバ側(スクリプト)でやったほうがよいかはリソース負荷を見て判断することになります。

scriptqueries の結果を元にしたチェック処理です。
Starlark 言語というPython方言を使用してcheck_context()関数を定義することで機能を実装します。
check_context関数は、docscontext を引数に取り、内容は以下の通りです。

変数 内容
docs クエリの結果配列。queriesの並び順で各クエリの結果が格納される。
context ユーティリティ関数を含むディクショナリ。ここで定義されています。

コードは定型的で、

  1. docs に格納されている結果から目的のフィールド取得(もしくは加工)
  2. 1のフィールドを評価し、結果用リストに定型の結果用ディクショナリを格納

ということを繰り返し、最後に結果用リストを返すだけです。
以下に設定ファイル例の抜粋を記載します。

例では特にしきい値などの指定はなく常にバージョンなどの情報を画面に表示しているだけですが、評価結果に応じてアラートを追加する、しきい値によってラベルを変えるといったことも可能です。

Advisor Checksの実行間隔について

Advisor Checks は柔軟な機能ですので、例えば通常アラート機能で実装するような内容も設定できます(例えばロードアベレージがしきい値を超えた場合に通知など)。

しかしながら、Advisor Checks はあくまで推奨事項をアドバイスする機能のため高頻度で実行する事は想定されていません。

実行間隔を設定する intervalパラメータには、秒単位といった値を指定することはできず、現在指定できる間隔は以下の3つです。

  • Standard
  • Frequent
  • Rare

これらの実際の間隔は以下のコードで定義されています。

https://github.com/percona/pmm/blob/9486707d7401e18834e4e640e17ba31afb8c88a0/managed/models/settings.go#L176-L186

Starndard = 24時間ごと、 Rare = 78時間ごと、Frequent = 4時間ごとになりますので、ご注意ください。

なお、Advisor Checksは、ダッシュボード上の「Run Checks」ボタンを押下することでも実行されますので、追加したインスタンスに即座にチェックを行いたいといったことも可能です。

独自のアドバイザチェックの実装

それでは、独自のアドバイザチェックを実装してみたいと思います。

今回は以下の項目についてチェックを追加します。

  • InnoDBバッファプールは物理メモリサイズの60~70%である
  • GTIDを有効化している
  • レプリケーションスレーブは、super_read_onlyが設定されている

以下は設定例です。

ローカルのカスタムチェックを有効化するために、PMM Server側の環境変数を設定した上で起動します。

本環境は、Podmanを使用した非特権ユーザの起動手順で起動しましたので、以下のファイルに環境変数を設定し、サービスを再起動します。

設定ファイルをPERCONA_TEST_CHECKS_FILEのパスにコピーします。

再起動すると、「Advisor Checks」画面で設定したチェックが有効化されています。

事前に以下の環境を監視対象に登録しています。

  • mysql-test-1 (レプリケーションソースDB)
    • パラメータはデフォルト
  • mysql-test-2 (レプリケーションレプリカDB)
    • GTIDは有効化済み(gtid_mode=ON)
    • それ以外のパラメータはデフォルト

「Run Checks」ボタンですぐにチェックを実行してみましょう。

何回か画面を更新すると、「Failed Checks」タブにチェックが失敗したホストが表示されます。

mysql-test-1サーバの結果を表示すると、2つのチェックに失敗しています。
super_read_onlyは設定していませんが、レプリカサーバでは無いので、想定通りチェックはパスしています。

mysql-test-2サーバも2つのチェックに失敗しています。
GTIDを設定していますので、該当のチェックはパスしています。
レプリカであり、super_read_onlyを設定していませんのでチェックを通りませんでした。

まとめ

本機能を使用することで、これまでの経験を活かしたベストプラクティスを育てる仕組みを作ることができます。

チェックの実装もそれほど難しくはありませんので、現在でも実用的にすぐにでも使い始められる印象を受けました。

利用してみて以下が不満な点としてありました。

  • チェックをパスした項目も画面に表示するか、選択できるようにして欲しい
  • 内部エラーによってチェックの実行自体に失敗した場合も画面に表示してほしい
  • (機能自体の不満ではありませんが)Python3とStarlarkの微妙な差異に躓くことがある
  • Yaml上に直接クエリやStarlarkスクリプトを書くのではなくファイルをincludeする形式にするかPMMの画面上でそれらを直接登録するUIがほしい

特にStarlarkスクリプトが失敗した場合に/srv/logs/pmm-managed.logの大量の出力の中からエラー行を探すのが面倒と感じるポイントでしたので、デバッグがしやすくなる仕組みは欲しいと感じました。

PMM2の新機能の実装、UIの改善スピートは非常に早いため、これからGAになるまでの間によりブラッシュアップされることを期待しましょう!

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃オープンソースデータベースのサポート業務に従事している有資格者で構成された技術サポートチームがPerconaに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次