ClusterControl 1.7.0には、エージェントベースの監視のためのPrometheusとの統合という大胆な新機能が導入されています。これをSCUMM（Severalnines ClusterControl Unified Management and Monitoring）と呼びました。以前のバージョンでは、監視タスクはエージェントなしでのみ実行されていました。 ClusterControlが監視機能をどのように実行するか疑問に思われる場合は、このドキュメントページを確認してください。
MySQLプロトコルを理解する高性能リバースプロキシであるProxySQLは、通常、MySQLレプリケーションとGalera Clusterの上に配置され、バックエンドMySQLサービスへのゲートウェイとして機能します。クエリルーター、クエリファイアウォール、クエリキャッシング、トラフィックディスパッチャーなどとして構成できます。 ProxySQLは、STATSスキーマを介して主要なメトリックを収集および公開します。これは、パフォーマンスを分析し、舞台裏で実際に何が起こっているかを理解するのに非常に役立ちます。 ProxySQLの詳細については、ProxySQLの包括的なチュートリアルにアクセスしてください。
このブログ投稿では、この新しいアプローチを使用してProxySQLインスタンスを詳細に監視する方法について説明します。この例では、ClusterControlを介してデプロイされた2ノードのMySQLレプリケーション（1つのマスターと1つのスレーブ）の上にProxySQLインスタンスがあります。高レベルのアーキテクチャは次のようになります：
また、ProxySQLインスタンスで次のクエリルールが定義されています（参照用として、収集された監視メトリックをさらに下に理解するため）：
プロメテウスを有効にする
ClusterControlのエージェントベースの監視は、クラスターごとに有効になります。 ClusterControlは、新しいPrometheusサーバーをデプロイすることも、既存のPrometheusサーバー（他のクラスター用にClusterControlによってデプロイされる）を使用することもできます。 Prometheusを有効にするのは非常に簡単です。 ClusterControl->クラスターを選択->ダッシュボード->エージェントベースの監視を有効にする：
次に、新しいPrometheusサーバーのIPアドレスまたはホスト名を指定するか、ドロップダウンから既存のPrometheusホストを選択します。
ClusterControlは、必要なパッケージ（Prometheusサーバー上のPrometheus、データベース上のエクスポーター、およびProxySQLノード）をインストールおよび構成し、データソースとしてPrometheusに接続し、UIでの監視データの視覚化を開始します。
展開ジョブが完了すると、次のセクションに示すように[ダッシュボード]タブにアクセスできるようになります。
ProxySQLダッシュボード
[ダッシュボード]タブでそれぞれのクラスターに移動すると、ProxySQLダッシュボードにアクセスできます。 [ダッシュボード]ドロップダウンをクリックすると、クラスター（MySQLレプリケーション）に関連するダッシュボードが一覧表示されます。 ProxySQLの概要ダッシュボードは[ロードバランサー]セクションにあります：
ProxySQLにはいくつかのパネルがあり、それらのいくつかは自明です。それでも、1つずつ訪問していきましょう。
ホストグループのサイズ
ホストグループのサイズは、単にすべてのホストグループのホストの総数です：
この場合、10（ライター）と20（リーダー）の2つのホストグループがあります。ホストグループ10は1つのホスト（マスター）で構成され、ホストグループ20には2つのホスト（マスターとスレーブ）があり、合計で3つのホストになります。
ProxySQLからホストグループ構成を変更（新しいホストを導入し、既存のホストを削除）しない限り、このグラフでは何も変更されないことを期待する必要があります。
クライアント接続
すべてのホストグループについてProxySQLによって処理されているクライアント接続の数：
上記のグラフは、過去45分間にポート6033でProxySQLインスタンスに接続されたMySQLクライアントが一貫して8つあることを示しています（これは[範囲の選択]オプションで変更できます）。アプリケーションのProxySQLへの接続を停止する（またはバイパスする）と、値は最終的に0に低下します。
クライアントの質問
グラフは、すべてのホストグループについてProxySQLによって処理されている質問の数を視覚化します。
MySQLのドキュメントによると、質問は単にサーバーによって実行されたステートメントの数です。これには、Queries変数とは異なり、クライアントによってサーバーに送信されたステートメントのみが含まれ、ストアドプログラム内で実行されたステートメントは含まれません。この変数は、COM_PING、COM_STATISTICS、COM_STMT_PREPARE、COM_STMT_CLOSE、またはCOM_STMT_RESETコマンドをカウントしません。繰り返しになりますが、アプリケーションをProxySQLに接続するのをやめる（またはバイパスする）と、値は0に下がります。
アクティブなバックエンド接続
ProxySQLがホストごとにバックエンドMySQLサーバーに対して維持する接続の数：
これは、バックエンドサーバーにクエリを送信するためにProxySQLによって現在使用されている接続の数を示しているだけです。最大値が特定のサーバーの接続制限に近くない限り（ max_connections で設定） サーバーがProxySQLホストグループに追加されると、良好な状態になります。
失敗したバックエンド接続
ProxySQLによって正常に確立されなかった接続の数：
上記の例は、過去45分間にバックエンド接続の障害が発生しなかったことを示しています。
ルーティングされたクエリ
このグラフは、バックエンドサーバーへの着信ステートメントの分散に関する洞察を提供します。
ご覧のとおり、ほとんどの読み取りはリーダーホストグループ（HG20）に送信されます。ここから、この読み取り中心のワークロードでクエリルールに一致するProxySQLによって実行されるバランシングパターンを理解できます。
接続なし
グラフは、現在空いている接続の数を示しています：
バックエンドサーバーにクエリを送信する時間コストを最小限に抑えるために、接続は開いたままになります。
レイテンシ
ProxySQL監視スレッドから報告されたマイクロ秒単位の現在のping時間：
これは、ProxySQLからバックエンドMySQLサーバーへの接続がどれほど安定しているかを示しています。長い一貫した時間の高い値は、ほとんどの場合、それらの間のネットワークの問題を示しています。
クエリキャッシュメモリ
このグラフは、ProxySQLによってキャッシュされているクエリのメモリ消費量を視覚化したものです。
上のグラフから、ProxySQLがクエリキャッシュによって合計8MBのメモリを消費していることがわかります。 8MBの制限に達した後（ mysql-query_cache_size_MBを介して構成可能 変数）、メモリはProxySQLのパージスレッドによってパージされます。クエリキャッシュルールが定義されていない場合、このグラフは作成されません。
ちなみに、ProxySQLでのクエリのキャッシュは、ClusterControlを使用して2回クリックするだけで実行できます。 ProxySQLの[トップクエリ]ページに移動し、クエリをロールオーバーして、[クエリキャッシュ]をクリックし、[ルールの追加]をクリックします。
クエリキャッシュの効率
このグラフは、キャッシュされたクエリの効率を視覚化したものです：
青い線は、結果セットが存在し、有効期限が切れていないクエリキャッシュに対して実行されたGETリクエストの成功率を示しています。ピンクの線は、クエリキャッシュに書き込まれた（挿入された）データまたはクエリキャッシュから読み取られたデータの比率を示しています。この場合、クエリキャッシュから読み取られたデータは、書き込まれたデータよりも高く、効率的なキャッシュ構成を示しています。
クエリキャッシュルールが定義されていない場合、このグラフは作成されません。
ネットワークトラフィック
このグラフは、ホストごとに、バックエンドMySQLサーバーとの間のネットワークトラフィック（データ受信+送信データ）を視覚化します。
上のスクリーンショットは、かなりの量のトラフィックがリーダーホストグループ（HG20）との間で転送/受信されていることを示しています。この読み取り集約型のワークロードでは、読み取り操作は通常、主にSELECTステートメントの結果セットサイズが原因で、はるかに多くのトラフィックを消費します。
書き込みホストグループ（HG10）との間で転送/受信されるトラフィックの比率はごくわずかです。これは、通常、書き込み操作で消費されるネットワークトラフィックが少なく、結果セットがクライアントに返されることが非常に少ないためです。
ミラーリング効率
グラフは、Mirror_concurrencyとMirror_queue_lengthのようなトラフィックミラーリング関連のステータスを示しています：
グラフは、トラフィックミラーリング（ mirror_hostgroup ）を構成した場合にのみ入力されます クエリルール内）。ミラーキューが増加している場合、ミラーリングの同時実行制限を減らすと、ミラーリングの効率が向上します。これは、 mysql-mirror_max_concurrencyを介して制御できます。 変数。簡単に言うと、キューエントリがゼロであることが、最も効率的なミラーリングのすべてです。
メモリ使用率
グラフは、ProxySQL内の主要コンポーネント（接続プール、クエリキャッシュ、永続ストレージ（SQLite））によるメモリ使用率を示しています。
上のスクリーンショットは、ProxySQLのメモリフットプリントがかなり小さく、合計で12MB未満であることを示しています。接続プールは、8スレッド（クライアント）のワークロードに対応するために1.3MBのトップのみを消費します。ホストで利用可能なRAMの空き容量が増えると、ProxySQLへのクライアント接続の数を3倍から4倍に増やすか、ProxySQL内にさらに多くのホットクエリをキャッシュして、MySQLバックエンドサーバーの負荷を軽減できるはずです。
ボーナス機能-ノードパフォーマンス
ClusterControl 1.7.0には、ProxySQLインスタンスのホストパフォーマンスメトリックが含まれるようになりました。以前のバージョンでは、ClusterControlは、ProxySQL統計スキーマによって公開されたProxySQL関連のメトリックのみを監視していました。この新機能には、[ノード]タブ->[ProxySQLインスタンス]->[ノードパフォーマンス]からアクセスできます：
ヒストグラムは、[ノード]-> [概要]セクションでデータベースノードに対してサンプリングされているものと同様に、主要なホストメトリックへの洞察を提供します。 ProxySQLインスタンスがアプリケーションと同じサーバーに同じ場所に配置されている場合は、文字通りClusterControlを使用してアプリケーションサーバーも監視しています。なんてクールなの？！
最終的な考え
ClusterControlとPrometheusの統合は、リバースプロキシ層までのデータベーススタックを監視および分析するための代替方法を提供します。これで、監視ジョブをPrometheusにオフロードするか、データベースインフラストラクチャにデフォルトのClusterControlエージェントレス監視アプローチを引き続き使用するかを選択できます。