アラートおよび通知

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

Directorのアラート

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

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

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

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

アラートのフィルタリング

Citrixアラート

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

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

定義済みのしきい値を持つ組み込みアラートポリシーのセットは、デリバリーグループおよびマルチセッション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アラートの合計数です。

アラートポリシーの作成

Directorのアラートポリシー

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

  1. [アラート]>[Citrixアラートポリシー]の順に選択し、[マルチセッションOSポリシー]などを選択します。
  2. [Create] をクリックします。
  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診断を実行して、原因を特定します。詳しくは、「ユーザーの問題のトラブルシューティング」を参照してください。

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

    • スコープ: デリバリーグループスコープ
    • しきい値: 警告 - 1、重大 - 2

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

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

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

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

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

平均ログオン期間

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

  • Directorのダッシュボードをチェックし、ログオン処理時間に関する最新の測定基準を取得します。短時間のうちに多数のユーザーがログインするとログオン処理時間が長引くことがあります。
  • 原因を絞り込むため、ログオンのベースラインおよび内訳をチェックします。詳しくは、「ユーザーログオンの問題の診断」を参照してください。

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

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

ログオン処理時間(ユーザー)

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

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

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

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

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

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

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

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

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

アラート サポートされるハイパーバイザー トリガー元 条件 構成
CPU使用率 Citrix Hypervisor、VMware vSphere ハイパーバイザー CPU使用率アラートしきい値に達しているか、超過している アラートしきい値は、ハイパーバイザーで設定する必要があります。
メモリ使用率 Citrix Hypervisor、VMware vSphere ハイパーバイザー メモリ使用率アラートしきい値に達しているか、超過している アラートしきい値は、ハイパーバイザーで設定する必要があります。
ネットワーク使用状況 Citrix Hypervisor、VMware vSphere ハイパーバイザー ネットワーク使用率アラートしきい値に達しているか、超過している アラートしきい値は、ハイパーバイザーで設定する必要があります。
ディスク使用率 VMware vSphere ハイパーバイザー ディスク使用率アラートしきい値に達しているか、超過している アラートしきい値は、ハイパーバイザーで設定する必要があります。
ホスト接続や電源の状態 VMware vSphere ハイパーバイザー ハイパーバイザーホストが再起動されたか、または利用できない アラートはVMware vSphereにあらかじめ組み込まれています。追加の構成は必要ありません。
使用不可のハイパーバイザー接続 Citrix Hypervisor、VMware vSphere Delivery Controller ハイパーバイザー(プールまたはクラスター)への接続が失われるか、電源がオフになるか、再起動されます。このアラートは、接続が利用できない間、1時間ごとに生成されます。 アラートはDelivery Controllerにあらかじめ組み込まれています。追加の構成は必要ありません。

注:

アラートの構成について詳しくは、「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コンポーネント図

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管理者がオペレーター以外の役割に割り当てられている場合、以下の操作を実行できません:

    > -  If there are multiple management servers configured and the primary management server is not available, the Director administrator cannot connect to the secondary management server. The primary management server is the server configured in the Director web.config file, that is the same server as the one specified with the DirectorConfig tool in step 3 above. The secondary management servers are peer management servers of the primary server.
    > -  While filtering alerts, the Director administrator cannot search for the alert source. This requires an operator level permission.
    
    1. ユーザー役割を変更するには、役割を右クリックし、[プロパティ]をクリックします。

    2. [ユーザーロールのプロパティ]ダイアログで、指定したユーザー役割に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バージョンが不一致。
アラートおよび通知