アラートと通知
アラートは、Directorのダッシュボードやその他の高レベルビューに、警告および重大なアラートシンボルとともに表示されます。アラートは、Premiumライセンスサイトで利用できます。アラートは1分ごとに自動的に更新されます。オンデマンドでアラートを更新することもできます。
警告アラート(琥珀色の三角形)は、条件の警告しきい値に達したか、それを超えたことを示します。
重大なアラート(赤い円)は、条件の重大なしきい値に達したか、それを超えたことを示します。
アラートの詳細情報を表示するには、サイドバーからアラートを選択するか、サイドバーの下部にあるGo to Alertsリンクをクリックするか、Directorページの上部からAlertsを選択します。
アラートビューでは、アラートをフィルター処理してエクスポートできます。たとえば、特定のデリバリーグループの過去1か月間の失敗したマルチセッションOSマシン、または特定のユーザーのすべてのアラートなどです。詳細については、「レポートのエクスポート」を参照してください。
Citrix®アラート
Citrixアラートは、Citrixコンポーネントから発生し、Directorで監視されるアラートです。Citrixアラートは、DirectorのAlerts \> Citrix Alerts Policyで構成できます。構成の一部として、アラートが設定したしきい値を超えたときに、個人やグループにメールで通知を送信するように設定できます。Citrixアラートの設定の詳細については、「アラートポリシーの作成」を参照してください。
注:
ファイアウォール、プロキシ、またはMicrosoft Exchange Serverがメールアラートをブロックしないようにしてください。
スマートアラートポリシー
事前定義されたしきい値を持つ一連の組み込みアラートポリシーは、デリバリーグループおよびマルチセッションOS VDAスコープで利用できます。この機能には、Delivery Controllerバージョン7.18以降が必要です。組み込みアラートポリシーのしきい値パラメーターは、Alerts \> Citrix Alerts Policyで変更できます。 これらのポリシーは、サイトに少なくとも1つのアラートターゲット(デリバリーグループまたはマルチセッションOS VDA)が定義されている場合に作成されます。さらに、これらの組み込みアラートは、新しいデリバリーグループまたはマルチセッションOS VDAに自動的に追加されます。
Directorとサイトをアップグレードする場合、以前のDirectorインスタンスのアラートポリシーが引き継がれます。組み込みアラートポリシーは、Monitorデータベースに対応するアラートルールが存在しない場合にのみ作成されます。
組み込みアラートポリシーのしきい値については、「アラートポリシーの条件」セクションを参照してください。
高度なアラートポリシー
Directorのプロアクティブ通知およびアラート機能は、高度なアラートポリシーという新しいアラートフレームワークを含むように強化されました。この機能を使用すると、各要素または条件のきめ細かな詳細を含めてアラートを作成できるため、アラートのスコープに対する制御が強化されます。現在、これらのポリシーには、コスト削減とインフラストラクチャに関するアラートが含まれています。
データソース駆動型アラートである高度なアラートポリシーの導入により、複数条件のスコープフィルタリングを使用できます。
この機能は、重要な問題への対応の迅速性や有効性の低下につながる可能性のある過剰なアラートを減らすのに役立ちます。このポリシーは、アラートポリシーの有効性と管理者からのエンゲージメントを測定するのに役立ちます。
次のデータソースのいずれかを選択できます。
-
マシン
-
プロビジョニングサービス
-
StoreFront™
-
デリバリーコントローラー™
コスト削減に関するアラート
コストを最適化するのに役立つコスト削減のアラートを作成できます。現在、マシンに関するアラートを作成できます。
マシンに関するアラートを作成するには、次の手順を実行します。
-
ポリシーの作成をクリックします。高度なアラートポリシーの作成セクションが表示されます。
-
データソースドロップダウンリストからマシンを選択します。コスト削減条件と対応する条件タイプが表示されます。

-
必要な条件タイプを以下から選択します。
-
電源管理されたマシンの電源オンに失敗しました
-
電源管理されたマシンの電源オフに失敗しました
-
高い稼働時間の電源管理マシン
-
-
選択した各条件について、特定のパラメーターと対応するオプションを選択します。
-
選択した条件タイプに対して、警告およびクリティカルのメトリックを設定します。
-
高い稼働時間の電源管理マシンについて:
-
稼働時間しきい値を超過したマシンの数
-
再アラート間隔(分)は最低60分です。
-
-
電源オンに失敗した電源管理マシンおよび電源オフに失敗した電源管理マシンについて:
-
稼働時間しきい値を超過したマシンの数
-
サンプリング間隔(分):間隔は30分の倍数にできます
-
再アラート間隔(分):再アラートは60分の倍数にできます
-
-
-
必要に応じて、選択したアラートの再アラート間隔をスケジュールします。
-
アラートのスコープを定義します。
-
通知チャネルを設定します。これはメールまたはWebhookにすることができます。
-
次のチェックボックスを選択できます。
-
WebhookにJSONペイロードを添付として含める
-
メールにCSVファイルを添付として含める
-
詳細については、アラートコンテンツの強化を参照してください。 -
-
アラート名や説明(オプション)などのアラートの詳細を入力します。
-
保存をクリックします。アラートが作成されます。
インフラストラクチャ監視のアラート
次のサポートされているCitrix Virtual Apps and Desktops™コンポーネントの健全性を監視するためにアラートを作成できます。
-
プロビジョニングサービス

-
StoreFront

-
デリバリーコントローラー

インフラストラクチャ監視 の設定が完了すると、Directorで利用可能な健全性データを使用して、必要なコンポーネントのアラートを構成できます。管理者は、条件、スコープ、および通知媒体を設定して、電子メールまたはWebhookを介したJSONペイロードで重要なアラートを受信できます。Provisioning ServiceとDelivery Controllerの場合、アラートのスコープをサイトレベルまたは個々のサーバーレベルのいずれかとして選択できます。たとえば、Provisioning Serviceの場合、「すべてのProvisioning Service」を選択すると、サイトに2つのサーバーがある場合でも、サイト全体に対して単一のアラートのみを受信します。これはサイトレベルのアラートと見なされます。発生したアラートは、分析と管理のためにCitrix Alertsセクションでも利用できます。
新しく導入されたインフラストラクチャポリシーの一部として、アラート条件は次の4つのセクションに分類されます。
-
到達可能性
-
依存サービス
-
影響
-
リソース使用率
各カテゴリ内の条件は、組織の優先順位に基づいて、重大および警告の重大度で設定できます。これらのアラートの再アラート間隔をスケジュールすることもできます。
アラート > Citrixアラートポリシーセクションからインフラストラクチャポリシーを作成できます。必要なカテゴリを選択し、ポリシーに必要な条件を選択できます。ポリシーの作成方法の詳細については、「アラートポリシーの作成」を参照してください。ポリシーが作成された後、Citrix Alerts ページでポリシーを編集、削除、または無効にできます。
各カテゴリとコンポーネントでサポートされている条件の詳細については、以下を参照してください。
次のデータは、電子メールまたは Citrix Alert ページでアラートとして受信されます。
| フィールド | 説明 |
|---|---|
| 顧客ID | サイトの顧客ID。 |
| アラートレベル | 指定可能な値は、Critical と Warning です。 |
| ターゲット | アラートがトリガーされたマシンの名前。 |
| 時間 | アラートがトリガーされた時刻。 |
| スコープ | ポリシーのスコープ。 |
| ポリシー | ポリシーの名前。 |
| 説明 | アラートがトリガーされる問題の説明。 |
ポリシーのスコープを定義する
アラートのスコープを定義し、例外を追加できます。アラートは選択したスコープに対してのみ生成され、例外の追加を使用して除外されたサブスコープはアラート生成に含まれません。この機能は、詳細なレベルでアラートを作成するのに役立ちます。
メールまたはWebhook URLを介して通知を作成できます。アラートを受信する希望の言語を選択することもできます。また、アラートパラメータをメールの.CSVファイル添付として、またはWebhook URLを介したJSONペイロードとして受信するオプションを選択することもできます。添付ファイルには、必要なパラメータの詳細が含まれています。詳細については、「アラートコンテンツの機能強化」を参照してください。
次のデータは、メールまたはCitrix Alertsページでアラートとして受信されます。
| フィールド | 説明 |
|---|---|
| 顧客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
次の行を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
上記の画像から、ポリシーが作成され、Uidが10であることがわかります。
構成にメールを追加するには
Set-MonitorNotificationEmailServerConfiguration -ProtocolType SMTP -ServerName NameOfTheSMTPServerOrIPAddress -PortNumber 80 -SenderEmailAddress loki@abc.com -RequiresAuthentication 0
ポリシーにメールを追加するには
Add-MonitorNotificationPolicyEmailAddresses -Uid $policy.Uid -EmailAddresses $emailaddress -EmailCultureName "en-US"
メールを追加するためのサンプルスクリプト:
Add-MonitorNotificationPolicyEmailAddresses -Uid 10 -EmailAddresses $emailaddress -EmailCultureName "en-US"
ポリシーにWebhook URLを追加するには
Set-MonitorNotificationPolicy –Uid $polcy.Uid –Webhook 'URL'
Webhook URLを追加するためのサンプルスクリプト:
Set-MonitorNotificationPolicy –Uid 10 –Webhook 'https://hooks.slack.com/triggers/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'
作成されたポリシーの詳細を取得
Get-MonitorNotificationPolicy -Uid 10
アラートポリシーを作成する
アラートポリシーを作成するには、たとえば、特定のセッション数条件が満たされたときにアラートを生成するには、次の手順を実行します。
-
アラート > Citrixアラートポリシーに移動し、たとえば、マルチセッションOSポリシーを選択します。
-
作成をクリックします。
-
ポリシーに名前を付けて説明し、アラートがトリガーされるために満たす必要がある条件を設定します。たとえば、ピーク接続セッション、ピーク切断セッション、およびピーク同時合計セッションの警告値と危険値を指定します。警告値は危険値より大きくしてはいけません。詳細については、アラートポリシーの条件を参照してください。
-
再アラート間隔を設定します。アラートの条件が引き続き満たされている場合、この時間間隔でアラートが再度トリガーされ、アラートポリシーで設定されている場合は、メール通知が生成されます。却下されたアラートは、再アラート間隔でメール通知を生成しません。
-
スコープを設定します。たとえば、特定のデリバリーグループに設定します。
-
通知設定で、アラートがトリガーされたときにメールで通知する必要があるユーザーを指定します。アラートポリシーでメール通知設定を行うには、メールサーバー構成タブでメールサーバーを指定する必要があります。
-
.CSV添付ファイルまたはJSONペイロードを介してアラートコンテンツを受信することもできます。これには、次のチェックボックスをオンにします。
-
Webhookにjsonペイロードを添付として含める
-
メールにcsvファイルを添付として含める
-
注:.CSV添付ファイルおよびJSONペイロードを介してアラートコンテンツを受信するオプションは、現在、一部のアラートでのみ利用可能です。詳細については、「アラートコンテンツの機能強化」を参照してください。 -
-
「保存」をクリックします。
スコープで20以上のデリバリーグループが定義されたポリシーを作成すると、構成の完了に約30秒かかる場合があります。この間、スピナーが表示されます。
最大20の固有のデリバリーグループ(合計1000のデリバリーグループターゲット)に対して50を超えるポリシーを作成すると、応答時間が増加する可能性があります(5秒以上)。
アクティブなセッションを含むマシンをあるデリバリーグループから別のデリバリーグループに移動すると、マシンパラメーターを使用して定義された誤ったデリバリーグループアラートがトリガーされる可能性があります。
注:
アラートポリシーを削除した後、そのポリシーによって生成されたアラート通知が停止するまでに最大30分かかる場合があります。
アラートコンテンツの機能強化
Directorのアラート機能が強化され、CSV添付ファイルとJSONペイロードが含まれるようになりました。この機能強化により、メールでCSV添付ファイルとして、またはWebhookがある場合はJSONペイロードとしてアラートの詳細を取得できます。このCSV添付ファイルまたはJSONペイロードを使用すると、詳細レベルで豊富なコンテンツを受信でき、問題の迅速な特定と解決に役立ちます。
現在、この機能強化は次のアラートでのみ利用可能です。
-
マシンの稼働時間
-
電源オンアクションの失敗
-
電源オフアクションの失敗
-
未登録マシン (%)
この機能を使用するには、アラートに移動し、次のチェックボックスを選択します。
-
Webhookにjsonペイロードを添付として含める
-
メールにcsvファイルを添付として含める
以下は、Citrix Alert Policiesセクションのスクリーンショットです。
強化されたアラート(/en-us/citrix-virtual-apps-desktops/current-release/media/csv-and-webhook.png)
以下は、Advanced Alert Policiesセクションのスクリーンショットです。
強化されたアラート(詳細)(/en-us/citrix-virtual-apps-desktops/current-release/media/csv-and-webhook-advanced.png)
CSV添付ファイル
次の表は、サポートされているすべてのアラートの.CSV添付ファイルの列を示しています。
| 列 | 適用されるアラート |
|---|---|
| マシン名、IPアドレス、およびデリバリーグループ名 | マシンの稼働時間、電源オフ失敗アクションと電源オン失敗アクション、および未登録マシン(%) |
| 現在の登録状態、失敗日、障害状態、およびライフサイクル状態 | 未登録マシン(%) |
| 最終電源アクション失敗理由、最終電源アクショントリガー元、最終電源アクションタイプ、および最終電源アクション完了日 | 電源オフ失敗アクションと電源オン失敗アクション |
| 電源状態、電源オン日時、総稼働時間(分) | マシンの稼働時間 |
Webhookペイロード
未登録マシンの割合アラート
{
"text": "{\"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\":[{\"MachineName\":\"<Name of the Machine>\",\"IPAddress\":\"<IP Address>\",\"DeliveryGroupName\":\"<Name of the DeliveryGroup>\",\"CurrentRegistrationState\":\"Unregistered\",\"FailureDate\":\"<Date of Failure>\",\"FaultState\":\"<Fault State of the Machine>\",\"LifecycleState\":\"<Lifecycle state of the Machine>\"},{\"MachineName\":\"<Name of the Machine>\",\"IPAddress\":\"<IP Address>\",\"DeliveryGroupName\":\"<Name of the DeliveryGroup>\",\"CurrentRegistrationState\":\"Unregistered\",\"FailureDate\":\"<Date of Failure>\",\"FaultState\":\"<Fault State of the Machine>\",\"LifecycleState\":\"<Lifecycle state of the Machine>\"}]}"
}
電源オン失敗アクションアラート
{
"text": "{\"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\":[{\"MachineName\":\"<Name of the Machine>\",\"IPAddress\":\"<IP Address>\",\"DeliveryGroupName\":\"<Name of the DeliveryGroup>\",\"LastPowerActionFailureReason\":\"<HypervisorReportedFailure, HypervisorRateLimitExceeded, UnknownError, Power Action Type>\",\"LastPowerActionTriggeredBy\":\"<End-User, Administrator, Auto-Scale, Schedule>\",\"LastPowerActionType\":\"<PowerOn/PowerOff>\",\"LastPowerActionCompletedDate\":\"<Time string Eg: 2024-05-15T15:04:27.723>\"},{\"MachineName\":\"<Name of the Machine>\",\"IPAddress\":\"<IP Address>\",\"DeliveryGroupName\":\"<Name of the DeliveryGroup>\",\"LastPowerActionFailureReason\":\"<HypervisorReportedFailure, HypervisorRateLimitExceeded, UnknownError, Power Action Type>\",\"LastPowerActionTriggeredBy\":\"<End-User, Administrator, Auto-Scale, Schedule>\",\"LastPowerActionType\":\"<PowerOn/PowerOff>\",\"LastPowerActionCompletedDate\":\"<Time string Eg: 2024-05-15T15:04:27.723>\"}]}"
}
電源オフ失敗アクションアラート
{
"text": "{\"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\":[{\"MachineName\":\"<Name of the Machine>\",\"IPAddress\":\"<IPV4 Address of the Machine>\",\"DeliveryGroupName\":\"<Name of the DeliveryGroup>\",\"LastPowerActionFailureReason\":\"<HypervisorReportedFailure,HypervisorRateLimitExceeded,UnknownError,Power Action Type>\",\"LastPowerActionTriggeredBy\":\"<End-User,Administrator,Auto-Scale,Schedule>\",\"LastPowerActionType\":\"<PowerOn/PowerOff>\",\"LastPowerActionCompletedDate\":\"<Time string Eg: 2024-05-15T15:04:27.723>\"},{\"MachineName\":\"<Name of the Machine>\",\"IPAddress\":\"<IPV4 Address of the Machine>\",\"DeliveryGroupName\":\"<Name of the DeliveryGroup>\",\"LastPowerActionFailureReason\":\"<HypervisorReportedFailure,HypervisorRateLimitExceeded,UnknownError,Power Action Type>\",\"LastPowerActionTriggeredBy\":\"<End-User,Administrator,Auto-Scale,Schedule>\",\"LastPowerActionType\":\"<PowerOn/PowerOff>\",\"LastPowerActionCompletedDate\":\"<Time string Eg: 2024-05-15T15:04:27.723>\"}]}"
}
マシンの稼働時間アラート
{
"text": "{\"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\":[{\"MachineName\":\"<Name of the Machine>\",\"IPAddress\":\"<IP Address>\",\"DeliveryGroupName\":\"<Name of the DeliveryGroup>\",\"PowerState\":\"<On/Off>\",\"PoweredOnDate\":\"2024-05-15T15:04:27.723\",\"TotalUptimeInMinutes\":180},{\"MachineName\":\"<Name of the Machine>\",\"IPAddress\":\"<IP Address>\",\"DeliveryGroupName\":\"<Name of the DeliveryGroup>\",\"PowerState\":\"<ON/OFF>\",\"PoweredOnDate\":\"2024-05-15T15:04:27.723\",\"TotalUptimeInMinutes\":\"<Uptime Duration>\"}]}"
}
アラートポリシーの条件
以下に、アラートカテゴリ、アラートを軽減するための推奨アクション、および定義されている場合は組み込みポリシー条件を示します。組み込みのアラートポリシーは、アラートおよび再アラートの間隔が60分に設定されています。
ピーク接続セッション
-
Directorのセッショントレンドビューで、接続済みセッションのピークを確認します。
-
セッション負荷に対応する十分な容量があることを確認してください。
-
必要に応じて新しいマシンを追加する
ピーク切断セッション
-
Directorのセッショントレンドビューで、切断済みセッションのピークを確認します。
-
セッション負荷に対応できる十分な容量があることを確認します。
-
必要に応じて、新しいマシンを追加します。
-
必要に応じて、切断されたセッションをログオフします。
ピーク時の同時合計セッション数
-
Directorのセッショントレンドビューで、同時セッションのピークを確認します。
-
セッション負荷に対応できる十分な容量があることを確認します。
-
必要に応じて、新しいマシンを追加します。
-
必要に応じて、切断されたセッションをログオフします。
CPU
-
必要に応じてプロセスを終了します。
-
プロセスを終了すると、保存されていないデータが失われます。
-
すべてが期待どおりに機能している場合は、将来的に追加のCPUリソースを追加します。注:リソース監視を有効にするポリシー設定は、VDAがインストールされているマシンでのCPUおよびメモリのパフォーマンスカウンターの監視に対して、デフォルトで許可されています。このポリシー設定が無効になっている場合、CPUおよびメモリの状態に関するアラートはトリガーされません。詳しくは、「監視ポリシー設定」を参照してください。スマートポリシー条件:
-
スコープ: デリバリーグループ、マルチセッションOSスコープ
-
しきい値: 警告 - 80%、危険 - 90%
-
メモリ
メモリ使用率は、VDA上の全体的なメモリ消費量(プロセスによるものを含む)を示します。個々のプロセスによるメモリ使用量に関する詳細な情報は、対応するVDAのマシン詳細ページから取得できます。
-
[マシン詳細]>[履歴使用率の表示]>[上位10プロセス] に移動し、メモリを消費しているプロセスを特定します。プロセスレベルのリソース使用状況統計の収集を開始するには、プロセス監視ポリシーが有効になっていることを確認してください。
-
必要に応じてプロセスを終了します。
-
プロセスを終了すると、保存されていないデータが失われます。
-
すべてが期待どおりに機能している場合は、将来的に追加のメモリを追加します。注:リソース監視を有効にするポリシー設定は、VDAがインストールされているマシンでのCPUおよびメモリのパフォーマンスカウンターの監視に対して、デフォルトで許可されています。このポリシー設定が無効になっている場合、CPUおよびメモリの状態に関するアラートはトリガーされません。詳しくは、「監視ポリシー設定」を参照してください。スマートポリシー条件:
-
スコープ: デリバリーグループ、マルチセッションOSスコープ
-
閾値: 警告 - 80%、危機的 - 90%
-
接続失敗率
過去1時間の接続失敗の割合。
-
試行された総接続数に対する総失敗数に基づいて計算されます。
-
Directorの接続失敗トレンドビューで、構成ログから記録されたイベントを確認します。
-
アプリケーションまたはデスクトップが到達可能であるかどうかを判断します。
接続失敗数
過去1時間の接続失敗数。
-
Director Connection Failures Trendsビューで、構成ログから記録されたイベントを確認します。
-
アプリケーションまたはデスクトップが到達可能であるかどうかを判断します。
ICA® RTT (平均)
平均ICAラウンドトリップ時間。
-
ICA RTTの内訳についてCitrix ADMを確認し、根本原因を特定します。詳細については、Citrix ADMドキュメントを参照してください。
-
Citrix ADMが利用できない場合は、Directorのユーザー詳細ビューでICA RTTと遅延を確認し、ネットワークの問題か、アプリケーションまたはデスクトップの問題かを判断します。
ICA RTT (セッション数)
閾値のICAラウンドトリップ時間を超えるセッションの数。
-
ICA RTTが高いセッション数についてCitrix ADMを確認します。詳細については、Citrix ADMドキュメントを参照してください。
-
Citrix ADMが利用できない場合は、ネットワークチームと協力して根本原因を特定します。スマートポリシーの条件:
-
スコープ: デリバリーグループ、マルチセッションOSスコープ
-
しきい値: 警告 - 5セッション以上で300ミリ秒、重大 - 10セッション以上で400ミリ秒
-
ICA RTT (セッションの割合)
平均ICAラウンドトリップ時間を超えるセッションの割合。
-
ICA RTTが高いセッション数についてCitrix ADMを確認します。詳細については、Citrix ADMドキュメントを参照してください。
-
Citrix ADMが利用できない場合は、ネットワークチームと協力して根本原因を特定します。
ICA RTT (ユーザー)
指定されたユーザーによって起動されたセッションに適用されるICAラウンドトリップ時間。ICA RTTが少なくとも1つのセッションでしきい値を超えた場合、アラートがトリガーされます。
失敗したマシン(シングルセッションOS)
失敗したシングルセッションOSマシンの数。失敗は、Directorのダッシュボードおよびフィルタービューに示されているように、さまざまな理由で発生する可能性があります。
-
Citrix Scout診断を実行して、根本原因を特定します。スマートポリシー条件:
-
スコープ: デリバリーグループ、マルチセッションOSスコープ
-
しきい値: 警告 - 1、重大 - 2
-
失敗したマシン (マルチセッションOS)
失敗したマルチセッションOSマシンの数。失敗は、Directorのダッシュボードおよびフィルタービューに示されているように、さまざまな理由で発生する可能性があります。
-
Citrix Scout診断を実行して、根本原因を特定します。スマートポリシー条件:
-
スコープ: デリバリーグループ、マルチセッションOSスコープ
-
しきい値: 警告 - 1、重大 - 2
-
失敗したマシン (割合)
デリバリーグループ内の失敗したシングルセッションおよびマルチセッションOSマシンの割合。これは、失敗したマシンの数に基づいて計算されます。このアラート条件では、デリバリーグループ内の失敗したマシンの割合としてアラートしきい値を構成でき、30秒ごとに計算されます。 失敗は、Directorのダッシュボードおよびフィルタービューに示されているように、さまざまな理由で発生する可能性があります。Citrix Scout診断を実行して、根本原因を特定します。詳細については、「ユーザーの問題のトラブルシューティング」を参照してください。
電源オンアクションの失敗と電源オフアクションの失敗
デリバリーグループ内の電源オンアクションの失敗数と電源オフアクションの失敗数。これは、電源オンまたはオフに失敗した電源管理マシンの数に基づいて計算されます。このアラート条件では、デリバリーグループ内で電源オンまたはオフに失敗した電源管理マシンの数としてアラートしきい値を構成でき、30分ごとに計算されます。
管理者は、高度なアラートポリシーでこれらのアラートに対して次のパラメーターを構成できます。
-
トリガー元: 電源アクションをトリガーしたもの
-
失敗の理由: なぜアクションが失敗したのか
-
しきい値: ポリシーをトリガーするために電源アクションが失敗したマシンのしきい値の数
-
サンプリング間隔: 失敗した電源アクションをチェックする必要がある間隔
-
再アラート間隔: アラートを再送信するまでの時間
失敗は、Directorのダッシュボードおよびフィルタービューに示されているように、さまざまな理由で発生する可能性があります。Citrix Scout診断を実行して、根本原因を特定します。詳細については、「ユーザーの問題のトラブルシューティング」を参照してください。
未登録マシン(%)
マシンが再起動によって不安定になった場合、またはデリバリーコントローラーと仮想マシン間の通信に問題がある場合、マシンは未登録と見なされます。**未登録マシン(%)**は、デリバリーグループ内の未登録のシングルセッションおよびマルチセッションOSマシンの割合であり、未登録マシンの数に基づいて計算されます。このアラート条件では、デリバリーグループ内の未登録マシンの割合として、警告およびクリティカルなしきい値を構成できます。再アラートの間隔を設定できます。未登録マシン(%)の条件が満たされたときに通知を受け取るために、メールを追加することもできます。クリティカルまたは警告のしきい値を超えると、アラートとメールが生成されます。アラートはCitrix Alertsで確認できます。**未登録マシン(%)**カテゴリ、および必要な状態と時間でフィルターできます。
メールがある場合はCSV添付ファイルで、Webhookがある場合はJSONペイロードで、アラートの詳細を受け取ることもできます。
注:
クリティカル値は警告値よりも大きくする必要があります。
ポリシー条件:
-
スコープ: シングルセッションOS、およびマルチセッションOSデリバリーグループ
-
しきい値: 警告とクリティカル
マシン稼働時間アラート
デリバリーグループ内のマシンの稼働時間は、デリバリーグループ内で電源がオンになっているマシンの1日あたりの時間数、1週間あたりの時間数、または1か月あたりの時間数に基づいて計算されます。このアラート条件を使用すると、デリバリーグループ内でマシンが電源オンになっている時間としてアラートしきい値を構成できます。マシンの稼働時間アラートは、次の場合に次のように機能します。
-
1日あたりの時間数 - マシンが1日あたり電源オンになっている時間数を指定でき、30分ごとに計算されます。設定できる1日あたりの最大時間数は24時間です。
-
週あたりの時間 - マシンが1週間に稼働する時間を指定でき、6時間ごとに計算されます。設定できる週あたりの最大時間は168時間です。
-
月あたりの時間 - マシンが1ヶ月に稼働する時間を指定でき、毎日1回計算されます。月あたりの最大時間は720時間です。 設定できる再アラート間隔の最小値は60分です。警告および重大アラートセクションで、マシンの稼働時間しきい値を超過するマシンの数を入力できます。また、任意のマシンに対して例外を追加することもできます。
たとえば、このアラートに5つのデリバリーグループが追加されており、最初のデリバリーグループと4番目のデリバリーグループでマシンの数が警告または重大なしきい値を超えた場合、アラートは最初のデリバリーグループと4番目のデリバリーグループに対して個別にトリガーされます。
このアラートは、管理者がマシンの稼働時間を分析するのに役立ち、この分析に基づいて管理者はコストの最適化に貢献できます。メールがある場合はCSV添付ファイルで、Webhookがある場合はJSONペイロードで、アラートの詳細を受け取ることもできます。
平均ログオン時間
過去1時間に発生したログオンの平均ログオン時間。
-
Directorダッシュボードでログオン期間に関する最新のメトリックを確認します。短期間に多くのユーザーがログオンすると、ログオン期間が長くなる可能性があります。
-
ログオンのベースラインと内訳を確認して、原因を絞り込みます。詳細については、「ユーザーログオンの問題の診断」を参照してください。スマートポリシー条件:
-
スコープ: デリバリーグループ、マルチセッションOSスコープ
-
しきい値: 警告 - 45秒、重大 - 60秒
-
ログオン時間(ユーザー)
過去1時間に発生した、指定されたユーザーのログオンのログオン時間。
負荷評価インデックス
過去5分間の負荷評価インデックスの値。
-
ピーク負荷(最大負荷)が発生している可能性のあるマルチセッションOSマシンについて、Directorで確認します。ダッシュボード(障害)とトレンドの負荷評価インデックスレポートの両方を確認します。スマートポリシーの条件:
-
スコープ: デリバリーグループ、マルチセッションOSスコープ
-
しきい値: 警告 - 80%、重大 - 90%
-
Webhook を使用してアラートポリシーを構成する
電子メール通知とは別に、Webhook を使用してアラートポリシーを構成できます。
注: この機能には、Delivery Controller バージョン 7.11 以降が必要です。
PowerShell コマンドレットを使用して、HTTP コールバックまたは HTTP POST でアラートポリシーを構成できます。これらは Webhook をサポートするように拡張されています。
新しい 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>
既存のアラートポリシーに 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\>}
アラートの一括解除
この機能は、管理者のアラート管理プロセスを最適化し、柔軟性を提供し、アラート疲労を軽減します。管理者は、時間、種類、またはカテゴリに基づいてアラートを一括解除でき、メンテナンス中やハイパーバイザーおよびその他の環境を扱う際のアラート管理を簡素化します。
アラートの一括解除は、管理者がワークロードを効率的に管理し、大量のアラートに圧倒されるのを防ぐのに役立ちます。
アラートを一括解除する手順
-
アラート > Citrixアラートタブに移動します。アラートが表示されます。「一括アラート」(/en-us/citrix-virtual-apps-desktops/current-release/media/bulk-alert.png)
-
ソース、カテゴリ、状態、または期間からオプションを選択して、解除したいアラートをフィルタリングします。特定のアラートが表示されます。
-
特定のアラートの横にあるチェックボックスを選択するか、上部にあるチェックボックスを選択してすべてのアラートを選択します。
-
解除をクリックします。アラートの解除を確認する通知が表示されます。
-
はいをクリックします。選択されたアラートは解除済みとしてマークされ、アラートのステータスがそれに応じて更新されます。
PowerShell SDKを使用したWebhook構成
PowerShell SDKを使用したWebhook構成機能により、管理者はWebhookプロファイルを作成、変更、削除、および一覧表示できます。この機能は、ヘッダー、認証タイプ、コンテンツタイプ、ペイロード、およびWebhook URLの指定を可能にすることで、Webhookの構成に柔軟性を提供します。
注:
サポートされているペイロード形式はテキストであり、エンドユーザーはWebhookでテキストを有効にする必要があります。
最新のペイロード形式は次のとおりです。
{"text": "This is a message from a Webex incoming webhook."}
Webhookを作成する
次のPowerShellサンプルコマンドを使用して、Webhookプロファイルを作成できます。
認証ヘッダーなしで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
認証ヘッダーを使用してWebhookを作成するには:
$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
プロファイルが作成されたら、データベースで確認できます。また、新しく作成されたWebhookプロファイルは、Citrix Alertsページで見つけることができます。
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
すべてのWebhookプロファイルの一覧を取得する
利用可能なすべてのWebhookプロファイルの一覧を取得するには、次のPowerShellコマンドのサンプルを使用できます。
Get-MonitorWebhookProfile
Get-MonitorWebhookProfile -Name 'profile_msteams'
Get-MonitorWebhookProfile -Uid 1
Webhookプロファイルを削除する
Webhookプロファイルを削除するには、次のPowerShellコマンドのサンプルを使用できます。
Remove-MonitorWebhookProfile -Uid 1
注:
Webhookプロファイルがいずれかのポリシーにマッピングされている場合、削除できません。回避策として、まずポリシーからWebhookマッピングを削除する必要があります。
Webhookプロファイルを使用してポリシーを作成する
Webhookプロファイルを使用してポリシーを作成するには、次のPowerShellコマンドのサンプルを使用できます。
New-MonitorNotificationPolicy -Name "Policy1" -Description "Policy Description" -Enabled $true -WebhookProfileId 1
Webhookプロファイルを使用してポリシーを更新する
Webhookプロファイルを使用してポリシーを更新するには、次のPowerShellコマンドのサンプルを使用できます。
$Policy = Set-MonitorNotificationPolicy -Uid 1 -WebhookProfileId 1
ポリシーからWebhookマッピングを削除する
ポリシーからWebhookプロファイルを削除するには、次のPowerShellコマンドのサンプルを使用できます。
$Policy = Set-MonitorNotificationPolicy -Uid 1 -WebhookProfileId 0
Webhookプロファイルをテストする
Webhookプロファイルをテストするには、次のPowerShellコマンドのサンプルを使用できます。
$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
ハイパーバイザーアラートの監視
Directorは、ハイパーバイザーの健全性を監視するためのアラートを表示します。XenServer®およびVMware vSphereからのアラートは、ハイパーバイザーのパラメーターと状態の監視に役立ちます。ハイパーバイザーへの接続ステータスも監視され、ホストのクラスターまたはプールが再起動されたり、利用できなくなったりした場合にアラートが提供されます。
ハイパーバイザーアラートを受信するには、Web Studioでホスティング接続が作成されていることを確認してください。詳細については、「接続とリソース」を参照してください。ハイパーバイザーアラートの監視対象となるのは、これらの接続のみです。
これらのアラートは、しきい値に達するか、それを超えると表示されます。ハイパーバイザーアラートには次のものがあります。
-
重大 — ハイパーバイザーアラームポリシーの重大なしきい値に達したか、超えた場合
-
警告 — ハイパーバイザーアラームポリシーの警告しきい値に達したか、超えた場合
-
却下済み — アクティブなアラートとして表示されなくなったアラート
この機能には、Delivery Controllerバージョン7 1811以降が必要です。サイト7 1811以降で古いバージョンのDirectorを使用している場合、ハイパーバイザーアラートの数のみが表示されます。アラートを表示するには、Directorをアップグレードする必要があります。
次の表は、ハイパーバイザーアラートのさまざまなパラメーターと状態について説明しています。
| アラート | サポートされているハイパーバイザー | トリガー元 | 条件 | 構成 |
|---|---|---|---|---|
| CPU使用率 | ゼノサーバー、ヴイエムウェア ブイスフィア | ハイパーバイザー | CPU使用率アラートのしきい値に達したか、超えた場合 | アラートのしきい値はハイパーバイザーで構成する必要があります。 |
| メモリ使用量 | ゼノサーバー、ヴイエムウェア ブイスフィア | ハイパーバイザー | メモリ使用量アラートしきい値に達したか、超過しました | アラートのしきい値はハイパーバイザーで構成する必要があります。 |
| ネットワーク使用量 | ゼノサーバー、ヴイエムウェア ブイスフィア | ハイパーバイザー | ネットワーク使用量アラートしきい値に達したか、超過しました | アラートのしきい値はハイパーバイザーで構成する必要があります。 |
| ディスク使用量 | ヴイエムウェア ブイスフィア | ハイパーバイザー | ディスク使用量アラートしきい値に達したか、超過しました | アラートのしきい値はハイパーバイザーで構成する必要があります。 |
| ホスト接続または電源状態 | ヴイエムウェア ブイスフィア | ハイパーバイザー | ハイパーバイザーホストが再起動されたか、利用できません | アラートはVMware vSphereにプリビルドされています。追加の構成は不要です。 |
| ハイパーバイザー接続が利用できません | ゼノサーバー、ヴイエムウェア ブイスフィア | デリバリーコントローラー | ハイパーバイザー(プールまたはクラスター)への接続が失われたか、電源がオフになったか、再起動されました。このアラートは、接続が利用できない間、1時間ごとに生成されます。 | アラートはDelivery Controllerにプリビルドされています。追加の構成は不要です。 |
注:
アラートの構成の詳細については、Citrix XenCenter Alerts を参照するか、VMware vCenter Alertsのドキュメントを確認してください。
メール通知設定は、Citrix Alerts Policy > Site Policy > Hypervisor Healthで構成できます。ハイパーバイザーアラートポリシーのしきい値条件は、Directorからではなく、ハイパーバイザーからのみ構成、編集、無効化、または削除できます。ただし、メール設定の変更やアラートの解除はDirectorで行うことができます。インフラストラクチャの監視が役割に含まれていない場合は、アラートを無効にできます。
重要:
-
ハイパーバイザーによってトリガーされたアラートは、Directorで取得および表示されます。ただし、ハイパーバイザーアラートのライフサイクル/状態の変更はDirectorには反映されません。
-
ハイパーバイザーコンソールで正常、解除済み、または無効になっているアラートは、Directorに表示され続け、明示的に解除する必要があります。
-
Directorで解除されたアラートは、ハイパーバイザーコンソールでは自動的に解除されません。
垂直および水平ロードバランシングアラートの処理の改善
以前は、
UseVerticalScalingForRdsLaunchesをtrueに設定し、Studioで「最大セッション数」ポリシーを構成すると、マシンは「最大容量」状態に移行しました。Directorは、制限が垂直ロードバランシングまたは水平ロードバランシングのいずれかによって達したかどうかにかかわらず、「最大容量」のアラートをトリガーしました。「最大負荷に達しました」などの特定のエラーが発生した場合、垂直ロードバランシングと水平ロードバランシングを区別する方法はありませんでした。これにより、垂直スケーリングシナリオにおける予期される動作に対して不要なアラートが発生し、時間と混乱を招いていました。
現在、垂直ロードバランシングがアクティブでマシンがセッション制限に達すると、「垂直スケーリングの最大容量」という新しい状態に移行します。Directorはこの新しい状態に対してアラートを生成しなくなりました。アラートは、水平スケーリングシナリオにおける「最大容量」に対してのみトリガーされます。新しい状態は、フィルターおよびカスタムレポートページで表示でき、これにより、予期される状態と例外的な状態を区別しやすくなります。この機能強化により、不要なアラートを回避し、実際の問題に集中できるようになり、監視とトラブルシューティングが効率化されます。これは、Set-BrokerSiteを使用して
UseVerticalScalingForRdsLaunchesを構成し、Studioで「最大セッション数」ポリシーを設定した場合に適用されます。