パフォーマンス データを収集するための推奨事項
この Azure Well-Architected フレームワーク パフォーマンス効率チェックリストの推奨事項への適用:
| PE:04 | パフォーマンス データを収集します。 ワークロード コンポーネントとフローは、自動的かつ継続的で意味のあるメトリックとログを提供する必要があります。 アプリケーション、プラットフォーム、データ、オペレーティング システムのレベルなど、ワークロードのさまざまなレベルでデータを収集します。 |
|---|
パフォーマンス データの収集は、ワークロードのパフォーマンスに関する情報を提供するメトリックとログを収集するプロセスです。 このデータには、"メトリック" という数値が含まれています。 メトリックは、特定の時点におけるシステムの状態を表すものです。 これには、レコードに編成されたさまざまなデータを格納するログも含まれます。
パフォーマンス データを収集することで、ワークロードのパフォーマンスを監視および分析できます。 この情報を使用して、パフォーマンスのボトルネックを特定し、問題のトラブルシューティングを行い、リソースの割り当てを最適化し、データドリブンの決定を行ってワークロードの全体的なパフォーマンス効率を向上させることができます。
データに基づく分析情報がないと、基となるパフォーマンスの問題や最適化の機会に気付かない可能性があります。 結果として、応答時間の遅延、スループットの低下、リソース使用量の増加、そして最終的には最適ではないユーザー エクスペリエンスにつながる可能性があります。 さらに、パフォーマンス データがないと、問題をタイムリーに診断してトラブルシューティングすることが困難になり、ダウンタイムが長くなり、生産性が低下します。
定義
| 相談 | 定義 |
|---|---|
| アクティビティ ログ | リソースの削除など、リソースに対する管理操作を追跡するログ。 |
| アプリケーション ログ | アプリケーション イベント、エラー、その他のアクティビティ (サインインの使用やデータベース接続の失敗など) に関する情報を追跡するログ。 |
| アプリケーション パフォーマンス監視 (APM) ツール | アプリケーションのパフォーマンスを監視し、報告するツール。 |
| コード インストルメンテーション | アプリケーション コードの観点による、パフォーマンス メトリックの直接的または間接的な取り込み。 取り込まれるメトリックには、フロー メトリック、リソース使用量、言語またはランタイムに固有のメトリックが含まれます。 |
| 分散トレース | 分散ワークロード コンポーネント全体のメトリックの収集と関連付け。 |
| メトリック シンク | 分析のために時系列データを関連付けるメトリックの保存先。 |
| プラットフォーム ログ | リソース ログ、アクティビティ ログ、監査ログなどの診断と監査のデータ。 |
| プラットフォームのメトリック | 特定の時点におけるワークロードのパフォーマンスを記録する数値。 |
| リソース ログ | システムによって生成されるデータ。 システムの状態に関する情報が提供されます。 |
| Rx/Tx エラー | ネットワーク インターフェイス上の受信エラーと送信エラーの数。 |
| 構造化ログ | 意味のある形式を定義してメッセージをログすること (通常はキーと値のペア)。 |
主要な設計戦略
パフォーマンスの最適化には、パフォーマンス目標に対するワークロードまたはフローの現在のパフォーマンスを測定するデータが必要です。 コードとインフラストラクチャのパフォーマンスをパフォーマンス目標に対して測定するには、適切な量と多様性のデータを収集する必要があります。 ワークロード内のすべてのコンポーネントとフローから、継続的で意味のあるメトリックとログが自動的に生成されるようにします。 このデータは、アプリケーション、プラットフォーム、ストレージ、オペレーティング システムなどのさまざまなレベルから収集する必要があります。 包括的なパフォーマンス データ収集により、パフォーマンスを全体的に把握し、非効率な部分と改善の余地を正確に特定できます。
パフォーマンス データの収集を一元化する
パフォーマンス メトリックとログの一元化は、さまざまなソースからパフォーマンス メトリックとログを収集し、それらを中央の場所に保存するプロセスです。 中央メトリック シンクと中央ログ シンクを作成します。 この一元化により、さまざまなシステムとコンポーネントのパフォーマンス メトリックとログに簡単にアクセスし、分析および監視することができます。 メトリックとログを一元化することで、ワークロードのパフォーマンスを視覚化できます。 ワークロードのパフォーマンス メトリックとログを集計して保存できる、適切なプラットフォームまたはツールを選択します。
トレードオフ: メトリックとログを収集するコストを理解します。 一般に、収集するメトリックとログが多いほど、コストが高くなります。
パフォーマンス データをセグメント化する
パフォーマンス データをセグメント化するには、発生元、目的、または環境に基づいてメトリックとログを整理して分類する必要があります。 たとえば、運用データを非運用データから分離したり、パフォーマンス目標とビジネス メトリックを区別したりする必要があります。 データのセグメント化は、特定の環境の最適化に役立ち、トラブルシューティングを支援し、パフォーマンスの監視の不正確さを制限します。 さまざまなデータ型を明確に区別することで、関連するメトリックをより効率的に取り込み、分析し、対応し、ワークロードの正常性をワークロードの目標に合わせて調整することができます。 パフォーマンス データをセグメント化するには、次の推奨事項を考慮してください。
運用データと非運用データを分離します。 データを環境ごとに分離することで、各環境の監視と最適化に集中することができます。 運用環境では、ユーザーや業務に直接影響するパフォーマンスの問題をより適切に特定し、対処することができます。 非運用環境では、データを分離すると、運用環境にデプロイする前のテスト フェーズ時に効果的なトラブルシューティングと微調整が容易になります。
各環境内で 1 つのデータ セットを使用します。 パフォーマンス目標に関連するアラートには、パフォーマンス目標用のデータ セットとは別のデータ セットを使用しないでください。 異なるデータ セットを使用すると、不正確なアラートが発生し、パフォーマンス監視の効果が損なわれる可能性があります。
パフォーマンス目標とビジネス メトリックを分離します。 運用と開発のチームは、パフォーマンス目標を使用してワークロードの正常性を監視し、ビジネス目標を達成します。 ビジネス メトリックは、ビジネス目標または顧客レポートに関連します。 データが直接重複している場合でも、ビジネス メトリックを別のデータ ストリームで取り込みます。 分離することで、柔軟に適切なデータを取り込み、データを個別に分析することができます。
アイテム保持ポリシーを定義する
アイテム保持ポリシーによって、パフォーマンス データを保持する期間が決まります。 これらのポリシーを確立すると、ストレージを効率的に管理し、分析に必要なデータのみにアクセスできるようになります。 このようなポリシーは、パフォーマンスの向上をサポートし、コンプライアンスの標準を満たします。 すべての環境で効果的にトラブルシューティングし、監視できるように、ログとメトリック データのアイテム保持ポリシーを構成する必要があります。 たとえば、場合によっては、テスト環境よりも運用環境でログとメトリックをより長い期間保持する必要があります。 保持期間は、組織の要件とコンプライアンスの規制と一致している必要があります。 分析と監査の目的でデータを保持する期間を決定します。 すぐに分析する必要のないデータはアーカイブします。
アプリケーションのパフォーマンス データを収集する
アプリケーション データの収集には、主にインストルメント化コードを介して収集されるスループット、待機時間、完了時間などのアプリケーションのパフォーマンス メトリックの監視と分析が含まれます。 アプリケーション パフォーマンス データから、アプリケーションの正常性とパフォーマンスに関する貴重な分析情報が得られます。 パフォーマンス データを監視および分析することで、問題を特定してトラブルシューティングし、アプリケーションのパフォーマンスを最適化し、情報に基づいてアプリケーションに関する意思決定を行うことができます。
コードをインストルメント化する
インストルメンテーションとは、コード スニペットを埋め込む、またはツールをアプリケーション コードに統合するプロセスを指します。 インストルメンテーションの目的は、アプリケーションの実行中にパフォーマンス データを取り込むことです。 アプリケーションの重要な操作を明らかにするメトリックを収集することが不可欠です。 スループット、待機時間、完了時間などのメトリックに注目します。 業務関連の操作とそうでない操作を区別することが重要です。 業務に関するデータの場合は、必ず明確に追跡および保存できるようにそのメタデータを構造化します。 コード インストルメンテーションの主な目的は、アプリケーションがワークロードを処理する方法に関するデータを収集することです。 これにより、次のメリットがあります。
パフォーマンスのボトルネックの特定: CPU 使用量やメモリ使用量などのメトリックを追跡することで、ボトルネックを特定し、それに応じてコードを最適化できます。
負荷がかかった状態のシステム動作の評価: さまざまなワークロードとストレスのシナリオで、アプリケーションがどのように動作するかを確認できます。 このデータは、スケーラビリティ、コンカレンシー、リソースの使用に関連する問題を特定するのに役立ちます。
アプリケーションの正常性と可用性の追跡: 重要なパフォーマンス インジケーターはリアル タイムで監視されるため、アプリケーションのパフォーマンスと可用性に影響する潜在的な問題に関するアラートを受け取ることができます。
ユーザー エクスペリエンスを向上する: ユーザーがアプリケーションをどのように操作するかについての分析情報を得ることができます。 この情報を使用して、ユーザー エクスペリエンスを最適化し、改善すべき領域を特定します。
容量を計画し、リソースを割り当てる: インストルメンテーションが収集するパフォーマンス データから、アプリケーションのリソース要件に関する貴重な分析情報が得られます。 この情報は、容量の計画とリソースの割り当てに関する判断に役立ちます。
パフォーマンス監視のためにコードをインストルメント化する場合は、次の戦略を考慮してください。
APM ツールを使用する: APM ツールは、メトリック、トレース、ログなどのパフォーマンス データを収集して分析できます。 APM ツールには、コード レベルのインストルメンテーション、トランザクション追跡、パフォーマンス プロファイルなどの機能があります。
ログとトレースのフレームワークを使用する: ログとトレースのフレームワークは、開発者がログとトレースを容易にするためにアプリケーションに統合するツールまたはライブラリです。 このようなフレームワークには、ログの生成、要求のトレース、さらには生成されたデータの書式設定や転送を行う関数が用意されています。 ログとトレースのフレームワークをコード ベースに組み込むことで、開発者は実行時に関連データを取り込むことができます。 データには、実行パス、I/O、パフォーマンスに関する情報を含めることができます。
カスタム インストルメンテーション: 開発者はカスタム コードを追加して、アプリケーションとワークロードに固有のパフォーマンス メトリックを収集できます。 カスタム インストルメンテーションで、ランタイムの測定、リソース使用量の追跡、または特定のイベントの取り込みを行うことができます。 プラットフォームのメトリックが不十分な場合にのみ、カスタム コード インストルメンテーションを作成します。 状況によっては、プラットフォーム リソースで、アプリケーションの集計だけでなく、詳細な視点を測定できます。 追加のコードのトレードオフか、パフォーマンス機能への依存関係かについて、カスタム コードを使用してその作業を複製するかどうかを検討します。
トランザクション時間を取り込みます。 トランザクション時間の取り込みは、パフォーマンス監視の一環として、主要な技術的機能のエンドツーエンド時間を測定することに関連しています。 アプリケーションレベルのメトリックには、エンドツーエンドのトランザクション時間を含める必要があります。 これらのトランザクション時間は、データベース クエリ、外部 API 呼び出しの応答時間、処理ステップの失敗率など、主要な技術的機能をカバーする必要があります。
テレメトリ標準を使用します。 APM ツール インストルメンテーション ライブラリと、OpenTelemetry などのテレメトリ標準を中心に構築されたツールの使用を検討してください。
分散トレースを有効にする
分散トレースは、分散システムを通過する要求を追跡および監視するために使用される手法です。 これにより、要求が複数のサービスやコンポーネント間を通過するパスを追跡し、ワークロードのパフォーマンスと効率について貴重な分析情報を得ることができます。 分散トレースは、分散システム内のボトルネック、待機時間の問題、最適化が必要な領域の特定に役立つため、パフォーマンス効率にとって重要です。 要求のフローを視覚化することで、遅延や非効率が発生している場所を特定し、適切な措置を実行してパフォーマンスを向上させることができます。 分散トレースを有効にするには、次の手順を実行します。
まず、アプリケーションとサービスをインストルメント化してトレース データを生成します。 OpenTelemetry など、分散トレースをサポートするライブラリまたはフレームワークを使用します。
トレース情報がサービス境界を越えて伝達されるようにします。 通常は、各要求で一意のトレース ID とその他のコンテキスト情報を渡す必要があります。
一元化されたトレース収集システムを設定します。 このシステムを使用して、アプリケーションとサービスによって生成されたトレース データを収集して保存します。
収集されたトレース データを使用して、要求のエンドツーエンド フローを視覚化し、分散システムのパフォーマンス特性を分析します。
アプリケーション ログを収集する
コードをインストルメント化するときは、主な出力の 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 時間を待機しているプロセスの数) |
| プロセス | - プロセス スレッド数 - プロセス ハンドル数 |
| [メモリ] | - コミット済みメモリ - 使用可能なメモリ - 1 秒あたりのページ数 - スワップ領域の使用量 |
| ディスク | - ディスクの読み取り - ディスクの書き込み - ディスク スループット - ディスク領域の使用量 |
| ネットワーク | - ネットワーク インターフェイスのスループット - ネットワーク インターフェイス Rx/Tx エラー |
データの検証と分析
パフォーマンス データは、パフォーマンス目標と一致している必要があります。 データは、パフォーマンス目標に関連するため、ワークロードまたはフローのパフォーマンスを完全かつ正確に表す必要があります。 たとえば、Web サービスの応答時間のパフォーマンス目標は 500 ms です。 頻繁に評価することでパフォーマンスの問題を早期に検出し、軽減することができるため、データの分析を日課にします。
アラートを作成する。 実用的なアラートを用意し、パフォーマンスの問題を迅速に特定して修正できるようにすることをお勧めします。 これらのアラートは、パフォーマンスのしきい値違反、潜在的なビジネスへの影響、関連するコンポーネントを明確に示すようにします。 まず、一般的な推奨されるアラートを設定することから始めます。 時間の経過と共に、特定のニーズに基づいてこれらの条件を変更できます。 これらのアラートの主な目的は、潜在的なパフォーマンス低下を、重大な問題に発展する前に予測することです。 外部の依存関係に対してアラートを設定できない場合は、依存関係の呼び出しにかかる時間など、間接的な測定値を収集する方法を検討してください。
データ収集の制限を設定します。 収集するデータの量とその保持期間に対する論理的な制限を決定し、設定します。 場合によっては、テレメトリによって膨大な量のデータが生成されることがあります。 最も重要なパフォーマンス インジケーターのみを取り込むことに重点を置くか、パフォーマンス データから意味のある分析情報を抽出する効率的なシステムを導入することが不可欠です。
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 関数の実行などが含まれます。 特定のアラート シナリオに対応する適切なアクションを選択します。
例
- ベースラインの高可用性ゾーン冗長アプリ サービスの Web アプリケーション
- Azure Kubernetes Service (AKS) でマイクロサービス アプリケーションを監視する
- Azure Monitor を使用した企業の監視
関連リンク
パフォーマンス効率のチェックリスト
レコメンデーションの完全なセットを参照してください。