Share via

パフォーマンス データを収集するための推奨事項

  • [アーティクル]

この Azure Well-Architected Framework パフォーマンス効率チェックリストの推奨事項に適用されます。

PE:04 パフォーマンス データを収集します。 ワークロード コンポーネントとフローでは、自動で継続的かつ意味のあるメトリックとログを提供する必要があります。 アプリケーション、プラットフォーム、データ、オペレーティング システムの各レベルなど、ワークロードのさまざまなレベルでデータを収集します。

パフォーマンス データの収集は、ワークロードのパフォーマンスに関する情報を提供するメトリックとログを収集するプロセスです。 このデータには、メトリックと呼ばれる数値が含 まれます。 メトリックは、特定の時点でのシステムの状態を表します。 また、レコードに編成されたさまざまな種類のデータを含むログも含まれます。

パフォーマンス データを収集することで、ワークロードのパフォーマンスを監視および分析できます。 この情報を使用して、パフォーマンスのボトルネックを特定し、問題のトラブルシューティングを行い、リソースの割り当てを最適化し、ワークロードの全体的なパフォーマンス効率を向上させるためのデータドリブンの決定を行うことができます。

データドリブンの分析情報がないと、基になるパフォーマンスの問題や最適化の機会を認識できない可能性があります。 潜在的な結果には、応答時間の短縮、スループットの低下、リソース使用量の増加、最終的には最適ではないユーザー エクスペリエンスが含まれます。 さらに、パフォーマンス データが不足しているため、問題の診断とトラブルシューティングをタイムリーに行うのが困難になり、ダウンタイムが長くなり、生産性が低下します。

定義

期間 定義
アクティビティ ログ リソースの削除など、リソースに対する管理操作を追跡するログ。
アプリケーション ログ アプリケーション イベント、エラー、およびその他のアクティビティ (サインインやデータベース接続エラーの使用など) に関する情報を追跡するログ。
アプリケーション パフォーマンス監視 (APM) ツール アプリケーションのパフォーマンスを監視およびレポートするツール。
コード インストルメンテーション アプリケーション コードの観点からのパフォーマンス メトリックの直接的または間接的なキャプチャ。 キャプチャされたメトリックには、フロー メトリック、リソースの使用、言語またはランタイムに固有のメトリックが含まれます。
分散トレース 分散ワークロード コンポーネント間でのメトリックの収集と関連付け。
メトリック シンク 分析のために時系列データを関連付けるメトリックのストレージの宛先。
プラットフォーム ログ リソース ログ、アクティビティ ログ、監査ログを含む診断および監査データ。
プラットフォームのメトリック 特定の時刻にワークロードのパフォーマンスを記録する数値。
リソース ログ システムによって生成されるデータ。 システムの状態に関する情報を提供します。
Rx/Tx エラー ネットワーク インターフェイスでの受信エラーと送信エラーの数。
構造化ログ メッセージをログに記録するための意味のある形式を定義する (通常はキーと値のペア)。

主要な設計戦略

パフォーマンスの最適化では、ワークロードまたはフローの現在のパフォーマンスをそのパフォーマンス目標に対して測定するためにデータが必要です。 コードとインフラストラクチャのパフォーマンスを パフォーマンス目標に対して測定するには、適切な量と多様性のデータを収集する必要があります。 ワークロード内のすべてのコンポーネントとフローによって、継続的で意味のあるメトリックとログが自動的に生成されるようにします。 このデータは、アプリケーション、プラットフォーム、ストレージ、オペレーティング システムなどのさまざまなレベルからソース化する必要があります。 包括的なパフォーマンス データ収集を使用すると、パフォーマンスを包括的に理解できるため、非効率性と改善のための手段を正確に識別できます。

パフォーマンス データを一元化する

パフォーマンス メトリックとログを一元化することは、さまざまなソースからパフォーマンス メトリックとログを収集し、中央の場所に格納するプロセスです。 中央メトリック シンクと中央ログ シンクを作成します。 この一元化により、さまざまなシステムとコンポーネントにわたるパフォーマンス メトリックとログに簡単にアクセス、分析、監視できます。 メトリックとログを一元化することで、ワークロードのパフォーマンスを可視化できます。 ワークロードのパフォーマンス メトリックとログを集計して格納できる適切なプラットフォームまたはツールを選択します。

トレードオフ: メトリックとログを収集するコストを理解します。 一般に、収集するメトリックとログが多いほど、コストが高くなります。

パフォーマンス データをセグメント化する

パフォーマンス データをセグメント化するには、メトリックとログの元、目的、または環境に基づいて、メトリックとログを整理して分類する必要があります。 たとえば、運用データを非運用環境のデータから分離するか、パフォーマンス目標とビジネス メトリックを区別する必要があります。 データのセグメント化は、特定の環境の最適化に役立ち、トラブルシューティングを容易にし、パフォーマンス監視の不正確さを制限します。 さまざまなデータ型を明確に区別することで、関連するメトリックをより効率的にキャプチャ、分析、対応し、ワークロードの目標に合わせてワークロードの正常性をより適切に調整できます。 パフォーマンス データをセグメント化するには、次の推奨事項を考慮してください。

  • 運用データと非運用データを別々に保持します。 環境ごとにデータを分離することで、各環境の監視と最適化に集中できます。 運用環境では、ユーザーと業務に直接影響を与えるパフォーマンスの問題をより適切に特定して対処できます。 非運用環境では、データの分離により、運用環境にデプロイする前に、テスト フェーズ中の効果的なトラブルシューティングと微調整が容易になります。

  • 各環境内で 1 つのデータ セットを使用します。 パフォーマンス ターゲットには 1 つのデータ セットを使用し、パフォーマンス ターゲットに関連するアラートには別のデータ セットを使用しないでください。 さまざまなデータ セットを使用すると、パフォーマンス監視の有効性を損なう不正確なアラートが発生します。

  • パフォーマンス目標とビジネス メトリックを分離します。 運用チームと開発チームは、パフォーマンス 目標を使用してワークロードの正常性を監視し、ビジネス 目標を満たします。 ビジネス メトリックは、ビジネス目標または顧客レポートに関連します。 データが直接重複している場合でも、別のデータ ストリームでビジネス メトリックをキャプチャします。 分離により、適切なデータを柔軟にキャプチャし、データを個別に分析できます。

アイテム保持ポリシーを定義する

保持ポリシーでは、パフォーマンス データを保持する必要がある期間が決まります。 これらのポリシーを確立すると、ストレージを効率的に管理し、分析に必要なデータのみにアクセスできるようになります。 このようなポリシーは、より優れたパフォーマンスをサポートし、コンプライアンス標準を満たしています。 すべての環境で効果的なトラブルシューティングと監視を可能にするために、ログデータとメトリックデータの保持ポリシーを構成する必要があります。 たとえば、ログとメトリックは、テスト環境よりも運用環境で長時間保持する必要がある場合があります。 保持期間は、organizationの要件とコンプライアンス規制と一致している必要があります。 分析と監査の目的でデータを保持する期間を決定します。 すぐに分析するために必要のないデータをアーカイブします。

アプリケーションパフォーマンスデータを収集する

アプリケーション データの収集には、主にコードのインストルメント化によって収集される、スループット、待機時間、完了時間などのアプリケーションのパフォーマンス メトリックの監視と分析が含まれます。 アプリケーション パフォーマンス データは、アプリケーションの正常性とパフォーマンスに関する貴重な分析情報を提供します。 パフォーマンス データを監視および分析することで、問題の特定とトラブルシューティング、アプリケーションのパフォーマンスの最適化、アプリケーションの情報に基づいた意思決定を行うことができます。

コードのインストルメント化

インストルメンテーションとは、コード スニペットを埋め込んだり、ツールをアプリケーション コードに統合したりするプロセスを指します。 インストルメンテーションの目的は、アプリケーションの実行中にパフォーマンス データをキャプチャすることです。 アプリケーションの重要な操作を強調表示するメトリックを収集することが不可欠です。 スループット、待機時間、完了時間などのメトリックに焦点を当てます。 ビジネス関連の運用とそうでない運用を区別することが重要です。 ビジネス運用に関連するデータの場合は、そのメタデータが個別の追跡とストレージを可能にする方法で構造化されていることを確認します。 コード インストルメンテーションの主な理由は、アプリケーションがワークロードを処理する方法に関するデータを収集することです。 これには、次のようなメリットがあります。

  • パフォーマンスのボトルネックの特定: CPU 使用率やメモリ使用量などのメトリックを追跡することで、ボトルネックを特定し、それに応じてコードを最適化できます。

  • 負荷の下でのシステム動作の評価: さまざまなワークロードとストレス シナリオでアプリケーションがどのように実行されるかを確認できます。 このデータは、スケーラビリティ、コンカレンシー、リソースの使用に関連する問題を特定するのに役立ちます。

  • アプリケーションの正常性と可用性の追跡: 主要業績評価指標はリアルタイムで監視されるため、アプリケーションのパフォーマンスと可用性に影響を与える可能性のある問題に関するアラートを受け取ることができます。

  • ユーザー エクスペリエンスの向上: ユーザーがアプリケーションとやり取りする方法に関する分析情報を得ることができます。 この情報を使用して、ユーザー エクスペリエンスを最適化し、改善のための領域を特定します。

  • 容量を計画し、リソースを割り当てる: インストルメンテーションによって収集されるパフォーマンス データは、アプリケーションのリソース要件に関する貴重な分析情報を提供できます。 この情報は、容量の計画とリソースの割り当てに関する決定を通知できます。

パフォーマンス監視用にコードをインストルメント化する場合は、次の方法を検討してください。

  • APM ツールを使用する: APM ツールは、メトリック、トレース、ログなどのパフォーマンス データを収集して分析できます。 APM ツールは、コード レベルのインストルメンテーション、トランザクション トレース、パフォーマンス プロファイリングなどの機能を提供します。

  • ログ記録とトレース フレームワークの使用: ログ記録フレームワークとトレース フレームワークは、開発者がログ記録とトレースを容易にするためにアプリケーションに統合するツールまたはライブラリです。 これらのフレームワークは、ログの生成、トレース要求、時には生成されたデータの書式設定や転送を行う関数を提供します。 ログ記録とトレース フレームワークをコード ベースに組み込むことで、開発者は実行時に関連するデータをキャプチャできます。 データには、実行パス、I/O、およびパフォーマンスに関する情報を含めることができます。

  • カスタム インストルメンテーション: 開発者は、アプリケーションとワークロードに固有のパフォーマンス メトリックを収集するカスタム コードを追加できます。 カスタム インストルメンテーションでは、ランタイムの測定、リソースの使用状況の追跡、または特定のイベントのキャプチャを行うことができます。 プラットフォーム メトリックが不十分な場合にのみ、カスタム コード インストルメンテーションを記述します。 場合によっては、プラットフォーム リソースは、アプリケーションの集計または詳細な観点を測定できます。 過剰なコードのトレードオフやプラットフォーム機能への依存に対してカスタム コードを使用してその作業を複製するかどうかの問題を検討します。

  • トランザクション時間をキャプチャします。 トランザクション時間のキャプチャは、パフォーマンス監視の一環として主要な技術的機能のエンドツーエンドの時間を測定することに関連します。 アプリケーション レベルのメトリックには、エンドツーエンドのトランザクション時間を含める必要があります。 これらのトランザクション時間は、データベース クエリ、外部 API 呼び出しの応答時間、処理ステップの失敗率などの主要な技術関数に対応する必要があります。

  • テレメトリ標準を使用します。 OpenTelemetry などのテレメトリ標準を中心に構築された APM ツールインストルメンテーション ライブラリとツールの使用を検討してください。

分散トレースを有効にする

分散トレースは、分散システムを通過する要求を追跡および監視するために使用される手法です。 これにより、要求のパスを追跡して複数のサービスとコンポーネント間を移動し、ワークロードのパフォーマンスと効率に関する貴重な分析情報を提供できます。 分散トレースは、分散システム内のボトルネック、待機時間の問題、最適化のための領域を特定するのに役立つので、パフォーマンス効率のために重要です。 要求のフローを視覚化することで、遅延や非効率性が発生する場所を特定し、パフォーマンスを向上させるための適切なアクションを実行できます。 分散トレースを有効にするには、次の手順に従います。

  1. まず、アプリケーションとサービスをインストルメント化してトレース データを生成します。 OpenTelemetry などの分散トレースをサポートするライブラリまたはフレームワークを使用します。

  2. トレース情報がサービス境界を越えて伝達されていることを確認します。 通常は、一意のトレース ID とその他のコンテキスト情報を各要求に渡す必要があります。

  3. 一元化されたトレース収集システムを設定します。 このシステムは、アプリケーションとサービスによって生成されたトレース データを収集して格納します。

  4. 収集されたトレース データを使用して、要求のエンドツーエンド フローを視覚化し、分散システムのパフォーマンス特性を分析します。

アプリケーション ログを収集する

コードをインストルメント化するときは、主な出力の 1 つがアプリケーション ログである必要があります。 ログは、さまざまな環境でのアプリケーションの実行方法を理解するのに役立ちます。 アプリケーション ログには、アプリケーション イベントを生成する条件が記録されます。 すべてのアプリケーション環境でアプリケーション ログを収集します。 アプリケーション全体で対応するログ エントリで、各トランザクションの関連付け ID をキャプチャする必要があります。 関連付け ID は、ユーザー サインインなどの重要なアプリケーション フロー間でアプリケーション ログ イベントを関連付ける必要があります。 この相関関係を使用して、ターゲットと非機能要件のコンテキストで主要なシナリオの正常性を評価します。

構造化ログを使用する必要があります。 構造化ログは、ログの解析と分析を高速化します。 これにより、複雑さなしでログのインデックス作成、クエリ、およびレポートを簡単に行うことができます。 アプリケーション コードで構造化ログ ライブラリを追加して使用します。 ログ エントリは、他の方法では関連付けられなかったデータを関連付けるのに役立つ場合があります。

リソース パフォーマンス データを収集する

リソース パフォーマンス データを収集することで、ワークロードの正常性と動作に関する分析情報を得ることができます。 リソース パフォーマンス データは、容量計画の鍵となるリソースの使用に関する情報を提供します。 このデータは、ワークロードの正常性に関する分析情報も提供し、問題の検出とトラブルシューティングに役立ちます。 次の推奨事項を検討してください。

  • すべてのリソースのメトリックとログを収集します。 各 Azure サービスには、リソースの機能に固有のメトリックのセットがあります。 これらのメトリックは、リソースの正常性とパフォーマンスを理解するのに役立ちます。 各リソースの 診断設定 を追加して、ワークロード チームがアラートとダッシュボードを作成する際にアクセスできる場所にメトリックを送信します。 メトリック データは、短期アクセスに使用できます。 長期的なアクセスまたは Azure Monitor の外部にあるシステムからのアクセスの場合は、メトリック データを統合シンクにアクセス場所に送信します。

  • プラットフォーム ツールを使用します。 Azure Monitor Insights などの組み込みおよび統合された監視ソリューションからインスピレーションを得ます。 このツールは、パフォーマンス操作を効率化します。 プラットフォームを選択し、カスタム ツールまたはレポートに投資するときは、プラットフォーム ツールを検討してください。

  • ネットワーク トラフィックを監視します。 ネットワーク トラフィックの監視とは、ネットワーク 経路を越えて移動するデータのフローとパターンを追跡および分析することを意味します。 トラフィック分析を収集し、サブネット境界を通過するトラフィックを監視します。 目標は、ネットワーク パフォーマンスを分析して最適化することです。

データベースとストレージのデータを収集する

多くのデータベースおよびストレージ システムには、独自の監視ツールが用意されています。 これらのツールは、これらのシステムに固有のパフォーマンス データを収集します。 多くの場合、データベースおよびストレージ システムでは、パフォーマンス関連のイベントとインジケーターを含むログが生成されます。 データベース データとストレージ パフォーマンス データを収集して、ボトルネックを特定し、問題を診断し、十分な情報に基づいた意思決定を行い、ワークロードの全体的なパフォーマンスと信頼性を向上させることができます。 次の種類のパフォーマンス データを収集することを検討してください。

  • スループット: スループットは、一定期間にわたってストレージ システムから読み取られたり、ストレージ システムに書き込まれたりするデータの量を測定します。 スループット データは、データ転送機能を示します。

  • 待機時間: 待機時間は、ストレージ操作が最後に実行される時間を測定します。 待機時間データは、ストレージ システムの応答性を示します。

  • IOPS (1 秒あたりの I/O 操作数): ストレージ システムが 1 秒間に実行できる読み取り操作または書き込み操作の数に関するデータ。 IOPS データは、ストレージ システムのスループットと応答性を示します。

  • 容量の使用: 容量の使用は、使用されるストレージ容量の量と使用可能な量です。 容量使用データは、組織が将来のストレージ ニーズを計画するのに役立ちます。

データベースの場合は、データベース固有のメトリックも収集する必要があります。

  • クエリのパフォーマンス: データベース クエリの実行時間、リソース使用量、効率性に関するデータ。 低速または非効率的なデータベース クエリでは、ワークロードの速度が大幅に低下する可能性があります。 低速で頻繁に実行されるクエリを探します。

  • トランザクションのパフォーマンス: トランザクション期間、コンカレンシー、ロックの競合など、データベース トランザクションのパフォーマンスに関するデータ。

  • インデックスのパフォーマンス: インデックスの断片化、使用状況の統計、クエリの最適化など、データベース インデックスのパフォーマンスに関するデータ。

  • リソースの使用: CPU、メモリ、ディスク領域、I/O、ネットワーク帯域幅を含むデータ。

  • 接続メトリック: アクティブな接続、中止された接続、失敗した接続の数を追跡するメトリック。 障害率が高い場合は、ネットワークの問題を示したり、データベースが接続の最大数に達したことを示したりする可能性があります。

  • トランザクション レート: 1 秒あたりにデータベースが実行されるトランザクションの数。 トランザクションレートの変化は、パフォーマンスの問題を示している可能性があります。

  • エラー率: データベースのパフォーマンスを示すデータ。 エラー率が高い場合は、パフォーマンスの問題を示している可能性があります。 データベース エラーを収集して分析する。

オペレーティング システム データを収集する (該当する場合)

サービスとしてのプラットフォーム (PaaS) ソリューションを使用すると、オペレーティング システムのパフォーマンス データを収集する必要がなくなります。 ただし、ワークロードが仮想マシン (サービスとしてのインフラストラクチャ) で実行されている場合は、オペレーティング システムに関するパフォーマンス データを収集する必要があります。 オペレーティング システムと仮想マシンに対する需要を理解する必要があります。 オペレーティング システムのパフォーマンス カウンターの頻繁なサンプル。 たとえば、1 分ごとにパフォーマンス カウンターをサンプリングできます。

少なくとも、次のパフォーマンス領域に関するデータを収集します。

パフォーマンス領域 プロセスまたは関数
CPU - CPU 使用率 (ユーザー モードまたは特権モード)
- CPU キューの長さ (CPU 時間を待機しているプロセスの数)
Process - プロセス スレッド数
- プロセス ハンドル数
メモリ - コミットされたメモリ
- 使用可能なメモリ
- 1 秒あたりのページ数
- スワップ領域の使用
ディスク - ディスク読み取り
- ディスクの書き込み
- ディスクスループット
- ディスク領域の使用量
ネットワーク - ネットワーク インターフェイスのスループット
- ネットワーク インターフェイス Rx/Tx エラー

データの検証と分析

パフォーマンス データは、パフォーマンス目標と一致している必要があります。 データは、パフォーマンス目標に関連するワークロードまたはフローのパフォーマンスを完全かつ正確に表す必要があります。 たとえば、Web サービスの応答時間のパフォーマンス目標は 500 ミリ秒です。 頻繁な評価によってパフォーマンスの問題の早期検出と軽減が可能であるため、データを分析するルーチンにします。

  • アラートを作成する。 アクション可能なアラートを作成し、パフォーマンスの問題を迅速に識別して修正できるようにすると便利です。 これらのアラートは、違反したパフォーマンスしきい値、潜在的なビジネス効果、および関連するコンポーネントを明確に示す必要があります。 まず、共通アラートと推奨アラートを設定します。 時間の経過とともに、特定のニーズに基づいてこれらの条件を変更できます。 これらのアラートの主な目的は、重大な問題にエスカレートする前に、潜在的なパフォーマンス低下を予測することです。 外部依存関係のアラートを設定できない場合は、依存関係呼び出しの期間など、間接的な測定値を収集する方法を考案することを検討してください。

  • データ収集の制限を設定します。 収集するデータの量とその保持期間に関する論理制限を決定して設定します。 テレメトリでは、大量のデータが生成される場合があります。 最も重要な業績評価指標のみをキャプチャすることに集中するか、パフォーマンス データから意味のある分析情報を抽出するための効率的なシステムを用意することが不可欠です。

Azure ファシリテーション

パフォーマンス データの一元化、セグメント化、保持: Azure Monitor は 、複数の Azure サブスクリプションと Azure 以外のサブスクリプションとテナントにわたって、ワークロードのすべてのレイヤーとコンポーネントからデータを収集して集計します。 データを相互に関連付け、分析、視覚化、および/またはデータに応答できる一般的な一連のツールで使用するために、データを共通のデータ プラットフォームに格納します。

Azure Monitor ログを有効にするには、少なくとも 1 つの Log Analytics ワークスペース が必要です。 すべてのデータ収集のために 1 つのワークスペースを使用できます。 パフォーマンス データをセグメント化するための要件に基づいて複数のワークスペースを作成することもできます。 また、 アイテム保持ポリシーを定義することもできます。

アプリケーション パフォーマンス データの収集: Application Insights は、アプリケーションのパフォーマンスと可用性を監視するのに役立つ Azure Monitor の機能です。 要求率、応答時間、例外の詳細などのテレメトリ データを収集することで、アプリケーション レベルの分析情報を提供します。 アプリケーションに対して Application Insights を有効にし、必要なパフォーマンス データを収集するように構成できます。 Application Insights では、 分散トレースもサポートされます。 すべてのフローの分散トレースを構成します。 エンドツーエンドのトランザクション フローを構築するには、さまざまなアプリケーション コンポーネントまたは階層から発生するイベントを関連付けます。

パフォーマンス カウンターは、アプリケーションのパフォーマンスを監視するための強力な方法です。 Azure には、CPU 使用率、メモリ使用量、ディスク I/O、ネットワーク トラフィックなどのデータを収集するために使用できるさまざまなパフォーマンス カウンターが用意されています。 パフォーマンス カウンター データを出力するようにアプリケーションを構成した場合、Azure Monitor は分析のためにデータを収集して格納します。

リソース パフォーマンス データの収集: ほとんどの Azure サービスでは、診断と監査の情報を提供するプラットフォーム ログとメトリックが生成されます。 診断設定を有効にすると、収集して格納するプラットフォーム ログとメトリックを指定できます。 関連付けの目的で、サポートされているすべてのサービスに対して診断を有効にしてから、アプリケーション ログと同じ宛先にログを送信します。

データベースとストレージのパフォーマンス データの収集: Azure Monitor を使用すると、Azure 内のデータベースのパフォーマンス データを収集できます。 Azure SQL Database、Azure Database for MySQL、Azure Database for PostgreSQL、およびその他のデータベース サービスの監視を有効にすることができます。 Azure Monitor には、CPU 使用率、メモリ使用量、クエリ パフォーマンスなど、データベースのパフォーマンスを監視するためのメトリックとログが用意されています。 問題の通知を受け取るには、パフォーマンスのしきい値に基づいてアラートを設定できます。

Azure には、Azure Virtual MachinesでのSQL Serverなど、データベースのパフォーマンスに関する推奨事項が用意されています。 これらの推奨事項は、データベース ワークロードのパフォーマンスを最適化するのに役立ちます。 これには、パフォーマンス カウンターの収集、待機統計のキャプチャ、ピーク時のパフォーマンス データの収集に関する提案が含まれます。

Azure Storage Analyticsを使用すると、Blob Storage、Table Storage、Queue Storage などの Azure Storage サービスのパフォーマンス データを収集できます。 ストレージ アカウントのログ記録とメトリックを有効にして、読み取り/書き込み操作の数、スループット、待機時間などの主要なパフォーマンス インジケーターを監視できます。

オペレーティング システムのパフォーマンス データの収集:Azure Diagnostics拡張機能を使用すると、CPU、メモリ、ディスク I/O、ネットワーク トラフィックなど、仮想マシン (VM) から詳細なパフォーマンス データを収集できます。 このデータは、分析とアラートのために Azure Monitor またはその他のストレージ サービスに送信できます。

パフォーマンス データの検証と分析: Azure Monitor 内では、Azure Monitor ログを使用して、アプリケーションやシステムからログ データを収集、分析、視覚化できます。 アプリケーション レベルのログやインフラストラクチャ ログなど、アプリケーションからログを取り込むよう Azure Monitor ログを構成できます。 ログを集計することで、イベントをクロスクエリし、アプリケーションのパフォーマンスに関する分析情報を得ることができます。 詳細については、「 Azure Monitor ログのコストの計算とオプション」および 「 Azure Monitor の価格」を参照してください。

Azure Monitor では、特定のパフォーマンス メトリックを監視し、定義済みの条件に基づいてアラートをトリガーするアラート ルールを定義できます。 たとえば、CPU 使用率が特定のしきい値を超えたとき、または応答時間が指定した制限を超えたときに通知するアラート ルールを作成できます。 目的の受信者に通知を送信するようにアラート ルールを構成します。

アラート ルールを作成するときに、アラートをトリガーするタイミングを決定する条件を定義できます。 しきい値、集計方法、時間枠、評価の頻度を設定できます。 パフォーマンス監視の要件に基づいて条件を定義します。 通知の送信に加えて、アラートがトリガーされたときに実行されるアクションを指定できます。 アクションには、電子メールの送信、Webhook の呼び出し、または Azure 関数の実行が含まれます。 特定のアラート シナリオに対応する適切なアクションを選択します。

例

パフォーマンス効率のチェックリスト

推奨事項の完全なセットを参照してください。

パフォーマンス効率チェックリスト