ClusterControlを使用したエージェントレスデータベースモニタリング

ホストとロードバランサーの統計収集の場合、ClusterControlはスーパーユーザー権限でSSH経由でこのタスクを実行します。したがって、ClusterControlが適切なエスカレーションを使用して必要なコマンドをリモートで実行できるようにするには、スーパーユーザー権限を持つパスワードなしのSSHが不可欠です。このプルアプローチには、他のメカニズムと比較していくつかの利点があります。

• エージェントレス–エージェントをインストール、構成、および保守する必要はありません。
• 管理と監視の構成の統合– SSHを使用して、監視メトリックをプルしたり、ターゲットノードで管理ジョブをプッシュしたりできます。
• 展開を簡素化する–唯一の要件は、パスワードなしの適切なSSHセットアップであり、それだけです。 SSHも非常に安全で暗号化されています。
• 一元化されたセットアップ–十分なリソースがあれば、1台のClusterControlサーバーで複数のサーバーとクラスターを管理できます。

ただし、プルメカニズムには次の欠点もあります。

• 監視データは、ClusterControlの観点からのみ正確です。たとえば、ネットワークの不具合があり、ClusterControlが監視対象のホストとの通信を失った場合、サンプリングは次の利用可能なサイクルまでスキップされます。
• ClusterControlがすべてのターゲットホストへのより多くの接続を確立する必要があるサンプリングレートの増加により、高粒度の監視のためのネットワークオーバーヘッドが発生します。
• ClusterControlは、ターゲットノードに代わってこれを行うエージェントがないため、ターゲットノードへの接続の再確立を試み続けます。
• 各ClusterControlサーバーがそれ自体の監視データをプルする必要があるため、クラスターを監視する複数のClusterControlサーバーがある場合の冗長データサンプリング。

ClusterControl 1.9.0（2021年7月にリリース）以降のMySQLクエリ監視では、ClusterControlは次の2つのタイプをサポートしています。

• エージェントレスクエリ監視（デフォルト）
• CMONクエリエージェントを使用したエージェントベースのクエリ監視。これを有効にするには追加の手順が必要です。 MySQLベースおよびPostgreSQLベースのデータベースのみ。

エージェントレスクエリ監視は、2つの異なる方法でクエリを監視します。

• クエリは、SSH経由でデータベースノードのスキーマをクエリすることにより、PERFORMANCE_SCHEMAから取得されます。
• PERFORMANCE_SCHEMAが無効または使用不可の場合、ClusterControlはSSH経由で低速クエリログのコンテンツを解析します。

パフォーマンススキーマが有効になっている場合、ClusterControlはそれを使用して低速のクエリを探します。それ以外の場合、ClusterControlは次のフローに基づいてMySQLの低速クエリログの内容を解析します（slow_query_log =ON動的変数を介して）：

1. 低速ログを開始します（MySQLランタイム中）。
2. 短時間（1秒または数秒）実行します。
ログを停止します。 解析ログ。
3. ログ（新しいログファイル）を切り捨てます。
4. 1に移動します。

収集されたクエリは、ハッシュ、計算、およびダイジェスト（正規化、平均化、カウント、並べ替え）されてから、ClusterControlCMONデータベースに格納されます。このサンプリング方法では、特に「ログの停止、ログの解析、ログの切り捨て」の部分で、一部のクエリがキャプチャされない可能性がわずかにあることに注意してください。これがオプションでない場合は、パフォーマンススキーマを有効にできます。

長いクエリ時間を超えるクエリのみが、遅いクエリログを使用してここに一覧表示されます。データが正しく入力されておらず、そこに何かがあるはずだと思われる場合は、次のいずれかである可能性があります。

• ClusterControlは、データを要約してデータを取り込むのに十分なクエリを収集しませんでした。長いクエリ時間を短縮してみてください。
• MySQLサーバーのmy.cnfでSlowQueryLog構成オプションを構成し、[ローカルクエリのオーバーライド]がオフになっています。 my.cnf内で定義した値を本当に使用したい場合は、ClusterControlがより正確な結果を計算できるように、おそらくlong_query_time値を下げる必要があります。
• 別のClusterControlノードがSlowQueryログもプルしています（スタンバイClusterControlサーバーがある場合）。 1台のClusterControlサーバーのみにこのジョブの実行を許可してください。

MySQL、MariaDB、およびPerconaサーバー用のClusterControlクエリモニターを使用することもできます。

PostgreSQLクエリ監視の場合、ClusterControlでは、すべてのSQLステートメントの実行統計を追跡するためにpg_stat_statementsモジュールが必要です。 UI（[クエリモニター]タブの下）にクエリを表示するときに、pg_stat_statementsビューと関数にデータを入力します。

間隔とタイムアウト

ClusterControl Controller（cmon）はマルチスレッドプロセスです。デフォルトでは、ClusterControl Controllerサンプリングスレッドは、監視対象の各ホストに1回接続し、ホスト統計をサンプリングするときにホストがドロップまたは切断するまで持続的接続を維持します。ほとんどの管理ジョブは独自のスレッドで実行されるため、ホストに割り当てられたジョブによっては、より多くの接続を確立する場合があります。たとえば、クラスターリカバリはリカバリスレッドで実行され、Advisorの実行はcronスレッドで実行され、プロセスモニタリングはプロセスコレクタスレッドで実行されます。

ClusterControl監視スレッドは、次の間隔で次のサンプリング操作を実行します。

• MySQLクエリ/ステータスメトリック：毎秒
• プロセス収集（/ proc）：10秒ごと
• サーバー検出：10秒ごと
• ホストメトリック（/ proc、/ sys）：30秒ごと（host_stats_collection_intervalを介して構成可能）
• データベースメトリック（PostgreSQLおよびMongoDBのみ）：30秒ごと（db_stats_collection_intervalを介して構成可能）
• データベーススキーマメトリック：3時間ごと（db_schema_stats_collection_intervalを介して構成可能）
• ロードバランサーの指標：15秒ごと（lb_stats_collection_intervalを介して構成可能）

命令型スクリプト（アドバイザ）は、CMONに付属するSSHおよびデータベースクライアントライブラリを利用できますが、次の制限があります。

• SSH実行の5秒のハード制限。
• データベース接続のデフォルト制限の10秒。CMON構成ファイルのnet_read_timeout、net_write_timeout、connect_timeoutを介して構成できます。
• CMONが正常に中止するまでの合計スクリプト実行時間制限の60秒。

アドバイザは、ClusterControlのUIから管理→Developer Studio で直接作成、コンパイル、テスト、およびスケジュールできます。 。次のスクリーンショットは、PERFORMANCE_SCHEMAから上位10個のクエリを抽出するためのアドバイザの例を示しています。

アドバイザーの実行は、アクティブ化されているかどうかとスケジュール時間によって異なります。 cron形式：

実行の結果は、パフォーマンス→アドバイザ<に表示されます。 / em> 、次のスクリーンショットに示すように：

デフォルトで提供されるアドバイザーの詳細については、デベロッパーをご覧ください。スタジオ製品ページ。

データは、MySQLクエリやステータスなどの短い間隔の監視データのためにCMONデータベースに直接保存されます。週次/月次/年次データポイントなどの長い間隔の監視データは、60秒ごとに集約され、10分間メモリに保存されます。これらの動作は、アーキテクチャ設計のために構成できません。

パラメータ

ClusterControlには、監視およびアラートポリシーに適合する多くのパラメータがあります。それらのほとんどは、ClusterControlUI→クラスターの選択→設定を介して構成できます。 。 [設定]タブには、アラート、しきい値、通知、グラフレイアウト、データベースカウンター、クエリの監視などを構成するための多くのオプションがあります。たとえば、警告とクリティカルのしきい値は次のように構成できます。

[ランタイム構成]ページには、アクティブなClusterControlコントローラーの要約リストが表示されます。 （CMON）ランタイム構成パラメーター：

合計で170を超えるClusterControlコントローラー構成オプションがあり、一部は詳細設定は、ポリシーの微調整を監視および警告するように構成できます。これらの一部は次のとおりです。

• monitor_cpu_temperature
• swap_warning
• swap_critical
• redobuffer_warning
• redobuffer_critical
• indexmemory_warning
• indexmemory_critical
• datamemory_warning
• datamemory_critical
• tablespace_warning
• tablespace_critical
• redolog_warning
• redolog_critical
• max_replication_lag
• long_query_time
• log_queries_not_using_indexes
• query_monitor_use_local_settings
• enable_query_monitor
• enable_query_monitor_auto_purge_ps

/etc/cmon.d/cmon_X.cnfにあるUIまたはCMON構成ファイル（XはクラスターID）を使用して、「ランタイム構成」ページにリストされているパラメーターを変更できます。次のコマンドを使用して、CMONでサポートされているすべての構成オプションを一覧表示できます。

$ cmon --help-config

最終的な考え

エージェントレス監視は、ますます複雑化するデータベースインフラストラクチャを管理するための最も効果的な方法の1つになっています。データベースの監視に関連する多くの課題の負担を軽減し、管理が容易です。

今日利用できるエージェントレス監視ツールはたくさんあります。ただし、データベースクラスターの他のすべての側面を管理するのに役立つ機能が満載の完全なプラットフォームを提供しているものは多くありません。 ClusterControlで他に何ができるかを確認するには、30日間の無料試用版をダウンロードしてください。

データベース監視に代わるエージェントベースの代替手段をお探しですか？ ClusterControlのエージェントベースのデータベース監視インフラストラクチャであるSCUMMを確認してください。