Azure Virtual Desktop の分析情報の用語集
この記事では、Azure Virtual Desktop Insights に関連する主な用語と概念を挙げ、簡単に説明します。
アラート
サブスクリプションで構成し、重大度 0 として分類されているアクティブな Azure Monitor のアラートは、すべて概要ページに表示されます。 アラートの設定方法について詳しくは、Azure Monitor のログ アラートに関するページをご覧ください。
使用可能なセッション
使用可能なセッションには、ホスト プールで使用可能なセッション数が表示されます。 この数字は、サービスが仮想マシン (VM) の数と、仮想マシンごとに許可されるセッションの最大数を乗算し、合計セッション数を減算することによって計算されます。
クライアントのオペレーティング システム (OS)
クライアント オペレーティング システム (OS) には、Azure Virtual Desktop リソースにアクセスしているエンドユーザーが現在使用している OS のバージョンが表示されます。 クライアント OS には、ユーザーがどのバージョンの Web (HTML) クライアントとフル リモート デスクトップ クライアントを持っているかも表示されます。 Windows OS バージョンの全一覧については、「オペレーティング システムのバージョン」を参照してください。
接続の成功
この項目は接続の正常性を示します。 "接続の成功" とは、接続がホストに到着し、その仮想マシンのスタックによって確認されたことを意味します。 接続の失敗は、接続がホストに到着しなかったことを意味します。
日次アクティブ ユーザー数 (DAU)
過去 24 時間にセッションを開始したユーザーの合計数。
毎日のアラート数
毎日トリガーされるアラートの総数。
毎日の接続数と再接続数
過去 24 時間以内に開始または完了した接続と再接続の合計数。
毎日の接続時間
過去 24 時間にユーザー間のセッションへの接続に費やした時間の合計数。
診断とエラー
Azure Virtual Desktop Insights にエラーまたはアラートが表示されるときは、次の 3 つの項目に分類されます。
アクティビティの種類: このカテゴリは、Azure Virtual Desktop 診断によるエラーの分類を示します。 カテゴリとは、管理アクティビティ、フィード、接続、ホスト登録、エラー、およびチェックポイントです。 これらのカテゴリの詳細については、「診断機能に Log Analytics を使用する」を参照してください。
種類: このカテゴリには、エラーの場所が表示されます。
- "service" または "ServiceError = TRUE" とマークされたエラーは、Azure Virtual Desktop サービスで発生しています。
- "deployment" とマークされた、または "ServiceError = FALSE" のタグが付いたエラーは Azure Virtual Desktop サービスの外部で発生しています。
- ServiceError タグの詳細については、「一般的なエラーシナリオ」を参照してください。
ソース: このカテゴリは、エラーが発生した場所について、より具体的な説明を示します。
診断: ユーザーがデプロイのイシューを観察して診断できるように、サービス アクティビティの監視とレポートを担当するサービス ロール。
RDBroker: デプロイ アクティビティの調整、オブジェクトの状態の保持、認証の検証などを担当するサービス ロール。
RDGateway: エンドユーザーと仮想マシン間のネットワーク接続の処理を担当するサービス ロール。
RDStack: VM にインストールされていて、Azure Virtual Desktop サービスと通信できるようにするソフトウェア コンポーネント。
クライアント: エンドユーザーのコンピューターで実行されていて、Azure Virtual Desktop サービスへのインターフェイスを提供するソフトウェア。 選択すると、公開されたリソースの一覧を表示し、リモート デスクトップ接続をホストします。
それぞれの診断の問題またはエラーには、どのような問題が発生したかを説明するメッセージが含まれます。 エラーのトラブルシューティングの詳細については、「Azure Virtual Desktop のイシューの特定と診断」を参照してください。
ゲートウェイ リージョン コード
Azure Virtual Desktop Insights の一部のメトリックでは、ユーザーが接続時に通過するゲートウェイ リージョンが一覧表示されます。 ゲートウェイ リージョンは、ゲートウェイが配置されている Azure リージョンに対応する 3 文字または 4 文字のコードで表されます。 次の表に、ゲートウェイ リージョン コードとそれに対応する Azure リージョンを示します。
| ゲートウェイ リージョン コード | Azure リージョン |
|---|---|
| AUC | オーストラリア中部 |
| AUC2 | オーストラリア中部 2 |
| AUE | オーストラリア東部 |
| AUSE | オーストラリア南東部 |
| BRS | ブラジル南部 |
| CAC | カナダ中部 |
| CAE | カナダ東部 |
| CHNO | スイス北部 |
| CIN | インド中部 |
| CUS | 米国中部 |
| EAS | 東アジア |
| EEU | 東ヨーロッパ |
| EUS | 米国東部 |
| EUS2 | 米国東部 2 |
| FRAS | フランス南部 |
| FRC | フランス中部 |
| GEC | ドイツ中部 |
| GEN | ドイツ北部 |
| GENE | ドイツ北東部 |
| GWC | ドイツ中西部 |
| JPE | 東日本 |
| JPW | 西日本 |
| KRC | 韓国中部 |
| KRS | 韓国南部 |
| KRS2 | 韓国南部 2 |
| NCUS | 米国中北部 |
| NEU | 北ヨーロッパ |
| NOE | ノルウェー東部 |
| [NOW] | ノルウェー西部 |
| SAN | 南アフリカ北部 |
| SAW | 南アフリカ西部 |
| SCUS | 米国中南部 |
| SEA2 | 東南アジア 2 |
| SEAS | 東南アジア |
| SIN | インド南部 |
| SWW | スイス西部 |
| UAEC | アラブ首長国連邦中部 |
| UAEN | アラブ首長国連邦北部 |
| UKN | 英国北部 |
| UKS | 英国南部 |
| UKS2 | 英国南部 2 |
| UKW | 英国西部 |
| WCUS | 米国中西部 |
| WEU | 西ヨーロッパ |
| WIN | インド西部 |
| WUS | 米国西部 |
入力遅延
Azure Virtual Desktop Insights の "入力遅延" は、各セッションのプロセス パフォーマンス カウンターごとの入力遅延を意味します。 aka.ms/azmonwvdi のホスト パフォーマンス ページでは、このパフォーマンス カウンターが、30 秒ごとにレポートをサービスに送信するように構成されています。 この 30 秒の間隔は "サンプル" と呼ばれ、その期間で最悪のケースを報告します。 中央値と p95 の値には、すべてのサンプルにおける中央値と 95 パーセンタイルが反映されます。
[ホスト別の入力遅延] で、そのホストに対してページ内の他のすべてのビジュアルをフィルター処理するセッション ホスト行を選択することができます。 また、プロセス名を選択して、時間グラフの中央値の入力遅延をフィルター処理することもできます。
遅延は以下のカテゴリに分類されます。
- 良い: 150 ミリ秒未満。
- 許容範囲内: 150-500 ミリ秒。
- Poor (低い): 500-2,000 ミリ秒 (2 秒未満)。
- Bad (悪い): 2,000 ミリ秒を超える (2 秒以上)。
入力遅延カウンターのしくみの詳細については、ユーザー入力遅延のパフォーマンス カウンターに関する記事を参照してください。
月間アクティブ ユーザー (MAU)
過去 28 日間にセッションを開始したユーザーの合計数。 データを 30 日以内に格納している場合、データの使用可能な期間が 28 日未満になると、MAU と接続値が期待を下回る場合があります。
パフォーマンス カウンター
パフォーマンス カウンターには、ハードウェア コンポーネント、オペレーティング システム、およびアプリケーションのパフォーマンスが表示されます。
次の表に、Azure Monitor が Azure Virtual Desktop で使用する、推奨されるパフォーマンス カウンターと期間を示します。
| パフォーマンス カウンター名 | 間隔 |
|---|---|
| Logical Disk(C:)\Avg.Disk Queue Length | 30 秒 |
| Logical Disk(C:)\Avg.Disk sec/Transfer | 60 秒 |
| Logical Disk(C:)\Current Disk Queue Length | 30 秒 |
| Memory(*)\Available Mbytes | 30 秒 |
| Memory(*)\Page Faults/sec | 30 秒 |
| Memory(*)\Pages/sec | 30 秒 |
| Memory(*)\% Committed Bytes in Use | 30 秒 |
| PhysicalDisk(*)\Avg. Disk Queue Length | 30 秒 |
| PhysicalDisk(*)\Avg. Disk sec/Read | 30 秒 |
| PhysicalDisk(*)\Avg. Disk sec/Transfer | 30 秒 |
| PhysicalDisk(*)\Avg. Disk sec/Write | 30 秒 |
| Processor Information(_Total)\% Processor Time | 30 秒 |
| Terminal Services(*)\Active Sessions | 60 秒 |
| Terminal Services(*)\Inactive Sessions | 60 秒 |
| Terminal Services(*)\Total Sessions | 60 秒 |
| *User Input Delay per Process(*)\Max Input Delay | 30 秒 |
| *User Input Delay per Session(*)\Max Input Delay | 30 秒 |
| RemoteFX Network(*)\Current TCP RTT | 30 秒 |
| RemoteFX Network(*)\Current UDP Bandwidth | 30 秒 |
潜在的な接続のイシュー
潜在的な接続のイシューには、ホスト、ユーザー、公開されたリソース、接続エラー率が高いクライアントが表示されます。 "レポート基準" フィルターを選択すると、次の列の値をチェックして、問題の重大度を評価できます。
- 試行回数 (接続試行の回数)
- リソース (公開されたアプリまたはデスクトップの数)
- ホスト (VM の数)
- クライアント
たとえば、 [ユーザー別] フィルターを選択した場合は、 [試行回数] 列で各ユーザーの接続試行回数を確認できます。
接続のイシューが複数のホスト、ユーザー、リソース、またはクライアントにまたがっている場合は、そのイシューがシステム全体に影響する可能性があります。 そうでない場合は、低優先度の小規模なイシューになります。
また、エントリを選択して追加情報を表示することもできます。 イシューに関連するホスト、リソース、およびクライアントのバージョンを確認できます。 この表示には、接続試行中に報告されたエラーも表示されます。
ラウンドトリップ時間 (RTT)
ラウンドトリップ時間 (RTT) は、エンドユーザーの場所とセッション ホストの Azure リージョンとの間の接続のラウンドトリップ時間の推定値です。 待機時間が最も短い場所を確認するには、「Azure ネットワークのラウンドトリップ待機時間の統計」で目的の場所を調べます。
セッションの履歴
[セッション] 項目には、すべてのセッションの状態と、接続されているか、接続解除されているかが表示されます。 [アイドル セッション] には、接続解除されたセッションのみが表示されます。
重大度 0 のアラート
すぐに対処する必要がある最も緊急度の高い項目。 このような問題に対処しないと、Azure Virtual Desktop のデプロイが動作しなくなる可能性があります。
接続までの時間
接続までの時間は、ユーザーがセッションを開始するためにリソースを開いてから、デスクトップが読み込まれて使用できる状態になるまでの時間です。 たとえば、RemoteApp の場合、これは、アプリケーションの起動に要する時間です。
接続までの時間には、次の 2 つの段階があります。
- 接続。これは、Azure サービスがユーザーをセッション ホストにルーティングするのに要する時間です。
- "ログオン"。これは、サービスが、ユーザーのサインインとセッション ホストでのセッションの確立に関連するタスクを実行するのに要する時間です。
接続までの時間を監視する場合、次の点に注意してください。
接続までの時間は、Azure Virtual Desktop サービスの診断データからの次のチェックポイントで測定されます。 接続が確立されるタイミングを判別するために Insights で使用されるチェックポイントは、デスクトップと RemoteApp のシナリオで異なります。
開始: WVDConnection State = started
終了: WVDCheckpoints Name = ShellReady (デスクトップ)、Name = RdpShellAppExecuted (リモート アプリ。タイミングについては、最初のアプリ起動のみを考慮してください)
たとえば、Insights では、デスクトップ エクスペリエンスが起動するまでの時間は、エクスプローラーの起動にかかる時間に基づいて測定されます。 また、Insights では、接続のためにシェル アプリの最初のインスタンスを起動するためにかかった時間に基づいて、RemoteApp が起動する時間も測定されます。
注意
ユーザーが複数の RemoteApp を起動すると、シェル アプリが 1 つの接続中に複数回実行される場合があります。 接続までの時間を正確に測定するには、接続ごとに最初の実行チェックポイントのみを使用する必要があります。
通常、新しいセッションの確立は、既存のセッションへの接続を再確立するよりも時間がかかります。これは、新しい接続と確立された接続の "ログオン" プロセスが異なるためです。
ユーザーが資格情報を入力するのに時間がかかったり、別の認証方法を使用してサインインしたりする場合を考慮して、ユーザーが資格情報を提供するのにかかる時間は、接続にかかる時間から差し引かれます。
接続までの時間が長い場合のトラブルシューティングでは、Azure Monitor によって合計接続時間のデータが 4 つのコンポーネントに分割されるため、サインイン時間を短縮する方法の特定に役立ちます。
注意
このセクションのコンポーネントは、プライマリ接続段階のみを示します。 これらのコンポーネントは並行して実行できます。つまり、接続にかかる時間が合計されることはありません。 接続までの合計時間は、Azure Monitor によって決定される、個別のプロセスでの測定値です。
次のフローチャートは、サインイン プロセスの 4 つの段階を示しています。
このフローチャートに示されている 4 つのコンポーネントは、次のとおりです。
ユーザー ルート: ユーザーが Azure Virtual Desktop アイコンを選択してセッションを開始してから、サービスによって接続先のホストが識別されるまでにかかる時間。 高いネットワーク負荷が高い場合、サービス負荷が高い場合、または固有のネットワーク トラフィック ルーティングの場合、ルーティング時間が長くなる可能性があります。 ユーザー ルートに関する問題のトラブルシューティングを行うには、ネットワーク パスを確認します。
スタック接続: サービスによってユーザーのターゲット セッション ホストが解決されてから、サービスによってセッション ホストとユーザーのリモート クライアント間で接続が確立されるまでにかかる時間。 ユーザー ルーティングと同様に、ネットワーク負荷、サーバー負荷、または固有のネットワーク トラフィック ルーティングは接続時間に影響を与える可能性があります。 このコンポーネントについては、ネットワーク ルーティングにも注意を払う必要があります。 接続時間を短縮するために、クライアント ホストとセッション ホストの両方ですべてのプロキシ構成が適切に構成されていること、およびサービスへのルーティングが最適であることを確認してください。
ログオン: ホストへの接続が確立され、シェルの読み込みが開始されるまでにかかる時間。 ログオン時間には、接続時間が長くなる原因となる可能性のあるいくつかのプロセスが含まれます。 Insights で "ログオン" 段階のデータを表示して、平均時間に予期しないピークがないかどうかを確認できます。
"ログオン" プロセスは、次の 4 つの段階に分けられます。
プロファイル: 新しいセッションのユーザーのプロファイルを読み込むのにかかる時間。 読み込みにかかる時間は、ユーザー プロファイルのサイズ、または使用しているユーザー プロファイル ソリューション (User Experience Virtualization など) によって異なります。 ネットワークに保存されているプロファイルに依存するソリューションを使用している場合、待機時間が長すぎると、プロファイルの読み込み時間が長くなる可能性もあります。
グループ ポリシー オブジェクト (GPO): グループ ポリシーを新しいセッションに適用するのにかかる時間。 データのこの領域の急増は、グループ ポリシーが多すぎる、ポリシーの適用に時間がかかりすぎる、またはセッション ホストでリソースの問題が発生していることを示しています。 処理時間を最適化するために実行できる 1 つの方法は、ドメイン コントローラーをセッションホストのできるだけ近くに配置することです。
シェルの開始: シェル (通常、explorer.exe) を起動するのにかかる時間。
FSLogix (Frxsvc): 新しいセッションで FSLogix を起動するのにかかる時間。 起動時間が長い場合、FSLogix ユーザー プロファイルをホストするために使用される共有に問題があることを示している可能性があります。 これらの問題のトラブルシューティングを行うには、共有がセッション ホストと同じ場所に配置され、ホストにサインインするユーザーの平均数に合わせて適切にスケーリングされていることを確認します。 確認する必要があるもう 1 つの領域は、プロファイルのサイズです。 プロファイルのサイズが大きい場合、起動時間が遅くなる可能性があります。
シェルの開始からシェルの準備完了まで: シェルの読み込みが開始されてから完全に読み込まれて使用できる状態になるまでの時間。 この段階での遅延は、セッション ホストの過負荷 (CPU またはメモリの高使用率、ディスク アクティビティの増加) または構成の問題が原因で発生する可能性があります。
ユーザー レポート
ユーザー レポートのページでは、特定のユーザーの接続履歴と診断情報を表示できます。 各ユーザー レポートには、使用パターン、ユーザー フィードバック、およびセッション中に発生したすべてのエラーが表示されます。 ほとんどの小さなイシューは、ユーザーからのフィードバックによって解決できます。 さらに詳しく調べる必要がある場合は、特定の接続 ID または期間で情報をフィルター処理することもできます。
コアあたりのユーザー数
これは、各仮想マシン コアのユーザー数です。 時間の経過と共にコアあたりの最大ユーザー数を追跡することで、コアごとの高い、低い、または変化するユーザー数で環境が一貫して実行されるかを判断できます。 アクティブになっているユーザーの数を把握することで、環境を効率的に準備し、スケーリングすることができます。
Windows イベント ログ
Windows イベント ログは、Azure Monitor エージェントまたは Windows 仮想マシン上の Log Analytics エージェントによって収集されるデータ ソースです。 システムやアプリケーションなどの標準ログのイベントに加えて、監視が必要なアプリケーションによって作成されるカスタム ログも収集できます。
次の表に、Azure Virtual Desktop Insights に必要な Windows イベント ログを示します。
| イベント名 | イベントの種類 |
|---|---|
| Application | エラーと警告 |
| Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin | エラー、警告、情報 |
| Microsoft-Windows-TerminalServices-LocalSessionManager/Operational | エラー、警告、情報 |
| システム | エラーと警告 |
| Microsoft-FSLogix-Apps/Operational | エラー、警告、情報 |
| Microsoft-FSLogix-Apps/Admin | エラー、警告、情報 |
次のステップ
- 開始するには、「Azure Virtual Desktop Insights を使用してデプロイを監視する」を参照してください。
- データ ストレージのコストを見積もり、測定、管理には、Azure Monitor コストを見積もるをご覧ください。
- 問題が発生した場合のヘルプや既知の問題については、トラブルシューティング ガイドをご覧ください。
また、Azure Advisor を設定して、一般的なイシューを解決または回避する方法を判断することもできます。 詳細については、「Azure Advisor の概要」を参照してください。
ヘルプが必要な場合、または質問がある場合は、コミュニティ リソースをご確認ください。
Azure Virtual Desktop の TechCommunity で、コミュニティに質問したり提案したりすることができます。
フィードバックを残す方法については、「Azure Virtual Desktop のトラブルシューティングの概要、フィードバック、およびサポート」を参照してください。
また、Azure Virtual Desktop についてのフィードバックは、Azure Virtual Desktop フィードバック ハブにお寄せいただくこともできます