Azure Database for MySQL - フレキシブル サーバーを監視する
Note
この記事には、Microsoft が使用しなくなった "スレーブ" という用語への言及が含まれています。 ソフトウェアからこの用語が削除された時点で、この記事から削除します。
Azure Database for MySQL フレキシブル サーバーでは、Azure Monitor を通してサーバーを監視できます。 サーバーに関する監視データは、ワークロードをトラブルシューティングしたり最適化したりするのに役立ちます。
この記事では、フレキシブル サーバーの動作に関する情報の分析に使用できるさまざまなメトリックとサーバー ログについて説明します。
メトリック
メトリックは、特定の時点におけるサーバーのリソースの何らかの側面を表す数値です。 サーバーのリソースを監視すると、ユーザーにとって最も重要なものを監視できるため、ワークロードのトラブルシューティングと最適化に役立ちます。 適切なメトリックの監視は、サーバーとアプリケーションのパフォーマンス、信頼性、可用性を維持するのに役立ちます。
Azure Database for MySQL フレキシブル サーバーには、ワークロードのパフォーマンスを把握するのに役立つさまざまなメトリックが用意されています。 このデータから、サーバーとアプリケーションへの影響を理解できます。
すべての Azure メトリックは 1 分間隔で、各メトリックの 30 日間の履歴が保持されます。 メトリックにアラートを構成できます。 「Azure Database for MySQL - フレキシブル サーバーのメトリックのアラートを設定する」を参照してください。 その他のタスクとして、自動化されたアクションの設定、高度な分析の実行、履歴のアーカイブなどがあります。 詳細については、Azure のメトリックの概要に関する記事をご覧ください。
メトリックのトラブルシューティング
Azure メトリックス エクスプローラーでのグラフの作成、カスタマイズ、または解釈に関する問題が発生することがあります。
さまざまな要因が原因でグラフにデータが表示されない場合があります。 これには、サブスクリプションに登録されていない Microsoft Insights リソース プロバイダーや、Azure Database for MySQL - フレキシブル サーバーへの適切なアクセス権がない場合が含まれます。 その他の可能性としては、選択した期間内にリソースがメトリックを生成しなかったか、選択した時間範囲が 30 日を超えている可能性があります。
この動作は、次のようないくつかの理由で発生する可能性があります:
- Microsoft.Insights リソース プロバイダーが登録されていない: メトリックを探索するには、サブスクリプションに登録されている Microsoft.Insights リソース プロバイダーが必要です。 「Azure リソース プロバイダーと種類」で説明されている手順に従って、サーバーを手動で登録します。
- リソースへのアクセス権が不十分: メトリックを探索する Azure Database for MySQL - フレキシブル サーバーに対する十分なアクセス許可があることを確認します。 選択した時間範囲の間にリソースがメトリックを生成しなかった グラフの時間をより広い範囲に変更します。 Azure で、Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、メトリックへのアクセスを管理します。 リソースのメトリックを調べるには、監視閲覧者、監視共同作成者、または共同作成者のメンバーである必要があります。
- 選択した時間範囲でリソースがメトリックを出力しませんでした: これは、いくつかの理由が原因である可能性があります。 1 つの可能性は、選択した期間内にリソースによってメトリックが生成されなかった場合です。 グラフの時間をより広い範囲に変更して、これが問題を解決するかどうかを確認してください。 この問題のトラブルシューティングの詳細については、Azure Monitor メトリックの「トラブルシューティング ガイド」を参照してください。
- 時間範囲が 30 日を超えています: タイム ピッカーの開始日と終了日の差が 30 日の間隔を超えていないことを確認します。 トラブルシューティング メトリックの詳細については、｢Azure Monitor メトリックのトラブルシューティング ガイド」を参照してください。
- 破線表示: Azure Monitor では、破線は既知の時間粒度データの 2 つのポイント間のデータのギャップまたは "null 値" を示します。 これは、不足しているデータ ポイントの検出に役立つ意図的な設計です。 グラフに破線が表示されている場合は、データが不足していることが示されます。 詳細についてはドキュメントを参照してください。
トラブルシューティング メトリックの詳細については、｢Azure Monitor メトリックのトラブルシューティング ガイド」を参照してください。
Note
非推奨としてマークされているメトリックは、Azure portal から削除される予定です。 Azure Database for MySQL フレキシブル サーバーを監視するには、これらのメトリックを無視する必要があります。
メトリックの一覧
以下のメトリックを Azure Database for MySQL フレキシブル サーバーに使用できます。
| メトリックの表示名 | メトリック | ユニット | 説明 |
|---|---|---|---|
| MySQL アップタイム | uptime | 秒 | このメトリックは、MySQL サーバーが実行されている時間の長さを示します。 |
| ホストの CPU 使用率 | cpu_percent | Percent | ホストの CPU 使用率は、選択した期間にサーバー上のすべてのタスクを処理するための CPU の合計使用率です。 このメトリックには、Azure Database for MySQL フレキシブル サーバー インスタンスと Azure MySQL プロセスのワークロードが含まれます。 CPU 使用率が高い状態は、データベース サーバーに処理能力を超えるワークロードがあるかどうかを確認するのに役立ちます。 このメトリックは、合計 CPU 使用率を表し、仮想マシンの CPU 使用率と同様です。 |
| 使用された CPU クレジット | cpu_credits_consumed | カウント | これはバースト可能なレベル専用です CPU クレジットは、ワークロードに基づいて計算されます。 詳しくは、「負荷の急増に対応できる B シリーズ仮想マシンのサイズ」をご覧ください。 |
| 残りの CPU クレジット | cpu_credits_remaining | カウント | これはバースト可能なレベル専用です 残りの CPU は、ワークロードに基づいて計算されます。 詳しくは、「負荷の急増に対応できる B シリーズ仮想マシンのサイズ」をご覧ください。 |
| ホストのネットワーク受信 | network_bytes_ingress | バイト | 選択した期間のサーバー上の受信ネットワーク トラフィックの合計。 このメトリックには、データベースと Azure Database for MySQL フレキシブル サーバー機能 (監視、ログなど) へのトラフィックが含まれます。 |
| ホストのネットワーク送信 | network_bytes_egress | バイト | 選択した期間のサーバー上の送信ネットワーク トラフィックの合計。 このメトリックには、データベースと Azure Database for MySQL フレキシブル サーバー機能 (監視、ログなど) からのトラフィックが含まれます。 |
| アクティブな接続 | active_connection | Count | サーバーへのアクティブな接続の数 アクティブな接続は、サーバーに接続されているスレッドの合計数です。azure_superuser からのスレッドも含まれます。 |
| Storage IO percent (ストレージ IO の割合) | io_consumption_percent | パーセント | 選択した期間に使用された IO の割合。 IO の割合は、読み取りと書き込みの両方の IOPS が対象です。 |
| ストレージ IO 数 | storage_io_countstorage_io_count | カウント | サーバーが 1 分あたりの I/O 操作 (読み取りと書き込みの両方) の合計数。 |
| メモリの割合 | memory_percent | Percent | このメトリックは、Azure MySQL (mysqld) サーバー プロセスによって占有されているメモリの割合を表します。 このメトリックは、Azure Database for MySQL フレキシブル サーバーで使用可能な合計メモリ サイズ (GB) から計算されます。 |
| 合計接続数 | total_connections | カウント | Azure Database for MySQL フレキシブル サーバー インスタンスへのクライアント接続の数。 合計接続数は、選択した期間の TCP/IP プロトコルを使用したクライアント接続の合計です。 |
| 中止された接続 | aborted_connections | カウント | 資格情報が正しくないために失敗した接続など、Azure Database for MySQL フレキシブル サーバー インスタンスへの接続に失敗した試行の合計数。 中止された接続の詳細については、このドキュメントを参照してください。 |
| クエリ | Query | Count | サーバーで 1 分間に実行されたクエリの合計数。 データベース ワークロードと Azure MySQL プロセスからの、サーバー上の 1 分間のクエリの合計数です。 |
| Slow_queries | slow_queries | Count | 選択した時間範囲内のサーバーでの低速クエリの合計数。 |
| Active Transactions | active_transactions | カウント | このメトリックは、MySQL 内のトランザクションの合計数を表します。 アクティブなトランザクションには、開始されたが、まだコミットまたはロールバックされていないすべてのトランザクションが含まれます。 |
ストレージの内訳メトリック
ストレージの内訳メトリックは、Azure Database for MySQL フレキシブル サーバーのストレージ使用状況に関する貴重な分析情報を提供します。 これらのメトリックにより、ストレージ容量、ストレージ使用率、ストレージ使用量、データストレージ使用量、ibdata1 ストレージ使用量、binlog ストレージ使用量、その他のストレージ使用量、およびバックアップストレージ使用量の詳しい内訳が表示されます。 これらのメトリックを監視することで、ストレージ リソースを効果的に管理し、ストレージの割り当てを最適化し、サーバーのストレージ容量を効率的に使用できます。 ストレージの内訳メトリックを理解すると、Azure Database for MySQL フレキシブル サーバーのパフォーマンスと可用性を維持するための十分な情報に基づいた意思決定を行うことができます。
次の表には、Azure Database for MySQL フレキシブル サーバーで使用できるストレージの内訳に関するメトリックの一覧が示されています。
| メトリックの表示名 | メトリック | ユニット | 説明 |
|---|---|---|---|
| ストレージの制限 | storage_limit | バイト | このサーバー用に構成された最大ストレージ サイズ。 |
| ストレージの割合 | storage_percent | パーセント | サーバーの上限のうち、使用済みのストレージの割合。 |
| 使用されているストレージ | storage_used | バイト | 使用されているストレージの量。 サービスで使用されるストレージには、データベース ファイル、トランザクション ログ、サーバー ログが含まれることがあります。 |
| 使用されているデータ ストレージ | data_storage_used | バイト | データベース ファイルの格納に使用されているストレージの量。 |
| ibdata1 Storage Used | ibdata1_storage_used | バイト | システム テーブルスペース (ibdata1) ファイルの格納に使用されているストレージの量。 |
| Binlog Storage Used | binlog_storage_used | バイト | バイナリ ログ ファイルの格納に使用されているストレージの量。 |
| 使用されているその他のストレージ | other_storage_used | バイト | 他のコンポーネントとメタデータ ファイルに使用されているストレージの量。 |
| 使用済みバックアップ ストレージ | backup_storage_used | バイト | 使用されているバックアップ ストレージの量。 |
レプリケーションのメトリック
レプリケーション メトリックは、Azure Database for MySQL フレキシブル サーバーのレプリケーションのパフォーマンスと状態に関する貴重な分析情報を提供します。 これらのメトリックを使用すると、レプリケーションの遅延を監視し、レプリカと HA IO/SQL スレッドの状態を確認し、レプリケーションの待機時間を測定できます。 これらのメトリックを追跡することで、レプリケーションのセットアップの信頼性と効率を確保し、潜在的な問題や遅延を特定し、データの整合性と可用性を維持するための適切なアクションを実行できます。 Azure Database for MySQL フレキシブル サーバーで使用できるさまざまなレプリケーション メトリックについて詳しく見ていきましょう。
次の表に、Azure Database for MySQL フレキシブル サーバーで使用できるレプリケーション メトリックを示します。
| メトリックの表示名 | メトリック | ユニット | 説明 |
|---|---|---|---|
| レプリケーションのラグ | replication_lag | 秒 | レプリケーションの遅延は、レプリカでソース サーバーから受信したトランザクションを再生する際にレプリカが遅れる秒数です。 このメトリックは、"SHOW SLAVE STATUS" コマンドの "Seconds_behind_Master" から計算され、レプリカ サーバーでのみ使用できます。 詳細については、「Azure Database for MySQL - フレキシブル サーバーのレプリケーション待機時間のトラブルシューティング」を参照してください |
| レプリカ IO の状態 | replica_io_running | State | レプリカ IO の状態は、レプリケーション I/O スレッドの状態を示します。 メトリック値は、I/O スレッドが実行されている場合は 1、実行されていない場合は 0 です。 |
| レプリカ SQL の状態 | replica_sql_running | State | レプリカ SQL の状態は、レプリケーション SQL スレッドの状態を示します。 メトリック値は、SQL スレッドが実行されている場合は 1、実行されていない場合は 0 です。 |
| HA IO の状態 | ha_io_running | 都道府県 | HA IO 状態は、「Azure Database for MySQL - フレキシブル サーバーの高可用性の概念」における状態を示します。 メトリック値は、I/O スレッドが実行されている場合は 1、実行されていない場合は 0 です。 |
| HA SQL の状態 | ha_sql_running | 都道府県 | HA SQL の状態は、「Azure Database for MySQL - フレキシブル サーバーの高可用性の概念」における状態を示します。 メトリック値は、SQL スレッドが実行されている場合は 1、実行されていない場合は 0 です。 |
| HA Replication Lag (HA レプリケーションのラグ) | ha_replication_lag | 秒 | HA レプリケーションのラグは、HA スタンバイ サーバーでソース サーバーから受信したトランザクションの再生が遅延している秒数です。 このメトリックは、"SHOW SLAVE STATUS" コマンドの "Seconds_behind_Master" から計算され、HA スタンバイ サーバーでのみ使用できます。 |
拡張メトリック
Azure Database for MySQL フレキシブル サーバーによって提供される標準メトリックに加えて、強化されたメトリックを使用して、サーバーのパフォーマンスに関する詳細な分析情報を得ることができます。 これらの強化されたメトリックは、ワークロードの特定の側面に関するより詳細な情報を提供します。
DML 統計
DML (データ操作言語) 統計メトリックを使用すると、サーバー上で実行された SELECT、UPDATE、INSERT、DELETE ステートメントの数を可視化できます。 これらのメトリックを監視することで、データベース操作の使用状況とパフォーマンスを追跡し、潜在的なボトルネックや非効率性を特定できます。
| メトリックの表示名 | メトリック | ユニット | 説明 |
|---|---|---|---|
| Com_select | Com_select | カウント | 選択した時間範囲内にサーバーで実行された SELECT ステートメントの合計数。 |
| Com_update | Com_update | カウント | 選択した時間範囲内にサーバーで実行された UPDATE ステートメントの合計数。 |
| Com_insert | Com_insert | カウント | 選択した時間範囲内にサーバーで実行された INSERT ステートメントの合計数。 |
| Com_delete | Com_delete | カウント | 選択した時間範囲内にサーバーで実行された DELETE ステートメントの合計数。 |
DDL 統計
DDL (データ定義言語) 統計メトリックは、サーバーで実行されるデータベースの作成、データベースの削除、テーブルの作成、テーブルの削除、およびテーブル ステートメントの変更を実行できる頻度に関する情報を提供します。 これらのメトリックは、データベースのスキーマ変更の頻度と影響を把握するのに役立ちます。これにより、データベースの設計を最適化し、全体的なパフォーマンスを向上させることができます。
| メトリックの表示名 | メトリック | ユニット | 説明 |
|---|---|---|---|
| Com_create_db | Com_create_db | カウント | 選択した時間範囲内にサーバーで実行された CREATE DATABASE ステートメントの合計数。 |
| Com_drop_db | Com_drop_db | カウント | 選択した時間範囲内にサーバーで実行された DROP DATABASE ステートメントの合計数。 |
| Com_create_table | Com_create_table | カウント | 選択した時間範囲内にサーバーで実行された CREATE TABLE ステートメントの合計数。 |
| Com_drop_table | Com_drop_table | カウント | 選択した時間範囲内にサーバーで実行された DROP TABLE ステートメントの合計数。 |
| Com_Alter | Com_Alter | カウント | 選択した時間範囲内にサーバーで実行された ALTER TABLE ステートメントの合計数。 |
InnoDB メトリック
Innodb メトリックは、Azure Database for MySQL フレキシブル サーバーの既定のエンジンである InnoDB ストレージ エンジンのパフォーマンスを計測します。 これらのメトリックには、InnoDB 行ロック時間、InnoDB 行ロック待機、Innodb バッファー プールの読み取り、Innodb バッファー プールの読み取り要求などが含まれます。 これらのメトリックを監視することで、データベースのストレージとキャッシュメカニズムの効率と有効性に関する分析情報を得ることができます。
これらの強化されたメトリックは、ワークロードを最適化し、Azure Database for MySQL フレキシブル サーバーのパフォーマンスを向上させるために役立つ情報を提供します。 これらのメトリックを使用すると、データに基づいた意思決定を行い、データベース操作のスケーラビリティ、信頼性、効率性を向上させることができます。
| メトリックの表示名 | メトリック | ユニット | 説明 |
|---|---|---|---|
| InnoDB 行ロック時間 | innodb_row_lock_time | Milliseconds | InnoDB 行ロック時間は、InnoDB 行レベルのロックの時間をミリ秒単位で測定します。 |
| InnoDB 行ロック待機 | innodb_row_lock_waits | カウント | InnoDB 行ロック待機メトリックは、クエリが InnoDB 行レベルのロックを待機する必要があった回数をカウントします。 |
| Innodb_buffer_pool_reads | Innodb_buffer_pool_reads | カウント | InnoDB エンジンが InnoDB バッファー プールから満たすことができず、ディスクから取り込む必要があった論理読み取りの合計数。 |
| Innodb_buffer_pool_read_requests | Innodb_buffer_pool_read_requests | Count | InnoDB バッファー プールから読み取る論理読み取り要求の合計数。 |
| Innodb_buffer_pool_pages_free | Innodb_buffer_pool_pages_free | カウント | InnoDB バッファー プール内の空きページの合計数。 |
| Innodb_buffer_pool_pages_data | Innodb_buffer_pool_pages_data | Count | InnoDB バッファー プール内のデータを含むページの合計数。 この数字には、ダーティとクリーンの両ページが含まれます。 |
| Innodb_buffer_pool_pages_dirty | Innodb_buffer_pool_pages_dirty | Count | InnoDB バッファー プール内のダーティ ページを含むページの合計数。 |
| MySQL 履歴リストの長さ | trx_rseg_history_len | カウント | このメトリックは、データベース内の変更の回数、特に以前の変更を含むレコードの数を計算します。 これは、新しい行バージョンが作成される原因となるデータの変化率に関連しています。 履歴リストが長くなると、データベースのパフォーマンスに影響する可能性があります。 |
| MySQL のロック タイムアウト | lock_timeouts | カウント | このメトリックは、ロックが原因でクエリがタイムアウトした回数を表します。 これは通常、別のクエリによって保持されている行またはテーブルのロックが、innodb_lock_wait_timeout 設定よりも長い時間待機している場合に発生します。 |
| MySQL のロックのデッドロック | lock_deadlock | カウント | このメトリックは、選択した期間に Azure Database for MySQL フレキシブル サーバー インスタンスで発生したデッドロックの回数を表します。 |
サーバー ログ
Azure Database for MySQL フレキシブル サーバーでは、ユーザーはサーバー ログを構成し、ダウンロードして、トラブルシューティング作業に役立てることができます。 この機能を有効にすると、Azure Database for MySQL フレキシブル サーバー インスタンスは、選択したログの種類のイベントの取り込みを開始し、ファイルに書き込みます。 これにより、ユーザーは Azure portal と Azure CLI を使ってファイルをダウンロードし、それらを操作できるようになります。 サーバー ログ機能は、既定では無効です。 サーバー ログを有効にする方法については、「Azure Database for MySQL フレキシブル サーバーのサーバー ログを有効にしてダウンロードする」を参照してください
サーバー ログでは、低速クエリ ログとエラー ログの有効化とダウンロードすることができます。 データの履歴分析を行うには、Azure portal のサーバーの [診断設定] ペインでログを Log Analytics ワークスペース、Azure Storage、またはイベント ハブに送信するための診断設定を追加します。 詳細については、診断の設定に関する記事を参照してください。
サーバー ログのリテンション期間
Azure Database for MySQL フレキシブル サーバー インスタンスのログが有効な場合、ログは作成から最長 7 日間使用できます。 使用可能なログの合計サイズが 7 GB を超える場合は、空き領域を利用できるようになるまで、古いファイルから削除されます。 サーバー ログの 7 GB のストレージ上限は、コストなしで使用可能であり、拡張することはできません。 ログのローテーションは、24 時間ごとか 500 MB ごとのどちらか早い方のタイミングで行われます。