Share via

スマート検出 - パフォーマンスの異常

  • [アーティクル]

Note

Application Insight リソースを、警告を利用したスマート検出 (プレビュー) に移行できます。 移行によって、さまざまなスマート検出モジュールのアラート ルールが作成されます。 作成されたこれらのルールは、他の Azure Monitor アラート ルールと同じように管理および構成できます。 これらのルールのアクション グループを構成して、新たな検出時のアクションの実行や通知のトリガーを行うための複数の方法を有効にすることもできます。

移行プロセスの詳細については、スマート検出のアラートへの移行に関する記事を参照してください。

Application Insights は、Web アプリケーションのパフォーマンスを自動的に分析し、潜在的な問題について警告できます。

この機能を使用する場合、サポートされている言語のための Application Insights 用のアプリの構成を除き、特別な設定は不要です。 これは、アプリが十分なテレメトリを生成する際にアクティブになります。

スマート検出による通知はいつ送信されますか

Application Insights は、アプリケーションのパフォーマンスの低下を以下のいずれかの方法で検出します。

  • 応答時間の低下 - アプリが要求に対する応答を開始する速度が以前よりも遅くなった場合です。 この変化は急激に現れる可能性があります。たとえば、最新のデプロイメントにおけるリグレッションが発生する場合などです。 または、メモリ リークなどが原因で徐々に変化が生じる可能性もあります。
  • 依存関係の期間の低下 - アプリが REST API、データベース、またはその他の依存関係の呼び出しを行う場合です。 依存関係の応答が以前よりも遅くなります。
  • 低パフォーマンスのパターン - 一部の要求にのみ影響を及ぼすパフォーマンスの問題がアプリで発生します。 たとえば、あるブラウザーでお使いのページの読み込みが他のブラウザーと比較して遅い場合や、特定のサーバーからの要求の処理が遅い場合などです。 現時点では、このアルゴリズムはページの読み込み時間、要求の応答時間、および依存関係の応答時間を監視します。

スマート検出では、通常のパフォーマンスのベースラインを確立するために、少なくとも 8 日間のテレメトリが必要です。 その期間にアプリケーションを実行した後で、重大な異常があれば通知が行われます。

アプリに問題があるのは確かですか

いいえ。通知は、アプリに確実に問題があることを示すものではありません。 これは単に、より詳しく確認することを推奨するものです。

どのように修正すればよいですか

通知には診断情報が含まれます。 次に例を示します。

Here is an example of Server Response Time Degradation detection

  1. トリアージ: 通知は、影響を受けるユーザーまたは操作の数を示します。 この情報を基に、問題に優先順位を割り当てることができます。

  2. スコープ: 問題が影響する範囲はすべてのトラフィックですか。または一部のページのみですか。 特定のブラウザーまたは場所に限定されますか。 この情報を通知から取得できます。

  3. 診断: 多くの場合、通知内の診断情報は問題の性質を示します。 たとえば、要求率が高いときに応答時間が遅くなる場合、サーバーまたは依存関係のキャパシティを超えていることを示している可能性があります。

    それ以外の場合は、Application Insights の [パフォーマンス] ペインを開きます。 そこに プロファイラー データが表示されます。 例外がスローされた場合は、スナップショット デバッガーを試すこともできます。

電子メール通知を構成する

スマート検出による通知は、既定で有効になっています。 それらは Application Insights リソースが存在するサブスクリプションへの監視閲覧者および監視共同作業者のアクセス権を持つ人に送信されます。 既定の通知を変更するには、電子メール通知の [構成] をクリックするか、Application Insights で [スマート検出の設定] を開きます。

Smart Detection Settings

  • 既定の通知を無効にして、指定した電子メールの一覧に置き換えることができます。

スマート検出のパフォーマンスの異常に関する電子メールは、Application Insights リソースごとに 1 日 1 通に制限されます。 この電子メールは、その日に検出された新しい問題が 1 つ以上ある場合にのみ送信されます。 どのメッセージも繰り返し送信されることはありません。

よく寄せられる質問

  • 私のデータは Microsoft のスタッフに見られますか。

    • いいえ。 サービスは完全に自動化されています。 通知を受け取るだけです。 ユーザーのデータは プライベートです。

  • Application Insights によって収集されたすべてのデータが分析されるのですか。

    • 現在は、要求の応答時間、依存関係の応答時間、およびページの読み込み時間が分析されます。 その他のメトリックの分析も行われる予定です。

  • この検出はどのような種類のアプリケーションに有効ですか。

    • このようなパフォーマンスの低下は、適切なテレメトリを生成するどのアプリケーションでも検出されます。 Web アプリに Application Insights がインストールされていれば、要求と依存関係が自動的に追跡されます。 ただし、バックエンド サービスやその他のアプリケーションで TrackRequest() または TrackDependency の呼び出しを挿入した場合は、スマート検出が同じ方法で動作します。

  • 独自の異常検出ルールを作成できますか。または既存のルールをカスタマイズできますか。

  • 分析はどのくらいの頻度で実行されますか。

    • 前日 (UTC タイム ゾーンにおける終日) のテレメトリの分析が毎日実行されます。

  • これによりメトリック アラートが置き換えられるのですか。

    • いいえ。 異常と見なされる可能性のあるすべての動作を検出することを確約しているわけではありません。

  • 通知に応答して何も行わない場合は、リマインダーが受信されますか

    • いいえ。各問題についてのメッセージが送信されるのは 1 回のみです。 問題が引き続き発生する場合、[スマート検出] フィード ペインでそれが更新されます。

  • メールが消えました。 どうしたらポータルで通知を見つけられますか。

    • アプリの Application Insights の概要にある [スマート検出] タイルをクリックします。 これで、最大 90 日前までのすべての通知を検索できます。

パフォーマンスを向上させるにはどうすればよいですか。

Web サイト ユーザーにとって最大の不満の 1 つは、自らの経験でわかるように、時間のかかる応答や応答障害です。 したがって、この問題に対処することが重要です。

トリアージ

まず、それは重要なことですか。 ページの読み込みには常に時間がかかるが、そのページの閲覧を必要としているユーザーが 1 % にすぎない場合は、多分、他にもっと考えるべき重要なことがあります。 しかし、ユーザーの 1% しかそのページを開いていないが、毎回例外がスローされる場合、調べてみる価値はあるでしょう。

一般的なガイドとして、影響を受けたユーザー数やトラフィックの割合 (%) などの影響評価を使用します。 それだけでは全体像がわからない可能性があることに注意してください。 確認すべきその他の証拠を収集します。

問題のパラメーターを検討します。 地理的な場所によって状況が異なる場合は、該当するリージョンを対象とする可用性テストをセットアップします。そのエリアのネットワークに問題がある可能性があるためです。

遅いページ読み込みの診断

どこに問題がありますか。 サーバーの応答が遅いですか、ページが長すぎますか、ブラウザーがページを表示するのに必要な作業が多すぎますか。

[Browsers metric] (ブラウザー メトリック) ペインを開きます。 ブラウザーのページ読み込み時間のセグメント表示で、どこで時間がかかっているかがわかります。

  • [要求送信時間] の値が大きい場合は、サーバーの応答が遅いか、または要求が大量のデータを含む POST 要求です。 応答時間を調べるには、 パフォーマンス メトリック を確認します。
  • 依存関係の追跡 をセットアップして、パフォーマンス低下の原因が外部のサービスによるものか、内部のデータベースによるものかを確認します。
  • [受信応答時間] が大部分を占めている場合は、ページと、JavaScript、CSS、イメージなどのページの依存部分 (ただし、非同期で読み込まれるデータではない) が長くなっています。 可用性テストをセットアップし、依存部分を読み込むオプションを必ず設定します。 いくつかの結果を取得したら、結果の詳細を開き展開して、各種ファイルの読み込み時間を表示します。
  • [クライアントの処理時間] の値が大きい場合は、スクリプトの実行に時間がかかっています。 理由が明らかでない場合は、何らかのタイミング コードを追加することを検討し、trackMetric 呼び出しで時間を送信してください。

表示が遅いページの改善

サーバーの応答およびページ読み込み時間を短縮するためのアドバイスは Web に多数掲載されていますが、ここではその一部を取り上げます。 把握済みかもしれませんがいくつかのヒントを参考までに以下に示します。

  • ファイルのサイズが大きいため読み込みに時間がかかる: スクリプトとその他の部分を非同期に読み込みます。 スクリプトのバンドルを使用します。 メイン ページをウィジェットに分割し、データを別々に読み込みます。 長いテーブルに対して古いプレーンな HTML が送信されない: スクリプトを使用してデータを JSON またはその他のコンパクトな形式で要求し、所定のテーブルに入力します。 このようなタスクにおいて有効な優れたフレームワークがあります (これらはまた、当然ながら、サイズの大きいスクリプトを含みます)。
  • サーバーの依存関係が低速:コンポーネントの地理的な場所について検討してください。 たとえば、Azure を使用している場合、Web サーバーとデータベースが同じリージョンにあることを確認します。 クエリで必要以上の情報が取得されませんか。 キャッシュまたはバッチは役に立ちますか。
  • 容量の問題:応答時間と要求数のサーバー メトリックを確認してください。 応答時間のピークと要求数のピークが合わない場合は、サーバーが拡大されている可能性があります。

サーバーの応答時間の低下

応答時間の低下の通知では次のことが示されます。

  • 対象の操作の通常の応答時間と比較した場合の応答時間
  • 影響を受けるユーザーの数
  • 検出日とその 7 日前における対象の操作の平均応答時間および 90 パーセンタイルの応答時間。
  • 検出日とその 7 日前における対象の操作の要求の数
  • 対象の操作における低下と関連する依存関係における低下の相関関係
  • 問題の診断に役立つリンク
    • Profiler トレースは、操作時間が費やされた場所を表示するのに役立ちます。 このリンクは、対象の操作に対する Profiler トレースの例が存在する場合に利用できます。
    • メトリック エクスプローラーのパフォーマンス レポート。このレポートでは、対象の操作の時間の範囲/フィルターを詳細に分析できます。
    • この呼び出しを検索して、特定の呼び出しプロパティを表示します。
    • エラー レポート - カウントが > 1 の場合、パフォーマンス低下の一因となるエラーが対象の操作で発生したことを示します。

依存関係の期間の低下

最新のアプリケーションの多くは、マイクロ サービスによるデザイン アプローチを採用しており、それは多くの場合、外部サービスに大きく依存しています。 たとえば、アプリケーションが何らかのデータ プラットフォームに依存している場合や、Azure AI サービスなどのクリティカルなサービス プロバイダーに依存している場合があります。

依存関係の低下の通知例を次に示します。

Here is an example of Dependency Duration Degradation detection

次の指標が提示されます。

  • 対象の操作の通常の期間と比較した場合の期間
  • 影響を受けるユーザーの数
  • 検出日とその 7 日前におけるこの依存関係の平均期間と 90 パーセンタイルの期間
  • 検出日とその 7 日前における依存関係の呼び出し数
  • 問題の診断に役立つリンク
    • 対象の依存関係に関するメトリック エクスプローラーのパフォーマンス レポート
    • 対象の依存関係の呼び出しの検索による呼び出しのプロパティの表示
    • エラー レポート - カウントが > 1 の場合、検出期間中に依存関係の呼び出しが失敗し、期間の低下の一因となった可能性があることを意味します。
    • 対象の依存関係の期間と数を計算するクエリと Analytics を開きます。

低パフォーマンスのパターンのスマート検出

Application Insights は、一部のユーザーにのみ影響する、または一部のケースでのみユーザーに影響するパフォーマンス上の問題を検出します。 たとえば、特定のブラウザーの種類でページの読み込み速度が他のブラウザーと比較して遅い場合や、特定のサーバーの要求処理速度が他のサーバーよりも遅い場合があります。 また、ある地域における特定のオペレーティング システムを使用するクライアントでのページ読み込みの遅延など、プロパティの組み合わせに関連する問題も検出します。

上記のような異常はデータを調べるだけでは検出は困難ですが、想像以上によく発生します。 多くの場合、お客様からのクレームによってのみ表面化します。 その時点では遅すぎます。影響を受けたユーザーはすぐに競合他社のソリューションに切り替えてしまうからです。

現時点では、このアルゴリズムはページの読み込み時間、サーバーにおける要求の応答時間、および依存関係の応答時間を監視します。

しきい値規則や構成規則を設定する必要はありません。 異常パターンの検出には、機械学習およびデータ マイニングのアルゴリズムが使用されます。

From the email alert, click the link to open the diagnostic report in Azure

  • [日時] は、問題が検出された日時を示します。
  • [内容] は、検出された問題と、問題の動作が見られたイベント セットの特性を示します。
  • 表では、パフォーマンスの低いセットと他のすべてのイベントの平均的な動作が比較されます。

リンクをクリックしてメトリックス エクスプローラーを開き、パフォーマンスの低いセットの時間とプロパティでフィルター処理されたレポートを表示します。

時間の範囲とフィルターを変更して、テレメトリを調べます。

次のステップ

これらの診断ツールを使用すると、アプリからテレメトリを調査できます。

スマート検出は自動化されています。 ただし、アラートを追加で設定する機能が用意されています。