モデル駆動型アプリで利用できるデータは何ですか?

モデル駆動型アプリでは、ページの読み込みと統一インターフェイス (UCI) アウトバウンド ネットワーク リクエストに関連するパフォーマンス データを利用できます。

どのような種類のページ読み込みが利用できますか ?

ページ読み込みデータはどこで入手できますか ?

このデータは Application Insights の pageViews テーブルに移動します。 ユーザーが統一インターフェイスにページを読み込むたびに、エントリーがログに記録されます。 ログに記録されるデータには、「クリーンな」 読み込みが含まれます。 持続時間が正確に測定できない読み込み高速ナビゲーション、アプリからの切り替え、アラートメッセージは含まれません。 このため、利用状況分析に関連する正確な数値にこのデータを使用しないことをお勧めします。

統一インターフェイスページの読み込みの詳細を提供する customDimensions に追加のプロパティがあります。 たとえば、このクエリは pageViews テーブル内のすべての属性の値を返します。

pageViews
| take 1

pageViews テーブル属性は次のとおりです。

• appModule: アプリ モジュール名。
• entityName: この属性は関連する場合に存在します。 EditForm、EntityList、Dashboards などのページタイプは、それらが エンティティにバインドされている 場合で利用可能です。 一部のシナリオでは、フォームがエンティティにバインドされておらず、値が未定義として表示されます。
• formId: formId はフォームを一意に識別し、その特定のフォームに影響する問題を関連付けるために使用できます。
• ホストタイプ: ブラウザ/モバイルアプリケーション/埋め込み
• isBoot: これはセッションの最初のロードですか?
• ロードタイプ
  • 0: 特定のページ タイプへの最初のアクセス (たとえば、フォームへの最初のアクセス)。
  • 1: 特定構成への最初のアクセス (たとえば、取引先企業フォームへの最初のアクセス)。
  • 2: 特定レコードへの最初のアクセス (たとえば、取引先企業レコード A2 への最初のアクセス)。
  • 3: この正確な URL は以前にアクセスされています。
• navigationOrigin: ユーザーが移動したページの種類。
• networkConnectivityState: デバイスが接続されているかどうか。
• pageName: ページの読み込みの種類。
• serverConnectivityState: アプリがサーバーに接続されているかどうか。
• syncRequestTime: 同期リクエストの待機に費やされた時間。
• coldLatency: SSLハンドシェイク時間を含むネットワーク遅延の最初の推定値。
• warmLatency: ネットワーク遅延のその後の推定値。これは、各リクエストの典型的な予想遅延です。
• warmThroughput: ネットワークの推定スループット（Kbps）。

Microsoft Dataverse イベントに対しては、ID フィールドまたは Application Insights の operation_ParentId は x-ms-service-request-id です。operationId は、トラブルシューティングの目的とサポートリクエストのためにバックエンドで activityId をマップします。

UCI アウトバウンド ネットワーク要求にはどのような種類のデータが利用できますか ?

これらは、特定のページをレンダリングするために統一インターフェイスによって行われた他の依存関係への呼び出しです。 これらは Dataverse または Azure DevOps または Office のような他の統合への発信通話である可能性があります。 次のクエリを使用して、このデータを取得します。このデータは、UCI リクエストの依存関係テーブルで利用できます。

dependencies
| where type == "UCI REQUEST"

UCI 要求の依存関係テーブルには、次のフィールドがあります。

• 名前: 統一インターフェイス によって呼び出されるURL。

• ターゲット: 現在は 名前と同じです。

• 成功: 呼び出しが成功したか失敗したかを示します。

• UserId: サインインしたユーザーのシステム ユーザーID。 Dataverse

• 期間: 通話の期間。

• customDimensions: 次の属性が含まれます。

  

  • appModule: 呼び出しを行うappModule。
  • bodySize: エンコードおよびデコードされた 応答 のサイズ。
  • cached: リクエストがローカル キャッシュに送信されたか、サーバーに送信する必要があったか。 エンドユーザーが Internet Explorer ブラウザーにいる場合は、これが機能しませんのでご注意ください。
  • download: 応答 のダウンロードにかかる時間。
  • stall: リクエストがブラウザのキューで待機していた時間。
  • ttfb: 初期対応 を待機するのに費やされた時間。「最初のバイトまでの時間」とも呼ばれます。この時間は、サーバーが 応答 を配信するのを待つ時間に加えて、サーバーへのラウンドトリップの遅延をキャプチャします。
  • coldLatency: SSLハンドシェイク時間を含むネットワーク遅延の最初の推定値。
  • warmLatency: ネットワーク遅延のその後の推定値。これは、各リクエストの典型的な予想遅延です。
  • warmThroughput: ネットワークの推定スループット（Kbps）。

シナリオを発見して分析する

一部のユーザーが統一インターフェイスで速度低下を経験しているのはなぜですか ?

発見と分析が役立つシナリオのひとつは、ある地域 (たとえば、アジア) のユーザーがフォームのパフォーマンスが遅いと報告した場合です。 アジアを拠点とするこのユーザーは、北米の環境または組織にアクセスしている可能性があります。 詳細には、ネットワーク関連の期間に加えて、合計読み込み時間が表示されます。 これが、ユーザーが知覚するパフォーマンスの低下の原因である可能性があります。

warmLatency、ウォームスループット、および coldLatency の属性を使って、次のイメージに示すように、ページの読み込みやその他の統一インターフェイス リクエストに費やされた時間の内訳を理解できます。

上記のリクエストでは、統一インターフェイス リクエストは、実際の Dataverse API (Web API) リクエストよりも時間がかかります。 この場合の内訳は、Dataverse API 呼び出し期間 (56 ミリ秒) に CustomDimensions.warmLatency (89 ミリ秒) を足した値で。これは、操作全体のほぼ継続時間 (144 ミリ秒) になります。 warmLatency の値は、その特定のクライアントの速度が遅いことを示しており、次のクエリを使用してユーザーレベルで分析できる問題である可能性があります。

dependencies
| where ['type'] == "UCI REQUEST"
| summarize avg(toint(customDimensions.warmLatency)), avg(toint(customDimensions.coldLatency)), avg(toint(customDimensions.warmThroughput)) by user_Id

pageViews
| summarize avg(toint(customDimensions.warmLatency)), avg(toint(customDimensions.coldLatency)), avg(toint(customDimensions.warmThroughput)) by user_Id

ユーザーがシステムにアクセスしている方法を確認できますか ?

Application Insightsリクエスト テーブルの customDimensionsのフィールドにある userAgent 属性にはこのデータがあります。 次のクエリを使用して、ユーザーがシステムにアクセスしているさまざまなソースの概要を取得できます。

pageViews
| summarize count() by tostring(customDimensions.userAgent), user_Id

dependencies
| where ['type'] == "UCI REQUEST"

ブラウザ、モバイル、または組み込みアプリケーションからアクセスしているユーザーの数を取得するにはどうすればよいですか ?

pageViews
| summarize count() by tostring(customDimensions.hostType)

次の画像は、このクエリの結果セットの例を示しています。

特定のユーザーに絞り込むにはどうすればよいですか?

pageViews
| where user_Id == "[userid]"
| summarize count() by tostring(customDimensions.hostType)

モニターと組み合わせて Application Insights を使用する方法は?

Azure Monitor は、統一インターフェイス 側からのセッションでのリアルタイムのトラブルシューティングに役立ちます。 エンド ツー エンドのトランザクション リクエストは、おそらく Application Insights で利用可能になります。 特定のアクションのログを確認するには、Monitor のイベント詳細ページの行のアクティビティ ID をメモします。 下記のクエリを使用してログを見つけることができます。

union *
| where operation_Id contains "[ActivityIdHere]"

Monitor はリアルタイムのデバッグツールであることに注意してください。ただし、データが数時間利用できない場合があります。

ユーザーが特定のフォームで問題を経験しているのはなぜですか？

ユーザーは、特定の組織の統一インターフェイスの 詳細 セクションからセッション ID を共有できます。

次に、この ID を使用して、そのセッションのすべてのアクティビティを確認することで問題を見つけることができます。 次のクエリを使用します。

union *
| where session_Id == '[sessionIdHere]'

どのフォームがさまざまな場所で使用されており、これらの場所でのフォームの読み込みパフォーマンスはどのくらいですか ?

pageViews
| summarize avg(duration) by name, client_City, client_CountryOrRegion

外部 API 呼び出しは失敗しますか、そしてデバッグを支援するためにエラースタックにドリルダウンするを入れることはできますか ?

エラー パネルの ブラウザー ビューには、統一インターフェイス送信要求が含まれています。 このリクエストは、Dataverse または組織の URL を含む組織に移動します。 他の URL に送信される他のリクエストがある可能性があります (たとえば、次のイメージでは、組織は dc.services.visualstudio.com を呼び出すカスタマイズを行っています)。 エンドツーエンドのトランザクションを調べて、これらの外部発信コールの失敗をさらに調べることができます。

特定のフォームアクションのパフォーマンスしきい値にアラートを設定できますか ? アラートを受信すると、メーカーは問題を診断してトラブルシューティングできますか ?

有効。 Application Insights で アラート を設定して、アプリケーションの状態を監視します。