アラートと通知
アラートは、ダッシュボードやその他の高レベルビューのMonitorに、警告および重大なアラートシンボルとともに表示されます。アラートは1分ごとに自動的に更新されます。必要に応じてアラートを更新することもできます。

警告アラート(琥珀色の三角形)は、条件の警告しきい値に達したか、超過したことを示します。
重大なアラート(赤い円)は、条件の重大なしきい値に達したか、超過したことを示します。
アラートに関する詳細情報は、サイドバーからアラートを選択するか、サイドバーの下部にある [アラートに移動] リンクをクリックするか、Monitorページの上部から [アラート] を選択することで表示できます。
アラートビューでは、アラートをフィルタリングしてエクスポートできます。たとえば、過去1か月間の特定のデリバリーグループの失敗したMulti-session OSマシン、または特定のユーザーのすべてのアラートなどです。詳細については、レポートのエクスポートを参照してください。

Citrix®アラート
Citrixアラートは、Citrixコンポーネントから発生するアラートです。Monitorの [アラート] > [Citrixアラートポリシー] でCitrixアラートを構成できます。構成の一部として、アラートが設定したしきい値を超過したときに、個人やグループに電子メールで通知を送信するように設定できます。Citrixアラートの設定の詳細については、アラートポリシーの作成を参照してください。
スマートアラートポリシー
- デリバリーグループおよびMulti-session OS VDAのスコープには、事前定義されたしきい値を持つ一連の組み込みアラートポリシーが用意されています。組み込みアラートポリシーのしきい値パラメーターは、[アラート] > [Citrixアラートポリシー] で変更できます。
- これらのポリシーは、サイトに少なくとも1つのアラートターゲット(デリバリーグループまたはMulti-session OS VDA)が定義されている場合に作成されます。また、これらの組み込みアラートは、新しいデリバリーグループまたはMulti-session OS VDAに自動的に追加されます。
組み込みアラートポリシーは、Monitorデータベースに対応するアラートルールが存在しない場合にのみ作成されます。
組み込みアラートポリシーのしきい値については、アラートポリシーの条件セクションを参照してください。

高度なアラートポリシー
- Monitorのプロアクティブ通知およびアラート機能が強化され、**高度なアラートポリシー**という新しいアラートフレームワークが追加されました。この機能を使用すると、各要素または条件のきめ細かな詳細を含めることでアラートを作成でき、アラートスコープの制御が強化されます。現在、これらのポリシーには、コスト削減とインフラストラクチャに関するアラートが含まれています。
- データソース駆動型アラートである高度なアラートポリシーの導入により、複数条件のスコープフィルタリングを使用できます。
この機能は、過剰なアラートを減らすのに役立ち、重要な問題への対応や効果の低下につながる可能性があります。このポリシーは、アラートポリシーの有効性と管理者からのエンゲージメントを測定するのに役立ちます。
- **[アラート]** \> **[高度なアラートポリシー]** \> **[ポリシーの作成]** セクションから、高度なアラートポリシーを作成できます。
- 次のデータソースのいずれかを選択できます。
- マシン
- Provisioning Service
- StoreFront™
コスト削減のためのアラート
- コストを最適化するのに役立つコスト削減のためのアラートを作成できます。現在、マシンに関するアラートを作成できます。
- マシンに関するアラートを作成するには、次の手順を実行します。
- [アラート] タブ > [高度なアラートポリシー] をクリックします。[高度なアラートポリシー] ページが表示されます。
- [ポリシーの作成] をクリックします。[高度なアラートポリシーの作成] セクションが表示されます。
- データソースドロップダウンリストから [マシン] を選択します。コスト削減条件と対応する条件タイプが表示されます。

-
必要に応じて、次の条件タイプを選択します。
- **電源管理対象マシンが起動に失敗しました** - **電源管理対象マシンがシャットダウンに失敗しました** - **稼働時間の長い電源管理対象マシン** -
選択した各条件について、特定のパラメーターと対応するオプションを選択します。 - 1. 選択した条件タイプの警告および重大なメトリックを設定します。
- **稼働時間の長い電源管理対象マシン**の場合: - 稼働時間しきい値を超過するマシンの数 - 再アラート間隔(分単位)。間隔は最小60分です。-
電源管理対象マシンが起動に失敗しました および 電源管理対象マシンがシャットダウンに失敗しました の場合:
- 稼働時間しきい値を超過するマシンの数
- サンプリング間隔(分単位)。間隔は30分の倍数です。
-
再アラート間隔(分単位)。再アラートは60分の倍数です。
-
- 必要に応じて、選択したアラートの再アラート間隔をスケジュールします。
-
- アラートのスコープを定義します。
-
通知チャネルを設定します。これは電子メールまたはWebhookにすることができます。
-
次のチェックボックスを選択できます。
- WebhookにJSONペイロードを添付ファイルとして含める
- 電子メールにCSVファイルを添付ファイルとして含める
-
- [アラートの詳細] ([アラート名] や [説明] (オプション)など)を入力します。 - 1. [保存] をクリックします。アラートが作成されます。
SPA接続遅延のアラート
- 「高度なアラートポリシー」フレームワークは、Secure Private Access (SPA) 接続のプロアクティブなアラートをサポートします。このポリシーを使用して、SPAユーザー接続に影響するエンドツーエンドの遅延を検出し、対処します。
SPA接続遅延アラートの設定
-
SPA接続遅延のアラートを作成するには、次の手順を実行します。
-
- [アラート] タブ > [高度なアラートポリシー] をクリックします。[高度なアラートポリシー] ページが表示されます。
-
- [ポリシーの作成] をクリックします。[高度なアラートポリシーの作成] セクションが表示されます。
- [データソース] ドロップダウンリストから [Secure Private Access] を選択します。SPA接続遅延の条件が表示されます。
-
必要に応じて、次のメトリックタイプを選択します。
- ISP遅延 (クライアント → CDN)
- 接続遅延 (クライアント → ゲートウェイPoP)
- ISP遅延 (クライアント → CDN)

- 接続遅延 (クライアント → ゲートウェイPoP)

- 選択した各メトリックについて、特定のパラメーターと対応するオプションを選択します。
-
選択した条件タイプに対して、警告および重大なメトリックを設定します。
- 遅延しきい値 (ミリ秒単位): 警告 (例: 150~200ミリ秒) および重大 (例: 300~400ミリ秒) の値を設定します。
- 影響を受けるユーザー (数): しきい値を超える遅延を経験しているユーザーの数
- サンプリング間隔 (分単位): 遅延を評価する頻度 (例: 5~15分)
- 再アラート間隔 (分単位): アラート疲労を避けるため、最低60分を推奨
- 必要に応じて、選択したアラートの再アラート間隔をスケジュールします。
- アラートのスコープを定義します。サイト、デリバリーグループ、またはターゲットサブセットを選択します。
-
通知チャネルを設定します。これはメールまたはWebhookにすることができます。
-
次のチェックボックスを選択できます。
- WebhookにJSONペイロードを添付として含める
- メールにCSVファイルを添付として含める
-
- [アラート名] (例: 「SPA接続遅延 – PoP East」) や [説明] (オプション) などの [アラートの詳細] を入力します。
- [保存] をクリックします。アラートが作成されます。
推奨事項:
プロアクティブなアラートのために、地域ごとのベースライン測定に基づいて遅延しきい値を調整します。Webhook統合を含めて、高遅延アラートをインシデント管理にルーティングし、より迅速なトリアージを行います。
インフラストラクチャポリシー
次のサポートされているCitrix DaaS™コンポーネントの健全性を監視するアラートを作成できます。
- Provisioning Service

- StoreFront

- Cloud Connector

- Connector Appliance

インフラストラクチャ監視のセットアップが完了すると、Monitorで利用可能な健全性データを使用して、必要なコンポーネントのアラートを設定できます。管理者は、条件、スコープ、および通知媒体を設定して、メールまたはWebhookを介したJSONペイロードで重要なアラートを受信できます。発生したアラートは、分析と管理のために [Citrix Alerts] セクションでも利用できます。
新しく導入されたインフラストラクチャポリシーの一部として、アラート条件は次の4つのセクションに分類されます。
- 到達可能性
- 依存サービス
- 影響
- リソース使用率
各カテゴリ内の条件は、組織の優先順位に基づいて [重大] および [警告] の重大度で設定できます。これらのアラートの再アラート間隔をスケジュールすることもできます。
[アラート] > [Citrixアラートポリシー] セクションからインフラストラクチャポリシーを作成できます。必要なカテゴリを選択し、ポリシーに必要な条件を選択できます。ポリシーの作成方法の詳細については、「アラートポリシーの作成」を参照してください。ポリシーが作成された後、Citrix Alertsページでポリシーを編集、削除、または無効にできます。
各カテゴリおよびコンポーネントでサポートされている条件の詳細については、以下を参照してください。
次のデータは、メールまたはCitrix Alertページでアラートとして受信されます。
| フィールド | 説明 |
|---|---|
| 顧客ID | サイトの顧客ID。 |
| アラートレベル | 可能な値は「重大」と「警告」です。 |
| ターゲット | アラートがトリガーされたマシンの名前。 |
| 時間 | アラートがトリガーされた時刻。 |
| スコープ | ポリシーのスコープ。 |
| ポリシー | ポリシーの名前。 |
| 説明 | アラートがトリガーされた問題の説明。 |
ポリシーのスコープの定義
アラートのスコープを定義し、例外を追加できます。アラートは選択したスコープに対してのみ生成され、例外の追加を使用して除外されたサブスコープはアラート生成に含まれません。この機能は、きめ細かなレベルでアラートを作成するのに役立ちます。
メールまたは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
<!--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"
-
```
- メールを追加するサンプルスクリプト:
- 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

- ## アラートポリシーの作成

- アラートポリシーを作成するには、たとえば、特定のセッション数条件が満たされたときにアラートを生成する場合、次の手順を実行します。
1. **アラート** > **Citrix Alerts Policy** に移動し、たとえば、Multi-session OS Policy を選択します。
1. **作成** をクリックします。
- 1. ポリシーに名前を付けて説明し、アラートがトリガーされるために満たす必要がある条件を設定します。たとえば、ピーク接続セッション、ピーク切断セッション、およびピーク同時合計セッションの警告と重大のカウントを指定します。警告値は重大値より大きくしてはいけません。詳細については、「[アラートポリシーの条件](/ja-jp/citrix-daas/monitor/site-analytics/alerts-notifications.html#alerts-policies-conditions)」を参照してください。
- 1. 再アラート間隔を設定します。アラートの条件が引き続き満たされている場合、この時間間隔でアラートが再度トリガーされ、アラートポリシーで設定されている場合はメール通知が生成されます。却下されたアラートは、再アラート間隔でメール通知を生成しません。
1. スコープを設定します。たとえば、特定のデリバリーグループに設定します。
1. 通知設定で、アラートがトリガーされたときに誰にメールで通知するかを指定します。メール通知は SendGrid 経由で送信されます。メール設定でメールアドレス `donotreplynotifications@citrix.com` がホワイトリストに登録されていることを確認してください。
- 1. **保存** をクリックします。
スコープで 20 個以上のデリバリーグループが定義されたポリシーを作成すると、構成の完了に約 30 秒かかる場合があります。この間、スピナーが表示されます。
- 最大 20 個の固有のデリバリーグループ(合計 1000 個のデリバリーグループターゲット)に対して 50 個を超えるポリシーを作成すると、応答時間が増加する(5 秒を超える)可能性があります。
アクティブなセッションを含むマシンをあるデリバリーグループから別のデリバリーグループに移動すると、マシンパラメータを使用して定義された誤ったデリバリーグループアラートがトリガーされる可能性があります。
- > **注:**
>
> アラートポリシーを削除した後、そのポリシーによって生成されたアラート通知が停止するまでに最大 30 分かかる場合があります。
- ### アラートコンテンツの機能強化
Monitor のアラート機能が強化され、CSV 添付ファイルと JSON ペイロードが含まれるようになりました。この機能強化により、メールで CSV 添付ファイルとして、または Webhook がある場合は JSON ペイロードとしてアラートの詳細を取得できます。この CSV 添付ファイルまたは JSON ペイロードを使用すると、詳細レベルで豊富なコンテンツを受信でき、問題の迅速な特定と解決に役立ちます。
現在、この機能強化は次のアラートでのみ利用可能です。
- マシンの稼働時間
- 電源オンアクションの失敗
- 電源オフアクションの失敗
- 未登録マシン (%)
- この機能を使用するには、アラートに移動し、次のチェックボックスを選択します。
- **Webhook に JSON ペイロードを添付ファイルとして含める**
- **メールに CSV ファイルを添付ファイルとして含める**
以下は、**Citrixアラートポリシー**セクションのスクリーンショットです。

以下は、**高度なアラートポリシー**セクションのスクリーンショットです。
- 
- #### 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>\"}]}"
}
<!--NeedCopy-->
電源オン失敗アクションアラート
- {
- "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>\"}]}"
}
<!--NeedCopy-->
電源オフ失敗アクションアラート
- {
- "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>\"}]}"
}
<!--NeedCopy-->
マシン稼働時間アラート
{
"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>\"}]}"
}
<!--NeedCopy-->
アラートポリシーの条件
以下に、アラートカテゴリ、アラートを軽減するための推奨アクション、および定義されている場合は組み込みポリシーの条件を示します。組み込みアラートポリシーは、アラートおよび再アラートの間隔が60分に設定されています。
ピーク接続セッション
- ピーク接続セッションについては、[モニターセッショントレンド]ビューを確認します。
- セッション負荷に対応する十分な容量があることを確認します。
- 必要に応じて新しいマシンを追加します。
ピーク切断セッション
- ピーク切断セッションについては、[モニターセッショントレンド]ビューを確認します。
- セッション負荷に対応する十分な容量があることを確認します。
- 必要に応じて新しいマシンを追加します。
- 必要に応じて切断されたセッションをログオフします。
ピーク同時合計セッション
- ピーク同時セッションについては、モニターの[モニターセッショントレンド]ビューを確認します。
- セッション負荷に対応する十分な容量があることを確認します。
- 必要に応じて新しいマシンを追加します。
- 必要に応じて切断されたセッションをログオフします。
CPU
-
CPU使用率の割合は、プロセスを含むVDA全体のCPU消費量を示します。個々のプロセスによるCPU使用率の詳細については、対応するVDAの[マシン詳細]ページから確認できます。
- [マシン詳細] > [履歴使用率の表示] > [上位10プロセス] に移動し、CPUを消費しているプロセスを特定します。プロセスレベルのリソース使用状況統計の収集を開始するには、プロセス監視ポリシーが有効になっていることを確認してください。
- 必要に応じてプロセスを終了します。
-
プロセスを終了すると、保存されていないデータが失われます。
-
すべてが期待どおりに機能している場合は、将来的にCPUリソースを追加します。
-
注:
ポリシー設定[リソース監視を有効にする]は、VDAを搭載したマシンでのCPUおよびメモリパフォーマンスカウンターの監視に対して、デフォルトで許可されています。このポリシー設定が無効になっている場合、CPUおよびメモリ条件のアラートはトリガーされません。詳細については、監視ポリシー設定を参照してください。
-
スマートポリシーの条件:
- **スコープ:** デリバリーグループ、マルチセッションOSスコープ - **しきい値:** 警告 - 80%、クリティカル - 90% -
メモリ
- メモリ使用率の割合は、プロセスを含むVDA全体のメモリ消費量を示します。個々のプロセスによるメモリ使用率の詳細については、対応するVDAの**[マシン詳細]**ページから確認できます。
- **[マシン詳細] > [履歴使用率の表示] > [上位10プロセス]** に移動し、メモリを消費しているプロセスを特定します。プロセスレベルのリソース使用状況統計の収集を開始するには、プロセス監視ポリシーが有効になっていることを確認してください。
-
必要に応じてプロセスを終了します。
- プロセスを終了すると、保存されていないデータが失われます。
-
すべてが期待どおりに機能している場合は、将来的にメモリを追加します。
注:
ポリシー設定[リソース監視を有効にする]は、VDAを搭載したマシンでのCPUおよびメモリパフォーマンスカウンターの監視に対して、デフォルトで許可されています。このポリシー設定が無効になっている場合、CPUおよびメモリ条件のアラートはトリガーされません。詳細については、監視ポリシー設定を参照してください。
スマートポリシーの条件:
- スコープ: デリバリーグループ、マルチセッションOSスコープ
- しきい値: 警告 - 80%、クリティカル - 90%
接続失敗率
過去1時間における接続失敗の割合。
- 試行された接続の総数に対する総失敗数に基づいて計算されます。
- 構成ログから記録されたイベントについては、[接続失敗トレンドの監視] ビューを確認してください。
- アプリケーションまたはデスクトップに到達可能かどうかを判断します。
接続失敗数
過去1時間における接続失敗の数。
- 構成ログから記録されたイベントについては、[接続失敗トレンドの監視] ビューを確認してください。
- アプリケーションまたはデスクトップに到達可能かどうかを判断します。
ICA® RTT (平均)
ICAラウンドトリップ時間の平均。
- ICA RTTの内訳を確認し、根本原因を特定するには、Citrix ADMを確認してください。詳細については、Citrix ADM ドキュメントを参照してください。
- Citrix ADMが利用できない場合は、[ユーザー詳細の監視] ビューで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マシンの数。失敗は、[監視ダッシュボード] および [フィルター] ビューに示されているように、さまざまな理由で発生する可能性があります。
-
根本原因を特定するには、Citrix Scout診断を実行してください。詳細については、ユーザーの問題のトラブルシューティングを参照してください。
スマートポリシーの条件:
- スコープ: デリバリーグループスコープ
- しきい値: 警告 - 1、重大 - 2
失敗したマシン (マルチセッションOS)
失敗したマルチセッションOSマシンの数。失敗は、[監視ダッシュボード] および [フィルター] ビューに示されているように、さまざまな理由で発生する可能性があります。
-
根本原因を特定するには、Citrix Scout診断を実行してください。
スマートポリシーの条件:
- スコープ: デリバリーグループ、マルチセッションOSスコープ
- しきい値: 警告 - 1、重大 - 2
失敗したマシン (割合)
デリバリーグループ内の失敗したシングルセッションおよびマルチセッションOSマシンの割合で、失敗したマシンの数に基づいて計算されます。このアラート条件を使用すると、デリバリーグループ内の失敗したマシンの割合としてアラートしきい値を構成でき、30秒ごとに計算されます。 失敗は、[監視ダッシュボード] および [フィルター] ビューに示されているように、さまざまな理由で発生する可能性があります。根本原因を特定するには、Citrix Scout診断を実行してください。詳細については、ユーザーの問題のトラブルシューティングを参照してください。
電源オンアクションの失敗と電源オフアクションの失敗
デリバリーグループ内の電源オンアクションの失敗数と電源オフアクションの失敗数で、電源オンまたはオフに失敗した電源管理対象マシンの数に基づいて計算されます。このアラート条件を使用すると、デリバリーグループ内で電源オンまたはオフに失敗した電源管理対象マシンの数としてアラートしきい値を構成でき、30分ごとに計算されます。
管理者は、高度なアラートポリシーでこれらのアラートに対して次のパラメーターを構成できます。
- トリガー元: 電源アクションをトリガーしたもの
- 失敗の理由: アクションが失敗した理由
- しきい値: ポリシーをトリガーするために電源アクションに失敗したマシンのしきい値
- サンプリング間隔: 失敗した電源アクションを確認する間隔
- 再アラート間隔: アラートが再送信されるまでの時間
失敗は、[監視ダッシュボード] および [フィルター] ビューに示されているように、さまざまな理由で発生する可能性があります。根本原因を特定するには、Citrix Scout診断を実行してください。詳細については、ユーザーの問題のトラブルシューティングを参照してください。
未登録マシン (割合)
マシンが再起動によって不安定になった場合、またはデリバリーコントローラー™と仮想マシン間の通信に問題がある場合、マシンは未登録と見なされます。未登録マシン (割合) は、デリバリーグループ内の未登録のシングルセッションおよびマルチセッションOSマシンの割合で、未登録マシンの数に基づいて計算されます。このアラート条件を使用すると、デリバリーグループ内の未登録マシンの割合として警告および重大なしきい値を構成できます。再アラートの間隔を設定できます。また、未登録マシン (割合) の条件が満たされたときに通知を受け取るためにメールを追加することもできます。重大または警告のしきい値を超えると、アラートとメールが生成されます。アラートはCitrix Alertsで確認できます。未登録マシン (割合) カテゴリと、必要な状態および時間でフィルターできます。
注:
重大値は警告値よりも大きくする必要があります。
ポリシーの条件:
- スコープ: シングルセッションOS、およびマルチセッションOSデリバリーグループ
- しきい値: 警告と重大
マシンの稼働時間アラート
デリバリーグループ内のマシンの稼働時間は、デリバリーグループ内で電源がオンになっているマシンの1日あたりの時間、1週間あたりの時間、または1か月あたりの時間に基づいて計算されます。このアラート条件により、デリバリーグループ内でマシンがオンになっている時間をアラートしきい値として構成できます。マシンの稼働時間アラートは、次の場合に機能します。
- 1日あたりの時間 - マシンが1日あたりにオンになる時間を指定でき、30分ごとに計算されます。設定できる1日あたりの最大時間は24時間です
- 1週間あたりの時間 - マシンが1週間あたりにオンになる時間を指定でき、6時間ごとに計算されます。設定できる1週間あたりの最大時間は168時間です
- 1か月あたりの時間 - マシンが1か月あたりにオンになる時間を指定でき、毎日1回計算されます。1か月あたりの最大時間は720時間です 設定できる再アラート間隔の最小値は60分です。警告およびクリティカルアラートセクションで、マシンの稼働時間しきい値を超過するマシンの数を入力できます。任意のマシンに対して例外を追加することもできます。
たとえば、このアラートに5つのデリバリーグループが追加されており、最初のデリバリーグループと4番目のデリバリーグループで、マシンの数が警告またはクリティカルなしきい値を超えた場合、アラートは最初のデリバリーグループと4番目のデリバリーグループに対して個別にトリガーされます。
このアラートは、管理者がマシンの稼働時間を分析するのに役立ち、この分析に基づいて、管理者はコストの最適化に貢献できます。アラートの詳細は、電子メールのCSV添付ファイルとして、またはWebhookの場合にはJSONペイロードを介して受け取ることもできます。
平均ログオン時間
-
過去1時間に発生したログオンの平均ログオン時間。
- ログオン時間に関する最新のメトリックを取得するには、Monitorダッシュボードを確認してください。短期間に多数のユーザーがログオンすると、ログオン時間が増加する可能性があります
-
原因を絞り込むには、ログオンのベースラインと内訳を確認してください。詳細については、「ユーザーログオンの問題の診断」を参照してください。
スマートポリシーの条件:
- スコープ: デリバリーグループ、マルチセッションOSスコープ
- しきい値: 警告 - 45秒、クリティカル - 60秒
ログオン時間 (ユーザー)
過去1時間に発生した、指定されたユーザーのログオンのログオン時間。
負荷評価インデックス
過去5分間の負荷評価インデックスの値。
-
ピーク負荷 (最大負荷) が発生する可能性のあるマルチセッションOSマシンについては、Monitorを確認してください。ダッシュボード (障害) とトレンドの負荷評価インデックスレポートの両方を表示します。
スマートポリシーの条件:
- スコープ: デリバリーグループ、マルチセッション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>
<!--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-->
ServiceNowを使用したアラートポリシーの構成
アラートポリシーを構成して、ServiceNow (SNOW) に直接通知を送信し、ITサービス管理 (ITSM) ワークフローとのシームレスな統合を可能にできます。この統合により、Citrix Monitorで生成されたアラートは、一元的な追跡、エスカレーション、およびインシデント解決のためにServiceNowに自動的に転送されます。
ServiceNow統合の利点
- 統合されたアラート管理: システムを切り替えることなく、Citrix Monitorインターフェイス内でServiceNowインシデントを直接作成、更新、および管理できます
- 自動ITSM構成: Monitorは、Webhook URLなどの必要なServiceNow構成を自動的に取得し、手動セットアップの複雑さを軽減します
- 合理化されたインシデント対応: アラートはServiceNowに転送され、一元的なインシデント追跡と解決が行われ、運用効率が向上します
前提条件
ServiceNow統合を構成する前に、以下を確認してください。
- ITSMアダプターサービスでServiceNowインスタンスが構成されていること
- Monitorでアラートポリシーを管理するために必要な権限があること
ServiceNow統合ステータスの確認
ITSM Adapterサービスとの統合ステータスは、監視 > 統合とデータエクスポートページで確認できます。このページには以下が表示されます。
- 現在の統合ステータス:
- 開始: ITSM Adapter統合が構成されていないことを示します。このオプションを選択して、初期設定プロセスを開始します。
- 管理: ITSM Adapter統合がアクティブで稼働中であることを示します。このオプションを選択して、ServiceNow統合設定を表示または変更します。
- 関連付けられたServiceNowインスタンスURL(ITSM AdapterでServiceNowインスタンスが構成されている場合にのみ表示されます)。

ServiceNow通知によるアラートポリシーの設定
ServiceNowに通知を送信するアラートポリシーを構成するには:
- アラート > Citrixアラートポリシーに移動し、ポリシーカテゴリ(例: マルチセッションOSポリシー)を選択します。
- 作成をクリックして新しいポリシーを作成するか、既存のポリシーを選択して編集をクリックします。
- 必要に応じてポリシー条件を構成します。
-
通知設定セクションで、ServiceNow統合オプションを探します。
-
ITSM Adapterが利用可能な場合:
- このポリシーのServiceNow経由でのアラート通知を有効にするには、チェックボックスをオンにします。
- 関連付けられたServiceNowインスタンスURLが参照用に表示されます。
- ポリシーにすでにWebhookが構成されている場合、ServiceNow統合を有効にすると既存のWebhook構成が上書きされることを警告メッセージが通知します。

-
ITSM Adapterが利用できない場合:
- ITSM統合が現在構成されていないことを示すメッセージが表示されます。
- 開始をクリックして統合設定にアクセスします。詳細については、ドキュメントを参照してください。

-
ITSM Adapterが利用可能な場合:
- 保存をクリックしてポリシーを保存します。
構成されると、ポリシー条件を満たすアラートは自動的にServiceNowに転送され、ITSM構成に基づいてインシデントまたはイベントとして管理できます。
アラートの一括解除
この機能は、管理者のアラート管理プロセスを最適化し、柔軟性を提供し、アラート疲労を軽減します。管理者は、時間、種類、またはカテゴリに基づいてアラートを一括で解除でき、メンテナンス中やハイパーバイザーなどの環境を扱う際のアラート管理を簡素化します。
アラートの一括解除は、管理者がワークロードを効率的に管理し、大量のアラートに圧倒されるのを防ぐのに役立ちます。
アラートを一括解除する手順
-
アラート > Citrixアラートタブに移動します。アラートが表示されます。

- ソース、カテゴリ、状態、または期間からオプションを選択して、解除したいアラートをフィルタリングします。特定のアラートが表示されます。
- 特定のアラートの横にあるチェックボックスをオンにするか、上部にあるチェックボックスをオンにしてすべてのアラートを選択します。
- 解除をクリックします。アラートの解除を確認する通知が表示されます。
- はいをクリックします。選択したアラートは解除済みとしてマークされ、アラートのステータスがそれに応じて更新されます。
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プロファイルを作成できます。
認証ヘッダーなしで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 "webhookprofile1" -Description "Description" -Url $url -Headers $headers -PayloadFormat $payloads -Platform Slack -Type Webhook -MethodType POST
<!--NeedCopy-->
認証ヘッダー付きで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 "webhookprofile1" -Description "Description" -Url $url -Headers $headers -PayloadFormat $payloads -Platform Slack -Type Webhook -MethodType POST
<!--NeedCopy-->
例:

プロファイルが作成されたら、データベースで確認できます。また、新しく作成されたWebhookプロファイルはCitrixアラートページで見つけることができます。

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 -Platform Slack -Type Webhook -MethodType POST
<!--NeedCopy-->
例:

すべてのWebhookプロファイルの一覧取得
利用可能なすべてのWebhookプロファイルの一覧を取得するには、以下のPowerShellサンプルコマンドを使用します。
Get-MonitorWebhookProfile
Get-MonitorWebhookProfile -Name 'profile_msteams'
Get-MonitorWebhookProfile -Uid 1
<!--NeedCopy-->
Webhookプロファイルの削除
Webhookプロファイルを削除するには、以下のPowerShellサンプルコマンドを使用します。
Remove-MonitorWebhookProfile -Uid 1
<!--NeedCopy-->
注:
Webhookプロファイルがいずれかのポリシーにマッピングされている場合、削除できません。回避策として、まずポリシーからWebhookマッピングを削除する必要があります。
Webhookプロファイルを使用したポリシーの作成
Webhookプロファイルを使用したポリシーを作成するには、以下のPowerShellサンプルコマンドを使用します。
New-MonitorNotificationPolicy -Name "Policy1" -Description "Policy Description" -Enabled $true -WebhookProfileId 1
<!--NeedCopy-->
Webhookプロファイルを使用したポリシーの更新
Webhookプロファイルを使用したポリシーを更新するには、以下のPowerShellサンプルコマンドを使用します。
$Policy = Set-MonitorNotificationPolicy -Uid 1 -WebhookProfileId 1
<!--NeedCopy-->
ポリシーからのWebhookマッピングの削除
ポリシーからWebhookプロファイルを削除するには、以下のPowerShellサンプルコマンドを使用します。
$Policy = Set-MonitorNotificationPolicy -Uid 1 -WebhookProfileId 0
<!--NeedCopy-->
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
<!--NeedCopy-->
ローカルホストキャッシュの構成同期失敗アラート監視
ローカルホストキャッシュを使用すると、Cloud ConnectorがCitrix Cloudとの接続を失った場合でも、ユーザーセッションを継続できます。ローカルホストキャッシュで使用されるキャッシュは、ローカルホストキャッシュモードがアクティブ化されたときに最新の構成を保証するために、プライマリデータベースと定期的に同期されます。ローカルホストキャッシュと構成同期プロセスに関する詳細については、ローカルホストキャッシュを参照してください。構成同期が3回以上連続して失敗した場合、Citrix Monitorは管理者に警告アラートを送信します。
Citrix Monitorには、構成同期の失敗について管理者に通知するための「ローカルホストキャッシュ - 構成同期の失敗」という事前定義されたアラートポリシーが導入されています。新しく導入されたポリシーは、Monitor > Citrix Alertsで確認できます。事前定義されたポリシーを変更して、メール受信者やWebhookを追加または編集し、アラート管理ツールやITSMツールでプロアクティブな通知を受け取ることができます。
「ローカルホストキャッシュ - 構成同期の失敗」アラートポリシーのスコープは、サイトのみに限定されます。
ハイパーバイザーアラートの監視
Monitorは、ハイパーバイザーの健全性を監視するためのアラートを表示します。Citrix Hypervisor™およびVMware vSphereからのアラートは、ハイパーバイザーのパラメーターと状態の監視に役立ちます。ハイパーバイザーへの接続状態も監視され、ホストのクラスターまたはプールが再起動されたり、利用できなくなった場合にアラートが提供されます。
ハイパーバイザーアラートを受信するには、管理タブでホスティング接続が作成されていることを確認してください。詳細については、接続とリソースを参照してください。これらの接続のみがハイパーバイザーアラートの監視対象となります。次の表に、ハイパーバイザーアラートのさまざまなパラメーターと状態を示します。
| アラート | サポートされるハイパーバイザー | トリガー元 | 条件 | 構成 |
|---|---|---|---|---|
| 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 Alertsを参照するか、VMware vCenter Alertsのドキュメントを確認してください。
メール通知の設定は、Citrix Alerts Policy > Site Policy > Hypervisor Healthで構成できます。ハイパーバイザーアラートポリシーのしきい値条件は、Monitorからではなく、ハイパーバイザーからのみ構成、編集、無効化、または削除できます。ただし、メール設定の変更やアラートの解除はMonitorで行うことができます。
重要:
- 1日以上経過したすべてのハイパーバイザーアラートは自動的に解除されます。
- ハイパーバイザーによってトリガーされたアラートはMonitorで取得および表示されます。ただし、ハイパーバイザーアラートのライフサイクル/状態の変更はMonitorには反映されません。
- ハイパーバイザーコンソールで正常または解除済み、あるいは無効になっているアラートはMonitorに表示され続け、明示的に解除する必要があります。
- Monitorで解除されたアラートは、ハイパーバイザーコンソールでは自動的に解除されません。

ハイパーバイザーアラートのみをフィルタリングできるように、「Hypervisor Health」という新しいアラートカテゴリが追加されました。これらのアラートは、しきい値に達するか超過すると表示されます。ハイパーバイザーアラートには次の種類があります。
- 重大 — ハイパーバイザーアラームポリシーの重大なしきい値に達したか、超過した
- 警告 — ハイパーバイザーアラームポリシーの警告しきい値に達したか、超過した
- 解除済み — アクティブなアラートとして表示されなくなったアラート
