AnalyticDB:モニタリング

よくある質問の概要

• Data Warehouse Edition のリザーブドモードのクラスターでディスク使用率をモニタリングする方法

• ホットデータとコールドデータが消費するストレージ領域を確認する方法

• テーブルサイズなどの情報を確認する方法

• [モニタリング情報] ページで、ホットデータの使用量が合計ディスク使用量よりも高いのはなぜですか？

• クラスターをリザーブドモードからエラスティックモードに変更した後、平均 CPU 使用率が増加するのはなぜですか？

• [モニタリング情報] ページではクエリ応答時間が長いのに、[診断と最適化] ページに対応する長時間実行 SQL ステートメントが表示されないのはなぜですか？

リザーブドモードでのディスク使用率のモニタリング

ディスク使用率が安全なしきい値を超えないように、モニタリングとアラートを設定します。これにより、通知をタイムリーに受信してディスク領域を管理し、サービスの安定性を維持できます。

1. AnalyticDB for MySQL コンソールにログインします。コンソールの左上隅でリージョンを選択します。左側のナビゲーションウィンドウで クラスターリスト をクリックします。管理するクラスターを見つけ、クラスター ID をクリックします。

2. 左側のナビゲーションウィンドウで、モニタリングとアラーム をクリックします。

3. [監視情報] ページで、[クエリと書き込み] タブをクリックしてディスク使用率を表示します。

   リザーブドモードでは、ディスク使用率はパーセンテージで表示されます。エラスティックモードでは、読み取り/書き込みノードの絶対ディスク使用量が表示されます。

   • リザーブドモード

     説明

     最大ディスク使用率は、クラスター内のすべてのノードの中で最も高いディスク使用率です。この値が 90% 以上に達すると、書き込み操作がロックされます。このメトリックには特に注意してください。

   • エラスティックモード

     説明

     ディスク使用率とは、単一の読み取り/書き込みノードの最大ディスク使用率を指します。この値が 8 TB 以上に達すると、クラスターにデータを書き込むことができなくなります。このメトリックには特に注意してください。

4. [監視情報] ページで、アラームルール設定 をクリックします。

5. [アラームルール] ページで、アラートルールの作成 をクリックします。

6. [アラームの作成] ページで、パラメーターを設定します。

   パラメーター	説明
   リソース範囲	アラートルールの範囲。有効な値は次のとおりです。 すべてのリソース：このオプションは、アカウント内のプロダクトのすべてのインスタンスにルールを適用します。たとえば、AnalyticDB for MySQL のディスク使用率が 80% 以上になったときにアラートがトリガーされるように設定した場合、このルールはすべての AnalyticDB for MySQL インスタンスに適用されます。リソース範囲 が すべてのリソース に設定されている場合、アラートは最大 1,000 リソースに対してトリガーされます。リソース数が 1,000 を超える場合、しきい値に達してもアラートがトリガーされないことがあります。アラートを設定する前に、アプリケーショングループを使用してビジネスごとにリソースをグループ化することを推奨します。 アプリケーショングループ：アラートルールは、プロダクトの指定されたアプリケーショングループ内のすべてのリソースに適用されます。 インスタンス：ルールは、プロダクトの特定のインスタンスにのみ適用されます。たとえば、ディスク使用率が 80% 以上というインスタンスレベルのアラートを設定した場合、その特定のインスタンスのディスク使用率がしきい値以上になると通知が送信されます。
   ルール説明	アラートをトリガーする条件。ルール説明を設定するには： Add Rule をクリックします。 ルールの説明を追加 パネルで、ルール名、Metric Type、Monitoring Metric、しきい値とアラームレベル、チャートプレビュー などのパラメーターを設定します。 OK をクリックします。
   チャネルサイレンス	未解決のアラートに対して繰り返し通知が送信される間隔。有効な値：5 分、15 分、30 分、60 分、3 時間、6 時間、12 時間、24 時間。メトリックがアラートのしきい値に達すると、アラートが送信されます。ミュート期間中にメトリックがしきい値を超え続けても、繰り返し通知は送信されません。ミュート期間が終了しても状態が解決されない場合、CloudMonitor は別のアラート通知を送信します。
   適用時刻	アラートルールがアクティブになる期間。 重要 ディスク使用率のアラートの場合、各アラート連絡先には 1 日に最大 4 回通知されます。それ以降のアラートはサイレンスされます。
   アラーム連絡先グループ	アラート通知を受信する連絡先グループ。 アプリケーショングループの通知は、このアラートグループ内の連絡先に送信されます。アラートグループには、1 つ以上のアラート連絡先を含めることができます。アラート連絡先とアラートグループの作成方法については、「アラート連絡先またはアラートグループの作成」をご参照ください。
   アラームコールバック	パブリックにアクセス可能な URL。CloudMonitor は、POST リクエストを介してこの URL にアラート情報をプッシュします。HTTP プロトコルのみがサポートされています。アラートコールバックの設定方法については、「しきい値ベースのアラートコールバックの使用」をご参照ください。 説明 このパラメーターを設定するには、詳細設定 をクリックします。
   Auto Scaling	Auto Scaling を有効にすると、アラート発生時に対応するスケーリングルールがトリガーされます。Auto Scaling の リージョン、スケーリンググループ、スケーリングルール を指定する必要があります。 スケーリンググループの作成方法については、「スケーリンググループの設定」をご参照ください。 スケーリングルールの作成方法については、「スケーリングルールの設定」をご参照ください。 説明 このパラメーターを設定するには、詳細設定 をクリックします。
   Simple Log Service	Simple Log Service を有効にすると、アラート発生時にアラート情報が Log Service に書き込まれます。Log Service の リージョン、Project、Logstore を指定する必要があります。 プロジェクトと Logstore の作成方法については、「LoongCollector を使用した ECS テキストログの収集と分析」をご参照ください。 説明 このパラメーターを設定するには、詳細設定 をクリックします。
   Simple Massage Queue (旧 MNS)（SMQ） - トピック	Simple Massage Queue (旧 MNS)（SMQ） - トピック を有効にすると、アラート情報が Message Service の指定されたトピックに送信されます。Message Service のリージョンとトピックを指定する必要があります。 トピックの作成方法については、「トピックの作成」をご参照ください。
   [モニタリングデータがない場合のアラート処理方法]	アラートルールでモニタリングデータが利用できない場合に実行するアクション。有効な値は次のとおりです。 何もしないでください (デフォルト) データアラームを送信しない [回復済みと見なす] 説明 このパラメーターを設定するには、詳細設定 をクリックします。
   タグ	アラートコンテンツにカスタムのキーと値のペアをタグとして追加します。

7. パラメーターを設定したら、OK をクリックします。

ホットデータとコールドデータのストレージの表示

AnalyticDB for MySQL コンソールにログインします。[監視情報] ページで、ホットデータ使用量 と コールドデータ使用量 を表示できます。

テーブルサイズの確認

AnalyticDB for MySQLコンソールにログインします。クラスターの [監視情報] ページで、テーブル情報統計 タブをクリックして、テーブルサイズなどの情報を表示します。

ホットデータの使用量と合計ディスク使用量の比較

AnalyticDB for MySQL クラスターには、複数のストレージノードが含まれています。ディスク使用率は、単一の読み取り/書き込みノードの最大ディスク使用率を表しますが、ホットデータの使用量は、すべての読み取り/書き込みノードのディスク使用量の合計です。

エラスティックモードでの CPU 使用率の増加

C32 クラスターをリザーブドモードからエラスティックモードに変更すると、シングルノードのコア数は 8 に減少します。デフォルトでは、BUILD タスクが 3 コアを占有するため、平均 CPU 使用率が増加します。この増加がサービスに影響しない場合は、何もする必要はありません。サービスに影響がある場合は、クラスターをスケールアップするか、チケットを起票してテクニカルサポートにお問い合わせください。BUILD タスクの詳細については、「BUILD」をご参照ください。

クエリ応答時間の差異

[モニタリング情報] ページのクエリ応答時間と [診断と最適化] ページの合計所要時間は、計算方法が異なります。[モニタリング情報] ページのクエリ応答時間には、結果セットのキャッシュ時間も含まれます。したがって、クエリがキャッシュを必要とする大きな結果セットを返す場合、[モニタリング情報] ページのクエリ応答時間は、[診断と最適化] ページに表示される合計所要時間よりも長くなります。[SQL 監査] ページを使用して、応答時間が長い SQL ステートメントを見つけることができます。

以下に、SQL ステートメントが消費する時間の計算方法について説明します。

SQL ステートメントが AnalyticDB for MySQL に送信されると、まずキューに配置されます。クエリの同時実行数が高い場合、キューイング時間が長くなる可能性があります。キューを抜けた後、ステートメントは実行エンジンに入り、そこでクエリが解析されて実行計画が生成されます。このプロセスが実行計画時間となります。実行計画が生成された後、サブタスクがストレージノードとコンピュートノードで実行され、これが実行時間となります。クエリが完了した後、結果セットが大きい場合、フロントエンドノードが結果をキャッシュします。これが結果セットのキャッシュ時間となります。次の図は、SQL ステートメントの時間の内訳を示しています。