アラートおよび通知
アラートは、ダッシュボードの監視およびそのほかの概要ビューに、警告および重大アラートシンボルと共に表示されます。アラートは、1分ごとに自動的に更新されます。オンデマンドで更新することもできます。
警告アラート(黄色の三角形)は、条件の警告しきい値以上になっていることを示します。
重大アラート(赤の円)は、条件の重大しきい値以上になっていることを示します。
サイドバーでアラートを選択して下部にある [アラートに移動] リンクをクリックするか、[監視]ページの上部にある [アラート] を選択すると、アラートに関するさらに詳細な情報を表示できます。
[アラート]ビューで、アラートをフィルターおよびエクスポートできます。たとえば、先月特定のデリバリーグループで失敗したマルチセッションOSマシンや、特定のユーザーに対するすべてのアラートを特定することができます。詳しくは、「レポートのエクスポート」を参照してください。
Citrixアラート
Citrixアラートは、Citrixコンポーネントで発生するアラートです。Citrixアラートは、[監視]内で [アラート]>[Citrixアラートポリシー] の順に選択して構成できます。この構成では、設定したしきい値を超過した場合のアラートに関して、ユーザーおよびグループにメール送信する通知を設定できます。Citrixアラートのセットアップについて詳しくは、「アラートポリシーの作成」を参照してください。
スマートアラートポリシー
定義済みのしきい値を持つ組み込みアラートポリシーのセットは、デリバリーグループおよびマルチセッションOS VDAスコープで使用できます。[アラート]>[Citrixアラートポリシー] で、組み込みアラートポリシーのしきい値パラメーターを変更できます。 これらのポリシーは、少なくとも1つのアラートターゲット(サイト内に定義されているデリバリーグループまたはマルチセッションOS VDA)が存在する場合に作成されます。また、これらの組み込みアラートは、新しいデリバリーグループまたはマルチセッションOS VDAに自動的に追加されます。
対応するアラートルールが監視データベースに存在しない場合にのみ、組み込みアラートポリシーが作成されます。
組み込みアラートポリシーのしきい値については、「アラートポリシーの条件」を参照してください。
高度なアラートポリシー
モニターの積極的な通知およびアラート機能が強化され、高度なアラートポリシーという新しいアラートフレームワークが追加されました。この機能を使用すると、各要素または条件の詳細を含めてアラートを作成できるため、アラートのスコープをより細かく制御できます。現在、これらのポリシーにはコスト削減とインフラストラクチャに関するアラートが含まれています。
データソース主導のアラートである高度なアラートポリシーの導入により、複数条件のスコープによるフィルタリングを使用できるようになりました。
この機能を使用すると、重要な問題に対処する際の応答性や有効性の低下につながる可能性のある、過剰なアラートを削減できます。このポリシーは、アラートポリシーの有効性と管理者の関与を測定するのに役立ちます。
[アラート]>[高度なアラートポリシー]>[ポリシーの作成] セクションから、高度なアラートポリシーを作成できます。
カテゴリとして、電源管理されたマシンの電源をオンにできませんでした、電源管理されたマシンの電源をオフにできませんでした、稼働率の高い電源管理されたマシンを選択し、ポリシーに必要な条件を選択できます。ポリシーの作成方法について詳しくは「アラートポリシーの作成」を参照してください。ポリシーを作成した後、Citrixアラートページでポリシーを編集、削除、または無効にできます。
上記の各条件に対して、特定のパラメーターと対応するオプションを選択できます。
稼働率の高い電源管理されたマシンのカテゴリでは、次のメトリックが確認されます:
- 稼働時間のしきい値を超えたマシンの数
- 再アラート間隔(分)は最小60分にできます
電源管理されたマシンの電源をオンにできませんでしたと電源管理されたマシンの電源をオフにできませんでしたカテゴリでは、次のメトリックが確認されます:
- 稼働時間のしきい値を超えたマシンの数
- サンプリング間隔(分)の間隔は、30分の倍数にできます
- 再アラート間隔(分)の再アラートは、60分の倍数にできます
必要に応じて、前述のカテゴリの重大度を設定できます。これらのアラートの再アラート間隔をスケジュールすることもできます。
ポリシーのスコープを定義する
アラートのスコープを定義し、例外を追加できます。アラートは選択したスコープに対してのみ生成され、例外の追加を使用して除外されたサブスコープはアラートの生成に含まれません。この機能は、詳細なレベルでアラートを作成するのに役立ちます。
メールまたはwebhook URLを通じて通知を作成できます。アラートを受信する際の優先言語を選択することもできます。アラートパラメーターをメールの.CSV添付ファイルで受信するか、またはwebhook URLを介してJSONペイロードで受信するオプションを選択することもできます。添付ファイルには必要なパラメーターの詳細が含まれています。詳しくは、「アラートコンテンツの機能強化」を参照してください。
次のデータは、メールまたはCitrixアラートページでアラートとして受信されます:
フィールド | 説明 |
---|---|
カスタマーID | サイトのカスタマーID。 |
アラートレベル | この値は、各アラート条件に対して設定された定義済みの値です。可能な値は、CriticalとWarningです。 |
条件 | この値は、ポリシーの作成時に設定される条件です。たとえば、未登録のマシンの数が20以上です。 |
ターゲット | アラートがトリガーされるデリバリーグループまたはサイトの名前。 |
サイト | サイトの名前。 |
スコープ | ポリシーのスコープ。この値にはサブスコープも含まれます。 |
ポリシー | ポリシーの名前。 |
説明 | アラートがトリガーされる問題の説明。 |
PowerShellスクリプトを使用して高度なアラートポリシーを作成する方法。
アラートポリシーを作成するPowerShellスクリプト:
asnp Citrix.Monitor.*
# Add Parameters
$timeSpan = New-TimeSpan -Seconds 30
$alertThreshold = 1
$alarmThreshold = 2
# Add Target UID's
$targetIds = @()
$targetIds += "e9a211b4-a1f3-4f74-b6c7-85225902e997"
# Add email addresses
$emailaddress = @()
$emailaddress += "loki@abc.com"
# Create new policy
$policy = New-MonitorNotificationPolicy -Name "FailedMachinePercentageAlertCreationViaPowershell" -Description "Policy created to test urm" -Enabled $true
<!--NeedCopy-->
次の行をFailedMachinePercentageの正しい条件に置き換えます
Add-MonitorNotificationPolicyCondition -Uid $policy.Uid -ConditionType FailedMachinePercentage -AlertThreshold $alertThreshold -AlarmThreshold $alarmThreshold -AlertRenotification $timeSpan -AlarmRenotification $timeSpan
Add-MonitorNotificationPolicyTargets -Uid $policy.Uid -Scope "DG-Multisession" -TargetKind DesktopGroup -TargetIds $targetIds
$policy = Get-MonitorNotificationPolicy -Uid $policy.Uid
$policy
<!--NeedCopy-->
上の画像から、ポリシーが作成され、Uidが10であることがわかります。
構成にメールを追加するには
Set-MonitorNotificationEmailServerConfiguration -ProtocolType SMTP -ServerName NameOfTheSMTPServerOrIPAddress -PortNumber 80 -SenderEmailAddress loki@abc.com -RequiresAuthentication 0
<!--NeedCopy-->
ポリシーにメールを追加するには
Add-MonitorNotificationPolicyEmailAddresses -Uid $policy.Uid -EmailAddresses $emailaddress -EmailCultureName "en-US"
<!--NeedCopy-->
メールを追加するためのサンプルスクリプト:
Add-MonitorNotificationPolicyEmailAddresses -Uid 10 -EmailAddresses $emailaddress -EmailCultureName "en-US"
<!--NeedCopy-->
ポリシーにwebhook URLを追加するには
Set-MonitorNotificationPolicy –Uid $polcy.Uid –Webhook 'URL'
<!--NeedCopy-->
webhook URLを追加するためのサンプルスクリプト:
Set-MonitorNotificationPolicy –Uid 10 –Webhook 'https://hooks.slack.com/triggers/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'
<!--NeedCopy-->
作成されたポリシーの詳細を取得する
Get-MonitorNotificationPolicy -Uid 10
<!--NeedCopy-->
インフラストラクチャポリシー(Technical Preview)
これらのポリシーは、サポートされているCitrix Virtual Apps and Desktopsコンポーネントの正常性に関連するアラートを作成するために導入されています。
インフラストラクチャ監視のセットアップが完了したら、Monitorで利用可能な正常性データを使用して、必要なコンポーネントのアラートを構成できます。管理者は、条件、範囲、通知媒体を設定して、重要なアラートを電子メールまたはWebhook経由のJSONペイロードで受信できます。発生したアラートは、Citrixアラートセクションで分析および管理することもできます。
新しく導入されたインフラストラクチャ ポリシーの一部として、アラート条件は次の4つのセクションに分類されます:
- 到達可能性
- 依存サービス
- 影響
- リソース使用率
各カテゴリ内の条件は、組織の優先順位に基づいて、CriticalおよびWarningの重大度で設定できます。これらのアラートの再アラート間隔をスケジュールすることもできます。
[アラート]>[Citrixアラートポリシー] セクションからインフラストラクチャポリシーを作成できます。必要なカテゴリを選択し、ポリシーに必要な条件を選択できます。ポリシーの作成方法について詳しくは「アラートポリシーの作成」を参照してください。ポリシーを作成した後、Citrixアラートページでポリシーを編集、削除、または無効にできます。
各カテゴリおよびコンポーネントでサポートされている条件の詳細については、以下を参照してください:
次のデータは、メールまたはCitrixアラートページでアラートとして受信されます:
フィールド | 説明 |
---|---|
カスタマーID | サイトのカスタマーID。 |
アラートレベル | 可能な値は、CriticalとWarningです。 |
ターゲット | アラートがトリガーされるマシンの名前。 |
時間 | アラートがトリガーされた時刻。 |
スコープ | ポリシーのスコープ。 |
ポリシー | ポリシーの名前。 |
説明 | アラートがトリガーされる問題の説明。 |
アラートポリシーの作成
特定のセッション数基準のセットを満たした場合にアラートを生成するなどの目的で、アラートポリシーを作成するには、以下の手順に従います:
- [アラート]>[Citrixアラートポリシー]の順に選択し、[マルチセッションOSポリシー]などを選択します。
- [作成] をクリックします。
- ポリシーの名前と説明を入力し、アラートをトリガーするために満たす必要がある条件を設定します。たとえば、最大接続セッション数、最大切断セッション数、および最大同時セッション数に対して、警告とする数および重大とする数を指定します。警告値を重大値よりも大きくすることはできません。詳しくは、「アラートポリシーの条件」を参照してください。
- 再アラート間隔を設定します。アラートの条件が引き続き満たされている場合、アラートはこの間隔で再トリガーされます。アラートポリシーで設定されている場合は、メール通知が生成されます。クリアされたアラートの場合、再アラート間隔でメール通知が生成されることはありません。
- スコープを設定します。たとえば、特定のデリバリーグループに対して設定します。
- お知らせ設定で、アラートがトリガーされたときのメール通知の送信先を指定します。メール通知はSendGridで送信されます。メールアドレス
donotreplynotifications@citrix.com
がメール設定で許可リストに登録されていることを確認してください。 - [保存] をクリックします。
スコープに20件以上のデリバリーグループが定義されているポリシーを作成すると、構成が完了するまでにおよそ30秒かかる場合があります。完了するまで、スピナーアイコンが表示されます。
最大20の一意のデリバリーグループに対して、50以上のポリシー(合計で1000デリバリーグループターゲット)を作成すると、応答時間が遅くなることがあります(5秒以上)。
アクティブなセッションがあるマシンをデリバリーグループから別のデリバリーグループに移動すると、マシンパラメーターで定義されたデリバリーグループアラートが誤って発信されることがあります。
注: アラートポリシーを削除した後、ポリシーによって生成されたアラート通知が停止するまでに最大30分かかる場合があります。
アラートコンテンツの機能強化
Monitorのアラート機能が強化され、CSV添付ファイルとJSONペイロードが含まれるようになりました。この機能強化により、アラートの詳細をメールのCSV添付ファイルで取得したり、webhookがある場合はJSONペイロードとして取得したりできるようになります。このCSV添付ファイルまたはJSONペイロードを使用すると、詳細なレベルで充実したコンテンツを受け取ることができ、問題を迅速に特定して解決するのに役立ちます。
現在、この機能強化は次のアラートでのみ利用可能です:
- マシンの稼働時間
- 電源オン操作の失敗
- 電源オフ操作の失敗
- 未登録のマシン(%)
この機能を使用するには、アラートに移動して次のチェックボックスを選択します:
- webhookに添付ファイルとしてJSONペイロードを含める
- メールにcsvファイルを添付する
以下は、[Citrixアラートポリシー] セクションのスクリーンショットです:
以下は、[高度なアラートポリシー] セクションのスクリーンショットです:
CSV添付ファイル
次の表は、サポートされているすべてのアラートの.CSV添付ファイルの列を示しています:
列 | 該当するアラート |
---|---|
マシン名、IPアドレス、デリバリーグループ名 | マシンの稼働時間、電源オフ操作の失敗、電源オン操作の失敗、および未登録マシン(%) |
現在の登録状態、エラーの日付、エラーの状態、ライフサイクルの状態 | 未登録マシン(%) |
最後の電源操作失敗の理由、最後の電源操作のトリガー元、最後の電源操作の種類、最後の電源操作の完了日 | 電源オフ操作の失敗と電源オン操作の失敗 |
電源状態、電源オンの日付、合計稼働時間(分) | マシンの稼働時間 |
webhookペイロード
未登録マシンの割合アラート
Webhook Payload
{
"Address": "<Webhook URL>",
"NotificationId": "<NotificationGUID>",
"NotificationState": "NotificationActive",
"Priority": "<Critical/Warning>",
"Target": "<DeliveryGroupName>",
"Condition": "Unregistered machines (in %)",
"Value": "<Value Set as Threshold>",
"Timestamp": "<Timestamp string Eg: April 25, 2024 9:33 PM (UTC +5)>",
"PolicyName": "<Alert Policy Name>",
"Description": "<Alert Policy Description>",
"Scope": "DeliveryGroup",
"Site": "<Name of the Site>",
"AttachmentData": [{
"Machine Name": "<Name of the Machine>",
"IP Address": “<IP Address>”,
"Delivery Group Name": "<Name of the DeliveryGroup>",
"Current Registration State": "Unregistered",
"Failure Date": “<Date of Failure>”,
"Fault State": "<Fault State of the Machine>",
"Lifecycle State": "<Lifecycle state of the Machine>"
},
{
"Machine Name": "<Name of the Machine>",
"IP Address": “<IP Address>”,
"Delivery Group Name": "<Name of the DeliveryGroup>",
"Current Registration State": "Unregistered",
"Failure Date": “<Date of Failure>”,
"Fault State": "<Fault State of the Machine>",
"Lifecycle State": "<Lifecycle state of the Machine>"
}]
}
<!--NeedCopy-->
電源オン操作の失敗アラート
Webhook Payload Body
{
"Address": "<Webhook URL>",
"NotificationId": "<NotificationGUID>",
"NotificationState": "NotificationActive",
"Priority": "<Critical/Warning>",
"Target": "<DeliveryGroupName>",
"Condition": "Failure To PowerOn Action",
"Value": "<Value Set as Threshold>",
"Timestamp": "<Timestamp string Eg: April 25, 2024 9:33 PM (UTC +5)>",
"PolicyName": "<Alert Policy Name>",
"Description": "<Alert Policy Description>",
"Scope": "DeliveryGroup",
"Site": "<Name of the Site>",
"AttachmentData": [{
"Machine Name": "<Name of the Machine>",
"IP Address": “<IP Address>”,
"Delivery Group Name": "<Name of the DeliveryGroup>",
"Last Power Action Failure Reason": "<HypervisorReportedFailure,HypervisorRateLimitExceeded,UnknownError,Power Action Type>",
"Last Power Action Triggered By": "<End-User,Administrator,Auto-Scale,Schedule>",
"Last Power Action Type": “<PowerOn/PowerOff>”,
"Last Power Action Completed Date": "<Time string Eg: 2024-05-15T15:04:27.723>",
{
"Machine Name": "<Name of the Machine>",
"IP Address": “<IP Address>”,
"Delivery Group Name": "<Name of the DeliveryGroup>",
"Last Power Action Failure Reason": "<HypervisorReportedFailure,HypervisorRateLimitExceeded,UnknownError,Power Action Type>",
"Last Power Action Triggered By": "<End-User,Administrator,Auto-Scale,Schedule>",
"Last Power Action Type": “<PowerOn/PowerOff>”,
"Last Power Action Completed Date": "<Time string Eg: 2024-05-15T15:04:27.723>"
}]
}
<!--NeedCopy-->
電源オフ操作の失敗アラート
{
"Address": "<Webhook URL>",
"NotificationId": "<NotificationGUID>",
"NotificationState": "NotificationActive",
"Priority": "<Critical/Warning>",
"Target": "<DeliveryGroupName>",
"Condition": "Failure To PowerOff Action",
"Value": "<Value Set as Threshold>",
"Timestamp": "<Timestamp string Eg: April 25, 2024 9:33 PM (UTC +5)>",
"PolicyName": "<Alert Policy Name>",
"Description": "<Alert Policy Description>",
"Scope": "DeliveryGroup",
"Site": "<Name of the Site>",
"AttachmentData": [{
"Machine Name": "<Name of the Machine>",
"IP Address": “<IP Address>”,
"Delivery Group Name": "<Name of the DeliveryGroup>",
"IP Address": "<IPV4 Address of the Machine>",
"Last Power Action Failure Reason": "<HypervisorReportedFailure,HypervisorRateLimitExceeded,UnknownError,Power Action Type>",
"Last Power Action Triggered By": "<End-User,Administrator,Auto-Scale,Schedule>",
"Last Power Action Type": “<PowerOn/PowerOff>”,
"Last Power Action Completed Date": "<Time string Eg: 2024-05-15T15:04:27.723>"
},
{
"Machine Name": "<Name of the Machine>",
"IP Address": “<IP Address>”,
"Delivery Group Name": "<Name of the DeliveryGroup>",
"IP Address": "<IPV4 Address of the Machine>",
"Last Power Action Failure Reason": "<HypervisorReportedFailure,HypervisorRateLimitExceeded,UnknownError,Power Action Type>",
"Last Power Action Triggered By": "<End-User,Administrator,Auto-Scale,Schedule>",
"Last Power Action Type": “<PowerOn/PowerOff>”,
"Last Power Action Completed Date": "<Time string Eg: 2024-05-15T15:04:27.723>"
}]
}
<!--NeedCopy-->
マシン稼働時間のアラート
{
"Address": "<Webhook URL>",
"NotificationId": "<NotificationGUID>",
"NotificationState": "NotificationActive",
"Priority": "<Critical/Warning>",
"Target": "<DeliveryGroupName>",
"Condition": "Machine Uptime Alert",
"Value": "<Value Set as Threshold>",
"Timestamp": "<Timestamp string Eg: April 25, 2024 9:33 PM (UTC +5)>",
"PolicyName": "<Alert Policy Name>",
"Description": "<Alert Policy Description>",
"Scope": "DeliveryGroup",
"Site": "<Name of the Site>",
"AttachmentData": [{
"Machine Name": "<Name of the Machine>",
"IP Address": “<IP Address>”,
"Delivery Group Name": "<Name of the DeliveryGroup>",
"IP Address": "<IPV4 Address of the Machine>",
"Power State": "<On/Off>",
"Powered On Date": "Time sting Eg: 2024-05-15T15:04:27.723",
"Total Uptime In Minutes": 180
},
{
"Machine Name": "<Name of the Machine>",
"IP Address": “<IP Address>”,
"Delivery Group Name": "<Name of the DeliveryGroup>",
"IP Address": "<IPV4 Address of the Machine>",
"Power State": "<ON/OFF>",
"Powered On Date": "<Time string Eg: 2024-05-15T15:04:27.723>",
"Total Uptime In Minutes": <Uptime Duration>
}]
}
<!--NeedCopy-->
アラートポリシーの条件
アラートカテゴリ、アラートを緩和するための推奨アクション、および定義されている場合は組み込みポリシーの条件を以下に示します。組み込みアラートポリシーは、60分のアラートおよび再アラートの間隔で定義されています。
最大接続セッション数
- [監視]のセッション傾向ビューで、最大接続済みセッション数をチェックします。
- セッションの負荷に対応するのに十分な処理能力があることを確認します。
- 必要に応じ、マシンを追加します。
最大切断セッション数
- [監視]のセッション傾向ビューで、最大切断セッション数をチェックします。
- セッションの負荷に対応するのに十分な処理能力があることを確認します。
- 必要に応じ、マシンを追加します。
- 必要に応じ、切断されたセッションからログオフします。
合計最大同時セッション数
- [監視]のセッション傾向ビューで、最大同時セッション数をチェックします。
- セッションの負荷に対応するのに十分な処理能力があることを確認します。
- 必要に応じ、マシンを追加します。
- 必要に応じ、切断されたセッションからログオフします。
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時間の接続エラーの率。
- 接続の合計試行回数に対する合計エラー数の割合に基づいて計算されます。
- [監視]の接続エラーの傾向ビューで、構成ログから記録されたイベントをチェックします。
- アプリケーションまたはデスクトップにアクセスできるかどうかを確認します。
接続エラー数
過去1時間の接続エラー数。
- [監視]の接続エラーの傾向ビューで、構成ログから記録されたイベントをチェックします。
- アプリケーションまたはデスクトップにアクセスできるかどうかを確認します。
ICA往復時間(平均)
平均ICA往復時間
- Citrix ADMでICA往復時間のブレークダウンをチェックして、原因を特定します。詳しくは、Citrix ADMのドキュメントを参照してください。
- Citrix ADMが利用可能でない場合は、[監視]の[ユーザーの詳細]ビューでICA往復時間および遅延をチェックして、これがネットワークの問題か、それともアプリケーションやデスクトップの問題かを特定します。
ICA往復時間(セッション数)
ICA往復時間を超過しているセッションの数。
- Citrix ADMで、ICA往復時間が高いセッションの数をチェックします。詳しくは、Citrix ADMのドキュメントを参照してください。
-
Citrix ADMを利用できない場合は、ネットワークチームと協力して原因を特定してください。
スマートポリシーの条件:
- スコープ: デリバリーグループ、マルチセッションOSスコープ
- しきい値: 警告 - 5つ以上のセッションで300ms、重大 - 10以上のセッションで400ms
ICA往復時間(セッションの%)
平均ICA往復時間を超過しているセッションの割合。
- Citrix ADMで、ICA往復時間が高いセッションの数をチェックします。詳しくは、Citrix ADMのドキュメントを参照してください。
- Citrix ADMを利用できない場合は、ネットワークチームと協力して原因を特定してください。
ICA往復時間(ユーザー)
特定のユーザーによって開始されたセッションに適用されたICA往復時間。1つ以上のセッションでICA往復時間がしきい値よりも高い場合は、アラートがトリガーされます。
障害が発生したマシン(シングルセッションOS)
失敗したシングルセッションOSマシンの数。[監視]ダッシュボードビューおよび[フィルター]ビューに表示されるように、エラーはさまざまな理由で発生します。
-
Citrix Scout診断を実行して、原因を特定します。詳しくは、「ユーザーの問題のトラブルシューティング」を参照してください。
スマートポリシーの条件:
- スコープ: デリバリーグループスコープ
- しきい値: 警告 - 1、重大 - 2
障害が発生したマシン(マルチセッションOS)
失敗したマルチセッションOSマシンの数。[監視]ダッシュボードビューおよび[フィルター]ビューに表示されるように、エラーはさまざまな理由で発生します。
-
Citrix Scout診断を実行して、原因を特定します。
スマートポリシーの条件:
- スコープ: デリバリーグループ、マルチセッションOSスコープ
- しきい値: 警告 - 1、重大 - 2
障害が発生したマシン(%)
障害が発生したマシンの数に基づいて計算された、デリバリーグループ内の障害が発生したシングルセッションおよびマルチセッションOSマシンの割合。アラートの条件を設定する際、アラートのしきい値をデリバリーグループ内の障害が発生したマシンの割合で構成できます。この条件は30秒ごとに計算されます。 [監視]ダッシュボードビューおよび[フィルター]ビューに表示されるように、エラーはさまざまな理由で発生します。Citrix Scout診断を実行して、原因を特定します。詳しくは、「ユーザーの問題のトラブルシューティング」を参照してください。
電源オフ操作の失敗と電源オン操作の失敗
電源オンまたはオフに失敗した電源管理されたマシンの数に基づいて計算された、デリバリーグループ内の失敗した電源オン操作の数と失敗した電源オフ操作の数。このアラート条件を使用すると、デリバリーグループ内で電源のオン/オフに失敗した電源管理されたマシンの数としてアラートしきい値を構成でき、このしきい値は30分ごとに計算されます。
管理者は、高度なアラートポリシーでこれらのアラートの次のパラメーターを設定できます:
- トリガー元:電源操作をトリガーしたもの
- エラーの理由::操作が失敗した理由
- しきい値:ポリシーをトリガーする、電源操作に失敗したマシンのしきい値数
- サンプリング間隔:失敗した電源操作をチェックする間隔
- 再アラート間隔:アラートを再送信するまでの期間
[監視]ダッシュボードビューおよび[フィルター]ビューに表示されるように、エラーはさまざまな理由で発生します。Citrix Scout診断を実行して、原因を特定します。詳しくは、「ユーザーの問題のトラブルシューティング」を参照してください。
未登録マシン(%)
再起動によりマシンが不安定になった場合、またはDelivery Controllerと仮想マシンの間に通信の問題が発生した場合、マシンは未登録とみなされます。未登録マシン(%) デリバリーグループ内の未登録のシングルセッションおよびマルチセッションOSマシンの割合で、未登録マシンの数に基づいて計算されます。このアラート条件を使用すると、警告および重大のしきい値を、デリバリーグループ内の未登録マシンの割合で構成できます。再アラートの間隔を設定できます。未登録マシン(%)の条件が満たされたときに通知を受け取るメールアドレスを追加することもできます。重大または警告のしきい値を超えると、アラートとメールが生成されます。Citrixアラートでアラートを表示できます。未登録マシン(%) カテゴリで必要な状態および時間に関してフィルタリングできます。
注:
重大値は警告値より大きくなければなりません。
ポリシー条件:
- スコープ:シングルセッションOS、およびマルチセッションOSデリバリーグループ
- しきい値:警告および重大
マシン稼働時間のアラート
デリバリーグループ内のマシンの稼働時間は、デリバリーグループ内でオンになっているマシンの1日あたりの時間数、1週間あたりの時間数、または1か月あたりの時間数に基づいて計算されます。このアラート条件を使用すると、アラートのしきい値を、デリバリーグループ内でオンになっているマシンの時間数で構成できます。マシン稼働時間のアラートは、次の場合に機能します:
- 1日あたりの時間 - 1日にマシンがオンになっている時間数を指定できます。これは30分ごとに計算されます。1日あたりに設定できる最大時間数は24時間です。
- 1週間あたりの時間 - 1週間にマシンがオンになっている時間数を指定できます。これは6時間ごとに計算されます。1週間あたりに設定できる最大時間数は168時間です。
- 1か月あたりの時間 - 1か月にマシンがオンになっている時間数を指定できます。これは1日1回計算されます。1か月あたりの最大時間は720時間です。 設定できる最小の再アラート間隔値は60分です。警告および重大なアラートのセクションで、マシンの稼働時間のしきい値を超えるマシンの数を入力できます。任意のマシンに対して例外を追加することもできます。
たとえば、このアラートに5つのデリバリーグループが追加されていて、最初のデリバリーグループと4番目のデリバリーグループマシンの数が警告または重大なしきい値を超えた場合、最初のデリバリーグループと4番目のデリバリーグループに対してアラートが個別にトリガーされます。
このアラートは、管理者がマシンの稼働時間を分析するのに役立ち、この分析に基づいて管理者はコストの最適化を実行できます。アラートの詳細は、メールの場合はCSV添付ファイルで、webhookの場合はJSONペイロードで受け取ることもできます。
平均ログオン時間
過去1時間に行われたログオンの平均ログオン処理時間。
- [監視]ダッシュボードをチェックし、ログオン処理時間に関する最新のメトリックを取得します。短時間のうちに多数のユーザーがログインするとログオン処理時間が長引くことがあります。
-
原因を絞り込むため、ログオンのベースラインおよび内訳をチェックします。詳しくは、「ユーザーログオンの問題の診断」を参照してください。
スマートポリシーの条件:
- スコープ: デリバリーグループ、マルチセッションOSスコープ
- しきい値: 警告 - 45秒、重大 - 60秒
ログオン処理時間(ユーザー)
過去1時間に行われた指定されたユーザーのログオンに関するログオン処理時間。
負荷評価基準インデックス
過去5分間の負荷評価基準インデックスの値。
-
[監視]で、ピーク負荷(最大負荷)に達している可能性があるマルチセッションOSマシンをチェックします。ダッシュボード(失敗)および負荷評価基準インデックス傾向レポートを表示します。
スマートポリシーの条件:
- スコープ: デリバリーグループ、マルチセッションOSスコープ
- しきい値: 警告 - 80%、重大 - 90%
webhookによるアラートポリシーの構成
メール通知以外に、webhookでアラートポリシーを構成できます。
注: この機能の使用には、Delivery Controllerバージョン7.11以降が必要です。
PowerShellコマンドレットを使用して、HTTPコールバックまたはHTTP POSTでアラートポリシーを構成できます。webhooksのサポートのために拡張されます。
新しいOctobluワークフローの作成および対応するwebhook URLの取得について詳しくは、『Octoblu Developer Hub』を参照してください。
新しいアラートポリシーや既存のポリシーに対してwebhook URLを構成するには、次のPowerShellコマンドレットを使用します。
webhook URLでアラートポリシーを作成する場合:
$policy = New-MonitorNotificationPolicy -Name <Policy name> -Description <Policy description> -Enabled $true -Webhook <Webhook URL>
<!--NeedCopy-->
既存のアラートポリシーにwebhook URLを追加する場合:
Set-MonitorNotificationPolicy - Uid <Policy id> -Webhook <Webhook URL>
<!--NeedCopy-->
PowerShellコマンドのヘルプについては、たとえば次のようにPowerShellヘルプを使用します:
Get-Help <Set-MonitorNotificationPolicy>
<!--NeedCopy-->
アラートポリシーから生成された通知によって、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-->
PowerShell SDKを使用したwebhookの構成
PowerShell SDKを使用したwebhook構成機能により、管理者はwebhookプロファイルを作成、変更、削除、および一覧表示できます。この機能により、ヘッダー、認証の種類、コンテンツの種類、ペイロード、webhook URLを指定できるため、webhookを柔軟に構成できるようになります。
注:
サポートされているペイロード形式はテキストであり、エンドユーザーはwebhookでテキストを有効にする必要があります。
最新のペイロード形式は次のとおりです:
{"text": "This is a message from a Webex incoming webhook."}
<!--NeedCopy-->
webhookを作成する
次のサンプルPowerShellコマンドを使用して、webhookプロファイルを作成できます:
$headers = [System.Collections.Generic.Dictionary[string,string]]::new()
$headers.Add("Content-Type", "application/json")
$payloads = '{ "text": "$PAYLOAD" }'
$url = "<Fill this field with the required URL>"
Add-MonitorWebhookProfile -Name "profile_slack" -Description "webhook profile for slack" -Url $url -Headers $headers -PayloadFormat $payloads
$headers = [System.Collections.Generic.Dictionary[string,string]]::new()
$headers.Add("Content-Type", "application/json")
$headers.Add("Authorization", "Basic <Fill this field with the authorization token>")
$payloads = '{ "text": "$PAYLOAD" }'
$url = "<Fill this field with the required URL>"
Add-MonitorWebhookProfile -Name "profile_azure" -Description "webhook profile for azure function with Authentication" -Url $url -Headers $headers -PayloadFormat $payloads
<!--NeedCopy-->
プロファイルが作成されると、データベースで確認できます。また、Citrixアラート ページで新しく作成されたwebhookプロファイルを見つけることができます。
webhookプロファイルを更新する
次のサンプルPowerShellコマンドを使用して、webhookプロファイルを更新できます:
$headers = [System.Collections.Generic.Dictionary[string,string]]::new()
$headers.Add("Content-Type", "application/json")
$payloads = '{ "text": "$PAYLOAD" }'
$url = "<Fill this field with the required URL>"
Set-MonitorWebhookProfile -Uid 1 -Name "profile_slack_citrix" -Description "webhook profile for citrix slack" -Url $url -Headers $headers -PayloadFormat $payloads
<!--NeedCopy-->
すべてのwebhookプロファイルの一覧を取得する
次のサンプルPowerShellコマンドを使用して、使用可能なすべてのwebhookプロファイルの一覧を取得できます:
Get-MonitorWebhookProfile
Get-MonitorWebhookProfile -Name 'profile_msteams'
Get-MonitorWebhookProfile -Uid 1
<!--NeedCopy-->
webhookプロファイルを削除する
次のサンプルPowerShellコマンドを使用して、webhookプロファイルを削除できます:
Remove-MonitorWebhookProfile -Uid 1
<!--NeedCopy-->
注:
webhookプロファイルがポリシーにマップされている場合は削除できません。回避策として、まずポリシーからwebhookマッピングを削除する必要があります。
webhookプロファイルを使用してポリシーを作成する
次のサンプルPowerShellコマンドを使用して、webhookプロファイルでポリシーを作成できます:
New-MonitorNotificationPolicy -Name "Policy1" -Description "Policy Description" -Enabled $true -WebhookProfileId 1
<!--NeedCopy-->
webhookプロファイルを使用してポリシーを更新する
次のサンプルPowerShellコマンドを使用して、webhookプロファイルでポリシーを更新できます:
$Policy = Set-MonitorNotificationPolicy -Uid 1 -WebhookProfileId 1
<!--NeedCopy-->
ポリシーからwebhookマッピングを削除する
次のサンプルPowerShellコマンドを使用して、ポリシーからwebhookプロファイルを削除できます:
$Policy = Set-MonitorNotificationPolicy -Uid 1 -WebhookProfileId 0
<!--NeedCopy-->
webhookプロファイルをテストする
次のサンプルPowerShellコマンドを使用して、webhookプロファイルをテストできます:
$headers = [System.Collections.Generic.Dictionary[string,string]]::new()
$headers.Add("Content-Type", "application/json")
$headers.Add("Authorization", "Basic <Fill this with authorization token>")
$payloads = '{ "text": "$PAYLOAD" }'
$url ="<Fill this field with the required URL>"
Test-MonitorWebhookProfile -Url $url -Headers $headers -PayloadFormat $payloads
<!--NeedCopy-->
ローカルホストキャッシュ構成の同期失敗アラートの監視
ローカルホストキャッシュを使用すると、Cloud ConnectorがCitrix Cloudとの接続を失った場合でも、ユーザーセッションを継続できます。ローカル ホストキャッシュによって使用されるキャッシュは、ローカルホストキャッシュモードがアクティブになっているときに最新の構成を取得するために、プライマリデータベースと定期的に同期されます。ローカルホストキャッシュと構成の同期プロセスについて詳しくは、「ローカルホストキャッシュ」を参照してください。構成の同期が連続して3回を超えて失敗すると、Citrix Monitorは管理者に警告アラートを送信します。
Citrix Monitorでは、構成の同期の失敗を通知するために、ローカルホストキャッシュ - 構成の同期失敗という名前の事前定義されたアラートポリシーが導入されました。新しく導入されたポリシーは [監視]>[Citrixアラート] で確認できます。事前定義されたポリシーを変更して、メールの受信者またはwebhookを追加または編集し、アラート管理ツールまたはITSMツールで予防的な通知を受信できます。
ローカルホストキャッシュ構成の同期失敗アラートポリシーの範囲は、サイトのみに限定されます。
ハイパーバイザーアラートの監視
[監視]では、ハイパーバイザーの正常性を監視するアラートが表示されます。Citrix HypervisorとVMware vSphereのアラートは、ハイパーバイザーのパラメーターと状態を監視するのに役立ちます。ハイパーバイザーへの接続状態も監視され、クラスターまたはホストのプールが再起動された場合、または使用できなくなった場合にアラートが出されます。
ハイパーバイザーアラートを受信するには、[管理] タブでホスト接続が作成されている必要があります。詳しくは、「接続およびリソース」を参照してください。ハイパーバイザーアラートではこれらの接続のみが監視されます。次の表に、ハイパーバイザーアラートのさまざまなパラメーターと状態を示します。
通知 | サポートされるハイパーバイザー | トリガー元 | 条件 | 構成 |
---|---|---|---|---|
CPU使用率 | Citrix Hypervisor、VMware vSphere | Hypervisor | CPU使用率アラートしきい値に達しているか、超過している | アラートしきい値は、ハイパーバイザーで設定する必要があります。 |
メモリ使用率 | Citrix Hypervisor、VMware vSphere | Hypervisor | メモリ使用率アラートしきい値に達しているか、超過している | アラートしきい値は、ハイパーバイザーで設定する必要があります。 |
ネットワーク使用状況 | Citrix Hypervisor、VMware vSphere | Hypervisor | ネットワーク使用率アラートしきい値に達しているか、超過している | アラートしきい値は、ハイパーバイザーで設定する必要があります。 |
ディスク使用率 | VMware vSphere | Hypervisor | ディスク使用率アラートしきい値に達しているか、超過している | アラートしきい値は、ハイパーバイザーで設定する必要があります。 |
ホスト接続や電源の状態 | VMware vSphere | Hypervisor | ハイパーバイザーホストが再起動されたか、または利用できない | アラートはVMware vSphereにあらかじめ組み込まれています。追加の構成は必要ありません。 |
使用不可のハイパーバイザー接続 | Citrix Hypervisor、VMware vSphere | Delivery Controller | ハイパーバイザー(プールまたはクラスター)への接続が失われるか、電源がオフになるか、再起動されます。このアラートは、接続が利用できない間、1時間ごとに生成されます。 | アラートはDelivery Controllerにあらかじめ組み込まれています。追加の構成は必要ありません。 |
注:
アラートの構成について詳しくは、「Citrix XenCenterアラート」を参照するか、VMware vCenterアラートのドキュメントを確認してください。
メール通知設定は、[Citrixアラートポリシー]>[サイトポリシー]>[ハイパーバイザーの正常性]から設定できます。Hypervisorのアラートポリシーのしきい値条件は、[監視]からではなくハイパーバイザーからのみ設定、編集、無効化、または削除できます。ただし、メール設定の変更とアラートの解除は[監視]で行うことができます。
重要:
- 2日以上経過したハイパーバイザー通知は、すべて自動的に破棄されます。
- アラートはHypervisorにより取得され、[監視]に表示されます。ただし、Hypervisorのアラートのライフサイクルや状態に対する変更は、[監視]には反映されません。
- 正常状態のアラートやHypervisorコンソールで破棄または無効化したアラートであっても、[監視]には表示され続けるため、Directorで明示的に破棄する必要があります。
- アラートを[監視]で破棄しても、Hypervisorコンソールで自動的に破棄されることはありません。
ハイパーバイザーアラートのみをフィルタリングできるように、「ハイパーバイザーの正常性」という新しいアラートカテゴリが追加されました 。これらのアラートは、しきい値に達するか超過すると表示されます。ハイパーバイザーのアラートには次のものがあります:
- 重大—ハイパーバイザーアラームポリシーの重大しきい値に達したか超過した
- 警告—ハイパーバイザーアラームポリシーの警告しきい値に達したか超過した
- 解除—アラートはアクティブなアラートとして表示されなくなる