アラートおよび通知

アラートは、Directorのダッシュボードおよびそのほかの概要ビューに、警告および重大アラートシンボルと共に表示されます。アラートは、Premiumライセンスを持つユーザーが使用できます。アラートは、1分ごとに自動的に更新されます。オンデマンドで更新することもできます。

警告アラート（黄色の三角形）は、条件の警告しきい値以上になっていることを示します。

重大アラート（赤の円）は、条件の重大しきい値以上になっていることを示します。

サイドバーでアラートを選択して下部にある ［アラートに移動］ リンクをクリックするか、［Director］ページの上部にある ［アラート］ を選択すると、アラートに関するさらに詳細な情報を表示できます。

［アラート］ビューで、アラートをフィルターおよびエクスポートできます。たとえば、先月特定のデリバリーグループで失敗したマルチセッションOSマシンや、特定のユーザーに対するすべてのアラートを特定することができます。詳しくは、「レポートのエクスポート」を参照してください。

Citrixアラート

Citrixアラートは、Citrixコンポーネントで発生し、Directorで監視されるアラートです。Citrixアラートは、Director内で［アラート］>［Citrixアラートポリシー］の順に選択して構成できます。この構成では、設定したしきい値を超過した場合のアラートに関して、ユーザーおよびグループにメール送信する通知を設定できます。Citrixアラートのセットアップについて詳しくは、「アラートポリシーの作成」を参照してください。

注：

ファイアウォール、プロキシ、またはMicrosoft Exchange Serverがメール通知をブロックしないようにしてください。

スマートアラートポリシー

定義済みのしきい値を持つ組み込みアラートポリシーのセットは、デリバリーグループおよびマルチセッションOS VDAスコープで使用できます。この機能には、Delivery Controllerバージョン7.18以降が必要です。［アラート］>［Citrixアラートポリシー］ で、組み込みアラートポリシーのしきい値パラメーターを変更できます。 これらのポリシーは、少なくとも1つのアラートターゲット（サイト内に定義されているデリバリーグループまたはマルチセッションOS VDA）が存在する場合に作成されます。さらに、これらの組み込みアラートは、新しいデリバリーグループまたはマルチセッションOS VDAに自動的に追加されます。

Directorとサイトをアップグレードする場合、以前のDirectorインスタンスのアラートポリシーが引き継がれます。対応するアラートルールが監視データベースに存在しない場合にのみ、組み込みアラートポリシーが作成されます。

組み込みアラートポリシーのしきい値については、「アラートポリシーの条件」を参照してください。

SCOMアラート

SCOMアラートには、Microsoft System Center 2012 Operations Manager（SCOM）からのアラート情報が表示されます。これにより、Director内のデータセンターの稼働状態およびパフォーマンスがより包括的に示されます。詳しくは、「SCOMアラート統合の構成」を参照してください。

サイドバーを展開する前にアラートアイコンの隣に表示されているアラートの数は、CitrixアラートとSCOMアラートの合計数です。

アラートポリシーの作成

特定のセッション数基準のセットを満たした場合にアラートを生成するなどの目的で、新しいアラートポリシーを作成するには、以下の手順に従います：

1. ［アラート］>［Citrixアラートポリシー］の順に選択し、［マルチセッションOSポリシー］などを選択します。
2. ［作成］ をクリックします。
3. ポリシーの名前と説明を入力し、アラートをトリガーするために満たす必要がある条件を設定します。たとえば、最大接続済みセッション数、最大切断セッション数、および最大同時セッション数に対して、警告とする数および重大とする数を指定します。警告値を重大値よりも大きくすることはできません。詳しくは、「アラートポリシーの条件」を参照してください。
4. 再アラート間隔を設定します。アラートの条件が引き続き満たされている場合、アラートはこの間隔で再トリガーされます。アラートポリシーで設定されている場合は、メール通知が生成されます。クリアされたアラートの場合、再アラート間隔でメール通知が生成されることはありません。
5. スコープを設定します。たとえば、特定のデリバリーグループに対して設定します。
6. お知らせ設定で、アラートがトリガーされたときのメール通知の送信先を指定します。アラートポリシーでメールお知らせ設定を行うには、［メールサーバーの構成］ タブでメールサーバーを指定する必要があります。
7. ［保存］をクリックします。

スコープに20件以上のデリバリーグループが定義されているポリシーを作成すると、構成が完了するまでにおよそ30秒かかる場合があります。完了するまで、スピナーアイコンが表示されます。

最大20の一意のデリバリーグループに対して、50以上のポリシー（合計で1000デリバリーグループターゲット）を作成すると、応答時間が遅くなることがあります（5秒以上）。

アクティブなセッションがあるマシンをデリバリーグループから別のデリバリーグループに移動すると、マシンパラメーターで定義されたデリバリーグループアラートが誤って発信されることがあります。

アラートポリシーの条件

アラートカテゴリ、アラートを緩和するための推奨アクション、および定義されている場合は組み込みポリシーの条件を以下に示します。組み込みアラートポリシーは、60分のアラートおよび再アラートの間隔で定義されています。

最大切断セッション数

• Directorセッションの傾向ビューで、最大接続済みセッション数をチェックします。
• セッションの負荷に対応するのに十分な処理能力があることを確認します。
• 必要に応じ、マシンを追加します。

最大切断セッション数

• Directorセッションの傾向ビューで、最大切断セッション数をチェックします。
• セッションの負荷に対応するのに十分な処理能力があることを確認します。
• 必要に応じ、マシンを追加します。
• 必要に応じ、切断されたセッションからログオフします。

合計最大同時セッション数

• Directorセッションの傾向ビューで、最大同時セッション数をチェックします。
• セッションの負荷に対応するのに十分な処理能力があることを確認します。
• 必要に応じ、マシンを追加します。
• 必要に応じ、切断されたセッションからログオフします。

CPU

CPU使用率は、プロセスも含めたVDAの全体的なCPUの消費を示します。関連VDAの ［マシンの詳細］ ページで個別のプロセスによるCPU使用率に関する情報を表示できます。

• ［マシンの詳細］>［履歴使用率の表示］>［上位10位のプロセス］ に移動して、CPUを消費しているプロセスを確認します。プロセス監視ポリシーが有効になっていることを確認して、プロセスレベルのリソース使用統計の収集を開始します。
• 必要に応じてプロセスを終了します。
• プロセスを終了すると、保存されていないデータは失われます。

• すべてが想定どおりに機能している場合は、将来的にCPUリソースを追加します。

  注：

  ポリシー設定 ［リソースの監視を有効にします］ はデフォルトで有効で、VDAがインストールされているマシンのCPUとメモリパフォーマンスカウンターを監視できます。このポリシー設定が無効にされると、CPUとメモリの条件に関するアラートはトリガーされません。詳しくは、「監視のポリシー設定」を参照してください。

  スマートポリシーの条件：

  • スコープ： デリバリーグループ、マルチセッションOSスコープ
  • しきい値： 警告 - 80%、重大 - 90%

メモリ

メモリ使用率は、プロセスも含めたVDAの全体的なメモリの消費を示します。関連VDAの ［マシンの詳細］ ページで個別のプロセスによるメモリ使用率に関する情報を表示できます。

• ［マシンの詳細］>［履歴使用率の表示］>［上位10位のプロセス］ に移動して、メモリを消費しているプロセスを確認します。プロセス監視ポリシーが有効になっていることを確認して、プロセスレベルのリソース使用統計の収集を開始します。
• 必要に応じてプロセスを終了します。
• プロセスを終了すると、保存されていないデータは失われます。

• すべてが想定どおりに機能している場合は、将来的にメモリを追加します。

  注：

  ポリシー設定 ［リソースの監視を有効にします］ はデフォルトで有効で、VDAがインストールされているマシンのCPUとメモリパフォーマンスカウンターを監視できます。このポリシー設定が無効にされると、CPUとメモリの条件に関するアラートはトリガーされません。詳しくは、「監視のポリシー設定」を参照してください。

  スマートポリシーの条件：

  • スコープ： デリバリーグループ、マルチセッションOSスコープ
  • しきい値： 警告 - 80%、重大 - 90%

接続エラー率

過去1時間の接続エラーの率。

• 接続の合計試行回数に対する合計エラー数の割合に基づいて計算されます。
• Director接続エラーの傾向ビューで、構成ログから記録されたイベントをチェックします。
• アプリケーションまたはデスクトップにアクセスできるかどうかを確認します。

接続エラー数

過去1時間の接続エラー数。

• Director接続エラーの傾向ビューで、構成ログから記録されたイベントをチェックします。
• アプリケーションまたはデスクトップにアクセスできるかどうかを確認します。

ICA往復時間（平均）

平均ICA往復時間

• Citrix ADMでICA RTTのブレークダウンをチェックして、原因を特定します。詳しくは、Citrix ADMのドキュメントを参照してください。
• Citrix ADMが利用可能でない場合は、Directorの［ユーザーの詳細］ビューでICA RTTおよび遅延をチェックして、これがネットワークの問題か、それともアプリケーションやデスクトップの問題かを特定します。

ICA往復時間（セッション数）

ICA往復時間を超過しているセッションの数。

• Citrix ADMで、ICA RTTが高いセッションの数をチェックします。詳しくは、Citrix ADMのドキュメントを参照してください。

• Citrix ADMが利用可能でない場合は、ネットワークチームと協力して原因を特定してください。

  スマートポリシーの条件：

  • スコープ： デリバリーグループ、マルチセッションOSスコープ
  • しきい値： 警告 - 5つ以上のセッションで300ms、重大 - 10以上のセッションで400ms

ICA往復時間（セッションの%）

平均ICA往復時間を超過しているセッションの割合。

• Citrix ADMで、ICA RTTが高いセッションの数をチェックします。 詳しくは、Citrix ADMのドキュメントを参照してください。
• Citrix ADMが利用可能でない場合は、ネットワークチームと協力して原因を特定してください。

ICA RTT（ユーザー）

特定のユーザーによって開始されたセッションに適用されたICA往復時間。1つ以上のセッションでICA RTTがしきい値よりも高い場合は、アラートがトリガーされます。

障害が発生したマシン（シングルセッションOS）

障害が発生したシングルセッション​OSマシンの数。Directorの［ダッシュボード］ビューおよび［フィルター］ビューに表示されるように、失敗はさまざまな理由で発生することがあります。

• Citrix Scout診断を実行して、原因を特定します。

  スマートポリシーの条件：

  • スコープ： デリバリーグループ、マルチセッションOSスコープ
  • しきい値： 警告 - 1、重大 - 2

障害が発生したマシン（マルチセッションOS）

失敗したマルチセッションOSマシンの数。Directorの［ダッシュボード］ビューおよび［フィルター］ビューに表示されるように、失敗はさまざまな理由で発生することがあります。

• Citrix Scout診断を実行して、原因を特定します。

  スマートポリシーの条件：

  • スコープ： デリバリーグループ、マルチセッションOSスコープ
  • しきい値： 警告 - 1、重大 - 2

障害が発生したマシン（%）

障害が発生したマシンの数に基づいて計算された、デリバリーグループ内の障害が発生したシングルセッションおよびマルチセッションOSマシンの割合。アラートの条件を設定する際、アラートのしきい値をデリバリーグループ内の障害が発生したマシンの割合で構成できます。この条件は30秒ごとに計算されます。 Directorの［ダッシュボード］ビューおよび［フィルター］ビューに表示されるように、失敗はさまざまな理由で発生することがあります。Citrix Scout診断を実行して、原因を特定します。詳しくは、「ユーザーの問題のトラブルシューティング」を参照してください。

平均ログオン時間

過去1時間に行われたログオンの平均ログオン処理時間。

• Directorのダッシュボードをチェックし、ログオン処理時間に関する最新の測定基準を取得します。短時間のうちに多数のユーザーがログインするとログオン処理時間が長引くことがあります。

• 原因を絞り込むため、ログオンのベースラインおよび内訳をチェックします。詳しくは、「ユーザーログオンの問題の診断」を参照してください。

  スマートポリシーの条件：

  • スコープ： デリバリーグループ、マルチセッションOSスコープ
  • しきい値： 警告 - 45秒、重大 - 60秒

ログオン処理時間（ユーザー）

過去1時間に行われた指定されたユーザーのログオンに関するログオン処理時間。

負荷評価基準インデックス

過去5分間の負荷評価基準インデックスの値。

• Directorで、ピーク負荷（最大負荷）に達している可能性があるマルチセッションOSマシンをチェックします。ダッシュボード（失敗）および負荷評価基準インデックス傾向レポートを表示します。

  スマートポリシーの条件：

  • スコープ： デリバリーグループ、マルチセッションOSスコープ
  • しきい値： 警告 - 80%、重大 - 90%

ハイパーバイザーアラートの監視

Directorでは、ハイパーバイザーの正常性を監視するアラートが表示されます。Citrix HypervisorとVMware vSphereのアラートは、ハイパーバイザーのパラメーターと状態を監視するのに役立ちます。ハイパーバイザーへの接続状態も監視され、クラスターまたはホストのプールが再起動された場合、または使用できなくなった場合にアラートが出されます。

ハイパーバイザーアラートを受信するには、Web Studioでホスト接続が作成されている必要があります。詳しくは、「接続およびリソース」を参照してください。ハイパーバイザーアラートではこれらの接続のみが監視されます。次の表に、ハイパーバイザーアラートのさまざまなパラメーターと状態を示します。

注：

アラートの構成について詳しくは、「Citrix XenCenterアラート」を参照するか、VMware vCenterアラートのドキュメントを確認してください。

メール通知設定は、［Citrixアラートポリシー］>［サイトポリシー］>［ハイパーバイザーの正常性］ から設定できます。Hypervisorのアラートポリシーのしきい値条件は、Directorからではなくハイパーバイザーからのみ設定、編集、無効化、または削除できます。ただし、メール設定の変更とアラートの解除はDirectorで行うことができます。

重要：

• アラートはHypervisorにより取得され、Directorに表示されます。ただし、Hypervisorのアラートのライフサイクルや状態に対する変更は、Directorには反映されません。
• 正常状態のアラートやHypervisorコンソールで破棄または無効化したアラートであっても、Directorには表示され続けるため、Directorで明示的に破棄する必要があります。
• アラートをDirectorで破棄しても、Hypervisorコンソールで自動的に破棄されることはありません。

ハイパーバイザーアラートのみをフィルタリングできるように、「ハイパーバイザーの正常性」という新しいアラートカテゴリが追加されました 。これらのアラートは、しきい値に達するか超過すると表示されます。ハイパーバイザーのアラートには次のものがあります：

• 重大—ハイパーバイザーアラームポリシーの重大しきい値に達したか超過した
• 警告—ハイパーバイザーアラームポリシーの警告しきい値に達したか超過した
• 解除—アラートはアクティブなアラートとして表示されなくなる

この機能の使用には、Delivery Controllerバージョン7 1811以降が必要です。サイトの7 1811以降で古いバージョンのDirectorを使用している場合は、ハイパーバイザーアラート数のみが表示されます。アラートを表示するには、Directorをアップグレードする必要があります。

SCOMアラート統合の構成

DirectorとのSCOM統合により、SCOMからのアラート情報を、Directorのダッシュボードおよびそのほかの概要ビューで表示できるようになります。

SCOMアラートは、Citrixアラートと共に画面上に表示されます。SCOMアラートには、サイドバーの［SCOM］タブからアクセスしてドリルダウンすることができます。

1か月前までの過去のアラートを表示し、情報を並べ替えてフィルターし、フィルターされた情報をCSV、Excel、およびPDFレポート形式にエクスポートすることができます。詳しくは、「レポートのエクスポート」を参照してください。

SCOM統合では、リモートPowerShell 3.0以降を使用してSCOM管理サーバーのデータをクエリし、ユーザーのDirectorセッションで永続的な実行空間接続を維持します。DirectorおよびSCOMサーバーのPowerShellバージョンが同じである必要があります。

SCOM統合の要件は、以下のとおりです：

• Windows Server 2012 R2
• System Center 2012 R2 Operations Manager
• PowerShell 3.0以上（DirectorおよびSCOMサーバーのPowerShellバージョンは一致する必要があります）
• クアッドコアCPUと16GBのRAM（推奨）
• SCOMのプライマリ管理サーバーは、Directorのweb.configファイルで構成する必要があります。この処理は、DirectorConfigツールを使用して実行できます。

Director管理者アカウントをSCOMオペレーターの役割として構成することをお勧めします。これにより、管理者がDirectorで完全なアラート情報を取得できるようになります。そのように構成できない場合、DirectorConfigツールを使用してSCOM管理者アカウントをweb.configファイルに構成できます。

これに加えて、最適なパフォーマンスを得るために、構成するDirector管理者の数は、1つのSCOM管理サーバーにつき10人以下とすることをお勧めします。

Directorサーバーで、以下を実行します：

1. コマンド Enable-PSRemoting を実行して、PowerShellリモート処理を有効にします。

2. SCOM管理サーバーをTrustedHosts一覧に追加します。PowerShellプロンプトを開いて、次のコマンドを実行します：

   • 最新のTrustedHosts一覧を取得します。

     Get-Item WSMAN:\localhost\Client\TrustedHosts

   • SCOM管理サーバーのFQDNを、TrustedHostsの一覧に追加します。<Old Values>は、Get-Itemコマンドレットから返された既存エントリのセットを表します。

     Set-Item WSMAN:localhostClientTrustedHosts -Value “<FQDN SCOM Management Server>,<Old Values>”

3. DirectorConfigツールを使用して、SCOMを構成します。

   C:\inetpub\wwwroot\Director\tools\DirectorConfig.exe /configscom

SCOM管理サーバーで、以下を実行します：

1. SCOM管理者の役割に、Director管理者を割り当てます。

   1. SCOM管理コンソールを開き、［管理］>［セキュリティ］>［ユーザーロール］ の順に選択します。

   2. ［ユーザーロール］では、新しいユーザー役割を作成するか、または既存のユーザー役割を変更することができます。SCOMデータへのアクセス方法を定義するSCOMオペレーターの役割には4つのカテゴリがあります。たとえば、読み取り専用の役割には、［管理］ペインが表示されず、規則、マシン、アカウントを検出または管理することができません。オペレーターの役割は、すべての管理権限を実行できる管理者の役割です。

      注：

      Director管理者がオペレーター以外の役割に割り当てられている場合、以下の操作を実行できません：

      • 複数の管理サーバーが構成されており、プライマリ管理サーバーを利用できない場合、Director管理者はセカンダリ管理サーバーに接続できません。プライマリ管理サーバーはDirectorのweb.configファイルで構成されるサーバーであり、前述の手順3でDirectorConfigツールで指定されたサーバーです。セカンダリ管理サーバーは、プライマリサーバーのピア管理サーバーです。
      • アラートのフィルター時に、Director管理者はアラートソースを検索できません。検索するには、オペレーターレベルの権限が必要です。

   3. ユーザー役割を変更するには、役割を右クリックし、［プロパティ］をクリックします。

   4. ［ユーザーロールのプロパティ］ダイアログで、指定したユーザー役割にDirector管理者を追加するか、またはそこからDirector管理者を削除することができます。

2. Director管理者を、SCOM管理サーバーの［Remote Management Users］グループに追加します。これにより、Director管理者がリモートPowerShell接続を確立できるようになります。

3. コマンド Enable-PSRemoting を実行して、PowerShellリモート処理を有効にします。

4. WS-Managementプロパティ制限を設定します：

   1. MaxConcurrentUsersの変更：

      CLI：

      ```winrm set winrm/config/winrs @{MaxConcurrentUsers = “20”}

      
      PS：
      
      ```Set­-Item WSMan:\localhost\Shell\MaxConcurrentUsers 20<!--NeedCopy-->
      

   2. MaxShellsPerUserの変更：

      CLI：

      winrm set winrm/config/winrs @{MaxShellsPerUser="20"}<!--NeedCopy-->

      PS：

   ```Set-Item WSMan:\localhost\Shell\MaxShellsPerUser 20

   
   1.  MaxMemoryPerShellMBの変更：
   
       CLI：
   
       ```winrm set winrm/config/winrs @{MaxMemoryPerShellMB="1024"}<!--NeedCopy-->
   

   PS：
   

   Set­-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1024<!--NeedCopy-->

5. SCOM統合が混在ドメイン環境で機能するよう、以下のレジストリエントリを設定します。

パス：HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

値の名前：LocalAccountTokenFilterPolicy

種類：DWord

値：1

注意： レジストリエディターの使用を誤ると、深刻な問題が発生する可能性があり、Windowsの再インストールが必要になる場合もあります。レジストリエディターの誤用による障害に対して、Citrixでは一切責任を負いません。レジストリエディターは、お客様の責任と判断の範囲でご使用ください。また、レジストリファイルのバックアップを作成してから、レジストリを編集してください。

SCOM統合がセットアップされると、メッセージ「Cannot get the latest SCOM alerts. View the Director server event logs for more information」が表示されることがあります。サーバーイベントログを使用して問題を特定し、解決することができます。次の原因が考えられます。

• DirectorまたはSCOMマシンで、ネットワーク接続が失われた。
• SCOMサービスが利用できないか、ビジー状態のため応答していない。
• 構成したユーザーの権限が変更されていたため、認証に失敗した。
• SCOMデータの処理中に、Directorでエラーが発生した。
• DirectorとSCOMサーバーのPowerShellバージョンが不一致。