アラートおよび通知
アラートの監視
アラートは、Directorのダッシュボードおよびそのほかの概要ビューに、警告および重大アラートシンボルと共に表示されます。アラートは、Platinumライセンスを持つユーザーが使用できます。アラートは、1分ごとに自動的に更新されます。オンデマンドで更新することもできます。
警告アラート（黄色の三角形）は、条件の警告しきい値以上になっていることを示します。
重大アラート（赤の円）は、条件の重大しきい値以上になっていることを示します。
サイドバーでアラートを選択して下部にある ［アラートに移動］ リンクをクリックするか、［Director］ページの上部にある ［アラート］ を選択すると、アラートに関するさらに詳細な情報を表示できます。
［アラート］ビューで、アラートをフィルターおよびエクスポートできます。たとえば、先月特定のデリバリーグループで失敗したサーバーOSマシンや、特定のユーザーに対するすべてのアラートを特定することができます。詳しくは、「レポートのエクスポート」を参照してください。
Citrixアラート：Citrixアラートは、Citrixコンポーネントで発生し、Directorで監視されるアラートです。Citrixアラートは、Director内で［アラート］>［Citrixアラートポリシー］の順に選択して構成できます。この構成では、設定したしきい値を超過した場合のアラートに関して、ユーザーおよびグループにメール送信する通知を設定できます。通知は、Octoblu webhookまたはSNMPトラップとしても構成できます。Citrixアラートのセットアップについて詳しくは、「アラートポリシーの作成」を参照してください。
SCOMアラート：SCOMアラートには、Microsoft System Center 2012 Operations Manager（SCOM）からのアラート情報が表示されます。これにより、Director内のデータセンターの稼働状態およびパフォーマンスがより包括的に示されます。詳しくは、「SCOMアラート」を参照してください。
サイドバーを展開する前にアラートアイコンの隣に表示されているアラートの数は、CitrixアラートとSCOMアラートの合計数です。
アラートポリシーの作成
特定のセッション数基準のセットを満たした場合にアラートを生成するなどの目的で、新しいアラートポリシーを作成するには、以下の手順に従います：
- ［アラート］>［Citrixアラートポリシー］の順に選択し、［サーバーOSポリシー］などを選択します。
- ［Create］ をクリックします。
- ポリシーの名前と説明を入力し、アラートをトリガーするために満たす必要がある条件を設定します。たとえば、最大接続済みセッション数、最大切断セッション数、および最大同時セッション数に対して、警告とする数および重大とする数を指定します。警告値を重大値よりも大きくすることはできません。詳しくは、「アラートポリシーの条件」を参照してください。
- 再アラート間隔を設定します。アラートの条件が引き続き満たされている場合、アラートはこの間隔で再トリガーされます。アラートポリシーで設定されている場合は、メール通知が生成されます。クリアされたアラートの場合、再アラート間隔でメール通知が生成されることはありません。
- スコープを設定します。たとえば、特定のデリバリーグループに対して設定します。
- お知らせ設定で、アラートがトリガーされたときのメール通知の送信先を指定します。アラートポリシーでメールお知らせ設定を行うには、［メールサーバーの構成］ タブでメールサーバーを指定する必要があります。
- ［保存］ をクリックします。
Octoblu webhook構成について詳しくは、「Octoblu webhookによるアラートポリシーの構成」を参照してください。
SNMPトラップ構成について詳しくは、「SNMPトラップによるアラートポリシーの構成」を参照してください。
スコープに20件以上のデリバリーグループが定義されているポリシーを作成すると、構成が完了するまでにおよそ30秒かかる場合があります。完了するまで、スピナーアイコンが表示されます。
最大20の一意のデリバリーグループに対して、50以上のポリシー（合計で1000デリバリーグループターゲット）を作成すると、応答時間が遅くなることがあります（5秒以上）。
アクティブなセッションがあるマシンをデリバリーグループから別のデリバリーグループに移動すると、マシンパラメーターで定義されたデリバリーグループアラートが誤って発信されることがあります。
アラートポリシーの条件
| アラートポリシーの条件 | 説明および推奨される操作 |
|---|---|
| 最大接続セッション数 | 最大接続済みセッションの数。Directorセッションの傾向ビューで、最大接続済みセッション数をチェックします。セッションの負荷に対応するのに十分な処理能力があることを確認します。必要に応じ、マシンを追加します。 |
| 最大切断セッション数 | 最大切断セッションの数。Directorセッションの傾向ビューで、最大切断セッション数をチェックします。セッションの負荷に対応するのに十分な処理能力があることを確認します。必要に応じ、マシンを追加します。必要に応じ、切断されたセッションからログオフします。 |
| 合計最大同時セッション数 | 最大同時セッションの数。Directorセッションの傾向ビューで、最大同時セッション数をチェックします。セッションの負荷に対応するのに十分な処理能力があることを確認します。必要に応じ、マシンを追加します。必要に応じ、切断されたセッションからログオフします。 |
| CPU | CPUの使用率（%）。CPUを消費しているプロセスやリソースを特定します。必要に応じてプロセスを終了します。プロセスを終了すると、保存されていないデータは失われます。すべてが想定どおりに機能している場合は、将来的にCPUリソースを追加します。注： ポリシー設定［リソースの監視を有効にします］はデフォルトで有効で、VDAがインストールされているマシンのCPUとメモリパフォーマンスカウンターを監視できます。このポリシー設定が無効にされると、CPUとメモリの状況に関するアラートがトリガーされます。詳しくは、「監視のポリシー設定」を参照してください。 |
| メモリ | メモリの使用率（%）。メモリを消費しているプロセスやリソースを特定します。必要に応じてプロセスを終了します。プロセスを終了すると、保存されていないデータは失われます。すべてが想定どおりに機能している場合は、将来的にメモリを追加します。注： ポリシー設定［リソースの監視を有効にします］はデフォルトで有効で、VDAがインストールされているマシンのCPUとメモリパフォーマンスカウンターを監視できます。このポリシー設定が無効にされると、CPUとメモリの状況に関するアラートがトリガーされます。詳しくは、「監視のポリシー設定」を参照してください。 |
| 接続エラー率 | 過去1時間の接続エラーの率。接続の合計試行回数に対する合計エラー数の割合に基づいて計算されます。Director接続エラーの傾向ビューで、構成ログから記録されたイベントをチェックします。アプリケーションまたはデスクトップにアクセスできるかどうかを確認します。 |
| 接続エラー数 | 過去1時間の接続エラー数。Director接続エラーの傾向ビューで、構成ログから記録されたイベントをチェックします。アプリケーションまたはデスクトップにアクセスできるかどうかを確認します。 |
| ICA往復時間（平均） | 平均ICA往復時間。NetScaler HDX InsightでICA RTTの詳細を確認して、根本原因を特定します。NetScalerが利用可能でない場合は、［Directorのユーザー詳細］ビューでICA RTTと遅延をチェックし、これがネットワークの問題か、またはXD/XAの問題かを特定します。詳しくは、NetScaler Insight Centerのドキュメント「HDX Insight」を参照してください。 |
| ICA往復時間（セッション数） | ICA往復時間を超過しているセッションの数。NetScaler HDX Insightで、ICA RTTが高いセッションの数をチェックします。詳しくは、NetScaler Insight Centerのドキュメント「HDX Insightのレポート」を参照してください。NetScalerが利用可能でない場合は、ネットワークチームと協力し根本原因を特定してください。 |
| ICA RTT（セッションの%） | 平均ICA往復時間を釣果しているセッションの割合（%）。NetScaler HDX Insightで、ICA RTTが高いセッションの数をチェックします。詳しくは、NetScaler Insight Centerのドキュメント「HDX Insightのレポート」を参照してください。NetScalerが利用可能でない場合は、ネットワークチームと協力し根本原因を特定してください。 |
| ICA RTT（ユーザー） | 特定のユーザーが開始したセッションに適用されるICA往復時間。1つ以上のセッションでICA RTTがしきい値よりも高い場合は、アラートがトリガーされます。 |
| 障害が発生したマシン（デスクトップOS） | 失敗したデスクトップOSマシンの数。Directorの［ダッシュボード］ビューおよび［フィルター］ビューに表示されるように、エラーはさまざまな理由で発生します。Citrix Scout診断を実行して、原因を特定します。詳しくは、「ユーザーの問題のトラブルシューティング」を参照してください。 |
| 障害が発生したマシン（サーバーOS） | 失敗したサーバーOSマシンの数。Directorの［ダッシュボード］ビューおよび［フィルター］ビューに表示されるように、エラーはさまざまな理由で発生します。Citrix Scout診断を実行して、原因を特定します。 |
| 平均ログオン期間 | 過去1時間に行われたログオンの平均ログオン処理時間。Directorのダッシュボードをチェックし、ログオンの処理時間に関する最新のメトリックを取得します。短時間のうちに多数のユーザーがログインすると、ログオンに時間がかかる場合があります。原因を絞り込むため、ログオンのベースラインおよび内訳をチェックします。詳しくは、「ユーザーログオンの問題の診断」を参照してください。 |
| ログオン処理時間（ユーザー） | 過去1時間に行われた指定されたユーザーのログオンに関するログオン処理時間。 |
| 負荷評価基準インデックス | 過去5分間の負荷評価基準インデックスの値。Directorで、ピーク負荷（最大負荷）に達している可能性があるサーバーOSマシンをチェックします。ダッシュボード（障害）と負荷評価基準インデックス傾向レポートの両方を表示します。 |
Octoblu webhookによるアラートポリシーの構成
メール通知は例外として、Octoblu webhookでアラートポリシーを構成してIoTサービスを開始できます。
注： この機能の使用には、Delivery Controllerバージョン7.11以降が必要です。
アラートを使用したIoTサービスの例としては、SMS通知の送信によるスタッフのサポートや、カスタムインシデント解決プラットフォームとの統合による追跡通知の支援などがあります。
PowerShellコマンドレットを使用して、HTTPコールバックまたはHTTP POSTでアラートポリシーを構成できます。webhooksのサポートのために拡張されます。
新しい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に転送できます。それには、SCOMをDelivery Controllerとともに構成してトラップメッセージをリスンします。
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サーバーで、以下を実行します：
-
コマンド Enable-PSRemoting を実行して、PowerShellリモート処理を有効にします。
-
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管理サーバーで、以下を実行します：
-
SCOM管理者の役割に、Director管理者を割り当てます。
-
SCOM管理コンソールを開き、［管理］>［セキュリティ］>［ユーザーロール］ の順に選択します。
-
［ユーザーロール］では、新しいユーザー役割を作成するか、または既存のユーザー役割を変更することができます。SCOMデータへのアクセス方法を定義するSCOMオペレーターの役割には4つのカテゴリがあります。たとえば、読み取り専用の役割には、［管理］ペインが表示されず、規則、マシン、アカウントを検出または管理することができません。オペレーターの役割は、すべての管理権限を実行できる管理者の役割です。
注：Director管理者がオペレーター以外の役割に割り当てられている場合、以下の操作を実行できません：
-
複数の管理サーバーが構成されており、プライマリ管理サーバーを利用できない場合、Director管理者はセカンダリ管理サーバーに接続できません。プライマリ管理サーバーはDirectorのweb.configファイルで構成されるサーバーであり、前述の手順3でDirectorConfigツールで指定されたサーバーです。セカンダリ管理サーバーは、プライマリサーバーのピア管理サーバーです。
-
アラートのフィルター時に、Director管理者はアラートソースを検索できません。検索するには、オペレーターレベルの権限が必要です。
-
-
ユーザー役割を変更するには、役割を右クリックし、［プロパティ］をクリックします。
-
［ユーザーロールのプロパティ］ダイアログで、指定したユーザー役割にDirector管理者を追加するか、またはそこからDirector管理者を削除することができます。
-
-
Director管理者を、SCOM管理サーバーの［Remote Management Users］グループに追加します。これにより、Director管理者がリモートPowerShell接続を確立できるようになります。
-
コマンド Enable-PSRemoting を実行して、PowerShellリモート処理を有効にします。
-
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 -
MaxMemoryPerShellMBの変更：
CLI：
winrm set winrm/config/winrs @{MaxMemoryPerShellMB="1024"}PS：
Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1024
-
-
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バージョンが不一致。