アラートと通知
アラートの監視
アラートは、Directorのダッシュボードやその他の上位レベルのビューに、警告および重大なアラートシンボルとともに表示されます。アラートはPlatinumライセンスのサイトで利用可能です。アラートは1分ごとに自動的に更新されます。また、オンデマンドでアラートを更新することもできます。
警告アラート（琥珀色の三角形）は、条件の警告しきい値に達したか、それを超えたことを示します。
重大なアラート（赤い円）は、条件の重大なしきい値に達したか、それを超えたことを示します。
アラートに関する詳細情報は、サイドバーからアラートを選択するか、サイドバーの下部にあるアラートに移動リンクをクリックするか、Directorページの上部からアラートを選択することで表示できます。
アラートビューでは、アラートをフィルタリングおよびエクスポートできます。たとえば、特定のデリバリーグループの過去1か月間の失敗したサーバーOSマシン、または特定のユーザーのすべてのアラートなどです。詳細については、「レポートのエクスポート」を参照してください。
アラートのフィルター(/ja-jp/xenapp-and-xendesktop/7-15-ltsr/media/Director_FilterAlerts.png)
Citrixアラート。Citrixアラートは、Citrixコンポーネントから発生し、Directorで監視されるアラートです。Citrixアラートは、Directorのアラート > Citrixアラートポリシーで構成できます。構成の一部として、アラートが設定したしきい値を超えたときに、個人やグループに電子メールで通知を送信するように設定できます。通知は、Octoblu WebhookまたはSNMPトラップとして構成することもできます。Citrixアラートの設定の詳細については、「アラートポリシーの作成」を参照してください。
SCOMアラート。SCOMアラートは、Microsoft System Center 2012 Operations Manager (SCOM)からのアラート情報を表示し、Director内でデータセンターの健全性とパフォーマンスをより包括的に示します。詳細については、「SCOMアラート」を参照してください。
サイドバーを展開する前にアラートアイコンの横に表示されるアラートの数は、Citrix®アラートとSCOMアラートの合計です。
アラートポリシーの作成
アラートポリシー(/ja-jp/xenapp-and-xendesktop/7-15-ltsr/media/Director-Alerts-Policy.png)
新しいアラートポリシーを作成するには、たとえば、特定のセッション数基準が満たされたときにアラートを生成する場合：
- 「アラート > Citrixアラートポリシー」に移動し、例えば「サーバーOSポリシー」を選択します。
- 「作成」をクリックします。
- ポリシーに名前を付けて説明し、アラートがトリガーされる条件を設定します。たとえば、ピーク接続セッション、ピーク切断セッション、ピーク同時合計セッションの警告数と危険数を指定します。警告値は危険値より大きくしてはいけません。詳細については、「アラートポリシーの条件」を参照してください。
- 再アラート間隔を設定します。アラートの条件が引き続き満たされている場合、この時間間隔でアラートが再度トリガーされ、アラートポリシーで設定されている場合はメール通知が生成されます。却下されたアラートは、再アラート間隔でメール通知を生成しません。
- スコープを設定します。たとえば、特定のデリバリーグループに設定します。
- 通知設定で、アラートがトリガーされたときに誰にメールで通知するかを指定します。アラートポリシーでメール通知設定を行うには、「メールサーバー構成」タブでメールサーバーを指定する必要があります。
- 「保存」をクリックします。
Octoblu Webhookの構成については、「Octoblu Webhookでアラートポリシーを構成する」を参照してください。
SNMPトラップの構成については、「SNMPトラップでアラートポリシーを構成する」を参照してください。
スコープに20以上のデリバリーグループが定義されたポリシーを作成する場合、構成の完了に約30秒かかることがあります。この間、スピナーが表示されます。
最大20個のユニークなデリバリーグループ（合計1000個のデリバリーグループターゲット）に対して50を超えるポリシーを作成すると、応答時間が増加する（5秒を超える）可能性があります。
アクティブなセッションを含むマシンをあるデリバリーグループから別のデリバリーグループに移動すると、マシンパラメーターを使用して定義された誤ったデリバリーグループアラートがトリガーされる可能性があります。
アラートポリシーの条件
| アラートポリシーの条件 | 説明と推奨されるアクション |
|---|---|
| ピーク接続セッション | ピーク接続セッションの数。Directorのセッショントレンドビューでピーク接続セッションを確認します。セッション負荷に対応できる十分な容量があることを確認します。必要に応じて新しいマシンを追加します。 |
| ピーク切断セッション | ピーク切断セッションの数。Directorのセッショントレンドビューでピーク切断セッションを確認します。セッション負荷に対応できる十分な容量があることを確認します。必要に応じて新しいマシンを追加します。必要に応じて切断されたセッションをログオフします。 |
| ピーク同時合計セッション | ピーク同時セッションの数。Directorのセッショントレンドビューでピーク同時セッションを確認します。セッション負荷に対応できる十分な容量があることを確認します。必要に応じて新しいマシンを追加します。必要に応じて切断されたセッションをログオフします。 |
| CPU | CPU使用率（パーセンテージ）。CPUを消費しているプロセスまたはリソースを特定します。必要に応じてプロセスを終了します。プロセスを終了すると、保存されていないデータは失われます。すべてが期待どおりに機能している場合は、将来的に追加のCPUリソースを追加します。注： ポリシー設定「リソース監視を有効にする」は、VDAがインストールされているマシンでのCPUおよびメモリパフォーマンスカウンターの監視に対して、デフォルトで許可されています。このポリシー設定が無効になっている場合、CPUおよびメモリ条件のアラートはトリガーされません。詳細については、「監視ポリシー」を参照してください。 |
| メモリ | メモリ使用率（パーセンテージ）。メモリを消費しているプロセスまたはリソースを特定します。必要に応じてプロセスを終了します。プロセスを終了すると、保存されていないデータは失われます。すべてが期待どおりに機能している場合は、将来的に追加のメモリを追加します。注： ポリシー設定「リソース監視を有効にする」は、VDAがインストールされているマシンでのCPUおよびメモリパフォーマンスカウンターの監視に対して、デフォルトで許可されています。このポリシー設定が無効になっている場合、CPUおよびメモリ条件のアラートはトリガーされません。詳細については、「監視ポリシー設定」を参照してください。 |
| 接続失敗の発生率 | 過去1時間の接続失敗率（パーセンテージ）。試行された接続の合計に対する失敗の合計に基づいて計算されます。Directorの接続失敗トレンドビューで、構成ログから記録されたイベントを確認します。アプリケーションまたはデスクトップに到達可能かどうかを判断します。 |
| 接続失敗の回数 | 過去1時間の接続失敗数。Directorの接続失敗トレンドビューで、構成ログから記録されたイベントを確認します。アプリケーションまたはデスクトップに到達可能かどうかを判断します。 |
| ICA 応答時間 (平均) | 平均ICAラウンドトリップ時間 根本原因を特定するために、ICA RTTの内訳についてNetScaler HDX Insightを確認してください。NetScalerが利用できない場合は、Directorのユーザー詳細ビューでICA RTTと遅延を確認し、ネットワークの問題かXD/XAの問題かを判断してください。詳細については、NetScaler Insight Centerのドキュメント「ユースケース: HDX Insight」を参照してください。 |
| ICA RTT (セッション数) | しきい値のICAラウンドトリップ時間を超えるセッション数。高いICA RTTを持つセッション数についてNetScaler HDX Insightを確認してください。詳細については、NetScaler Insight Centerのドキュメント「HDX Insightレポート」を参照してください。NetScalerが利用できない場合は、ネットワークチームと協力して根本原因を特定してください。 |
| ICA RTT (セッションの割合) | 平均ICAラウンドトリップ時間を超えるセッションの割合。高いICA RTTを持つセッション数についてNetScaler HDX Insightを確認してください。詳細については、NetScaler Insight Centerのドキュメント「HDX Insightレポート」を参照してください。NetScalerが利用できない場合は、ネットワークチームと協力して根本原因を特定してください。 |
| ICA® 応答時間 (ユーザー) | 指定されたユーザーによって起動されたセッションに適用されるICAラウンドトリップ時間。少なくとも1つのセッションでICA RTTがしきい値より高い場合、アラートがトリガーされます。 |
| 失敗したマシン (デスクトップOS) | 失敗したデスクトップOSマシンの数。失敗は、Directorのダッシュボードおよびフィルタービューに示されているように、さまざまな理由で発生する可能性があります。根本原因を特定するためにCitrix Scout診断を実行してください。詳細については、「ユーザーの問題のトラブルシューティング」を参照してください。 |
| 失敗したマシン (サーバーOS) | 失敗したサーバーOSマシンの数。失敗は、Directorのダッシュボードおよびフィルタービューに示されているように、さまざまな理由で発生する可能性があります。根本原因を特定するためにCitrix Scout診断を実行してください。 |
| 平均ログオン時間 | 過去1時間に発生したログオンの平均ログオン時間。ログオン時間に関する最新のメトリックを取得するには、Directorダッシュボードを確認してください。短期間に多数のユーザーがログオンすると、ログオン時間が長くなる可能性があります。原因を絞り込むために、ログオンのベースラインと内訳を確認してください。詳細については、「ユーザーログオンの問題の診断」を参照してください。 |
| ログオン時間 (ユーザー) | 過去1時間に発生した、指定されたユーザーのログオンのログオン時間。 |
| ロード評価インデックス | 過去5分間のロード評価インデックスの値。ピーク負荷（最大負荷）が発生している可能性のあるサーバーOSマシンについては、Directorで確認してください。ダッシュボード（障害）とトレンドのロード評価インデックスレポートの両方を確認してください。 |
Octoblu Webhook を使用してアラートポリシーを構成する
メール通知とは別に、Octoblu Webhook を使用してアラートポリシーを構成し、IoT サービスを開始できます。
注: この機能には、Delivery Controller バージョン 7.11 以降が必要です。
アラートを利用できる IoT サービスの例としては、サポートスタッフへの SMS 通知の送信や、カスタムインシデント解決プラットフォームとの統合による通知追跡の支援などがあります。
PowerShell コマンドレットを使用して、HTTP コールバックまたは HTTP POST でアラートポリシーを構成できます。これらは Webhook をサポートするように拡張されています。
新しい Octoblu ワークフローの作成と、対応する Webhook URL の取得については、Octoblu Developer Hub を参照してください。
新しいアラートポリシーまたは既存のポリシーに Octoblu Webhook URL を構成するには、次の PowerShell コマンドレットを使用します。
Webhook URL を使用して新しいアラートポリシーを作成する:
$policy = New-MonitorNotificationPolicy -Name <Policy name> -Description <Policy description> -Enabled $true -Webhook <Webhook URL>
既存のアラートポリシーに Webhook URL を追加する:
Set-MonitorNotificationPolicy - Uid <Policy id> -Webhook <Webhook URL>
PowerShell コマンドに関するヘルプについては、PowerShell ヘルプを使用してください。例:
Get-Help <Set-MonitorNotificationPolicy>
アラートポリシーから生成された通知は、Webhook URL への POST 呼び出しで Webhook をトリガーします。POST メッセージには、JSON 形式の通知情報が含まれています。
{"NotificationId" : \<Notification Id\>,
"Target" : \<Notification Target Id\>,
"Condition" : \<Condition that was violated\>,
"Value" : \<Threshold value for the Condition\>,
"Timestamp": \<Time in UTC when notification was generated\>,
"PolicyName": \<Name of the Alert policy\>,
"Description": \<Description of the Alert policy\>,
"Scope" : \<Scope of the Alert policy\>,
"NotificationState": \<Notification state critical, warning, healthy or dismissed\>,
"Site" : \<Site name\>}
<!--NeedCopy-->
SNMP トラップを使用してアラートポリシーを構成する
SNMP トラップで構成されたアラートがトリガーされると、対応する SNMP トラップメッセージは、さらなる処理のために構成されたネットワークリスナーに転送されます。Citrix アラートは、SNMP バージョン 2 以降のトラップをサポートしています。現在、トラップメッセージは1つのリスナーに転送できます。
注： この機能には、Delivery Controllerバージョン7.12以降が必要です。
SNMPトラップを構成するには、次のPowerShellコマンドレットを使用します。
-
現在のSNMPサーバー構成を取得します。
Get-MonitorNotificationSnmpServerConfiguration -
SNMPバージョン2のサーバー構成を設定します。
Set-MonitorNotificationSnmpServerConfiguration -ServerName <Server IP> -PortNumber <Port ID> -SnmpSender <Sender name> -CommunityString public -Protocol V2 -
SNMPバージョン3のサーバー構成を設定します。
$authpass = "<authentication password>" | ConvertTo-SecureString -AsPlainText -Force $privpass = "<Privacy password>" | ConvertTo-SecureString -AsPlainText -Force Set-MonitorNotificationSnmpServerConfiguration -ServerName <Server IP> -PortNumber <Port ID> -SnmpSender <Sender name> -EngineId <Engine Id> -AuthPassword $authpass -PrivPassword $privpass -PrivPasswordProtocol <Privacy password protocol> -AuthPasswordProtocol <Authentication password protocol> -Protocol V3 <!--NeedCopy--> -
既存のアラートポリシーに対してSNMPトラップを有効にします。
Set-MonitorNotificationPolicy -IsSnmpEnabled $true -Uid <Policy ID> -
SNMPトラップ構成で新しいアラートポリシーを作成します。
$policy = New-MonitorNotificationPolicy -Name <Policy name> -IsSnmpEnabled $true -Description <Policy description> -Enabled $true
DirectorからのSNMPトラップメッセージにおけるOIDの構造は次のとおりです。 1.3.6.1.4.1.3845.100.1.<UID> ここで、<UID> は、Directorで定義されたすべてのアラートポリシーに対して連続して生成されます。したがって、OIDは各ユーザー環境で一意です。
- 1.3.6.1.4.1.3845.100.1 を使用して、Directorからのすべてのトラップメッセージをフィルターします。
- 1.3.6.1.4.1.3845.100.1.<UID> を使用して、特定の警告のトラップメッセージをフィルターおよび処理します。
環境で定義されているアラートポリシーのUIDを取得するには、次のコマンドレットを使用します。
Get-MonitorNotificationPolicy
SNMPトラップをSCOMに転送できます。これを行うには、Delivery Controller™でSCOMを構成して、トラップメッセージをリッスンするようにします。
SCOMアラート統合を構成する
SCOMとDirectorの統合により、SCOMからのアラート情報をDirectorのダッシュボードやその他の高レベルビューで表示できます。
SCOMアラートは、Citrixアラートとともに画面に表示されます。サイドバーのSCOMタブからSCOMアラートにアクセスし、ドリルダウンできます。
1か月前までの履歴アラートを表示し、並べ替え、フィルター処理を行い、フィルター処理された情報をCSV、Excel、PDFレポート形式でエクスポートできます。詳細については、「レポートのエクスポート」を参照してください。
SCOM統合は、リモートPowerShell 3.0以降を使用してSCOM管理サーバーからデータをクエリし、ユーザーのDirectorセッションで永続的な実行空間接続を維持します。DirectorとSCOMサーバーは同じPowerShellバージョンである必要があります。
SCOM統合の要件は次のとおりです。
- ウィンドウズ サーバー 2012 R2
- システム センター 2012 R2 オペレーションズ マネージャー
- PowerShell 3.0以降 (DirectorとSCOMサーバーのPowerShellバージョンは一致している必要があります)
- クアッドコアCPU、16 GB RAM (推奨)
- SCOMのプライマリ管理サーバーは、Directorのweb.configファイルで構成する必要があります。これはDirectorConfigツールを使用して実行できます。
注:
- Citrixでは、Director管理者アカウントをSCOMオペレーターロールとして構成し、Directorで完全なアラート情報を取得できるようにすることをお勧めします。これが不可能な場合は、DirectorConfigツールを使用して、web.configファイルでSCOM管理者アカウントを構成できます。
- Citrixでは、最適なパフォーマンスを確保するために、SCOM管理サーバーごとに10を超えるDirector管理者を構成しないことをお勧めします。
ディレクターサーバーで:
-
PowerShellリモート処理を有効にするには、「Enable-PSRemoting」と入力します。
-
SCOM管理サーバーをTrustedHostsリストに追加します。PowerShellプロンプトを開き、次のコマンドを実行します。
- 現在のTrustedHostsリストを取得する
Get-Item WSMAN:\localhost\Client\TrustedHosts
<!--NeedCopy-->
1. Add the FQDN of the SCOM Management Server to the list of TrustedHosts. \<Old Values\> represents the existing set of entries returned from Get-Item cmdlet
Set-Item WSMAN:\localhost\Client\TrustedHosts -Value "<FQDN SCOM Management Server>,<Old Values>"
<!--NeedCopy-->
- DirectorConfigツールを使用してSCOMを構成します。
C:\inetpub\wwwroot\Director\tools\DirectorConfig.exe /configscom
<!--NeedCopy-->
SCOM管理サーバーで:
-
Director管理者をSCOM管理者ロールに割り当てます。
-
SCOM管理コンソールを開き、管理 > セキュリティ > ユーザーロールに移動します。
-
ユーザーロールでは、新しいユーザーロールを作成したり、既存のユーザーロールを変更したりできます。SCOMデータへのアクセスの性質を定義するSCOMオペレーターロールには4つのカテゴリがあります。たとえば、読み取り専用ロールでは管理ペインが表示されず、ルール、マシン、アカウントを検出または管理できません。オペレーターロールは完全な管理者ロールです。
注: Director管理者が非オペレーターロールに割り当てられている場合、次の操作は利用できません。
-
複数の管理サーバーが構成されており、プライマリ管理サーバーが利用できない場合、Director管理者はセカンダリ管理サーバーに接続できません。プライマリ管理サーバーは、Directorのweb.configファイルで構成されているサーバーであり、上記のステップ3でDirectorConfigツールで指定されたサーバーと同じです。セカンダリ管理サーバーは、プライマリサーバーのピア管理サーバーです。
-
アラートをフィルタリングしている間、Director管理者はアラートソースを検索できません。これにはオペレーターレベルの権限が必要です。
-
-
任意のユーザーロールを変更するには、そのロールを右クリックし、プロパティをクリックします。
-
ユーザーロールのプロパティダイアログで、指定されたユーザーロールからDirector管理者を追加または削除できます。
-
-
SCOM管理サーバーのRemote Management UsersグループにDirector管理者を追加します。これにより、Director管理者はリモートPowerShell接続を確立できます。
-
PowerShellリモート処理を有効にするには、Enable-PSRemotingと入力します。
-
WS-Managementプロパティの制限を設定します:
-
MaxConcurrentUsers の値を変更する必要があります:
CLIの場合:
winrm set winrm/config/winrs @{MaxConcurrentUsers = "20"}PSの場合:
Set-Item WSMan:\localhost\Shell\MaxConcurrentUsers 20 -
MaxShellsPerUser の値を変更する必要があります:
CLIの場合:
winrm set winrm/config/winrs @{MaxShellsPerUser="20"}PSの場合:
Set-Item WSMan:\localhost\Shell\MaxShellsPerUser 20 -
Modify MaxMemoryPerShellMB:
CLIの場合:
winrm set winrm/config/winrs @{MaxMemoryPerShellMB="1024"}PSの場合:
Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1024
-
-
混合ドメイン環境でSCOM統合が機能するようにするには、次のレジストリエントリを設定します。
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Key: LocalAccountTokenFilterPolicy
データの種類: DWord
値: 1
注意: レジストリを誤って編集すると、オペレーティングシステムの再インストールが必要になるような深刻な問題が発生する可能性があります。レジストリエディターの誤った使用によって生じる問題が解決できることを、Citrixは保証できません。レジストリエディターはご自身の責任において使用してください。編集する前に必ずレジストリをバックアップしてください。
SCOM統合がセットアップされると、「最新のSCOMアラートを取得できません。詳細については、Directorサーバーのイベントログを参照してください。」というメッセージが表示されることがあります。サーバーのイベントログは、問題の特定と修正に役立ちます。原因としては、次のようなものが考えられます。
- DirectorまたはSCOMマシンでのネットワーク接続の喪失。
- SCOMサービスが利用できないか、応答するにはビジー状態すぎる。
- 構成されたユーザーの権限の変更による認証の失敗。
- SCOMデータの処理中にDirectorでエラーが発生しました。
- ディレクターとSCOMサーバー間のパワーシェルバージョン不一致。