アラートと通知

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

ディレクターのアラート(/ja-jp/citrix-virtual-apps-desktops/2507-ltsr/media/dir-alerts.png)

警告アラート（琥珀色の三角形）は、条件の警告しきい値に達したか、それを超えたことを示します。

重大なアラート（赤い円）は、条件の重大なしきい値に達したか、それを超えたことを示します。

アラートの詳細情報は、サイドバーからアラートを選択するか、サイドバーの下部にあるGo to Alertsリンクをクリックするか、Directorページの上部にあるAlertsを選択することで表示できます。

アラートビューでは、アラートをフィルター処理してエクスポートできます。たとえば、過去1か月間の特定のデリバリーグループの失敗したマルチセッションOSマシン、または特定のユーザーのすべてのアラートなどです。詳しくは、「レポートのエクスポート」を参照してください。

アラートのフィルター(/ja-jp/citrix-virtual-apps-desktops/2507-ltsr/media/director_filteralerts.png)

シトリックス®アラート

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データベースに対応するアラートルールが存在しない場合にのみ作成されます。

組み込みのアラートポリシーのしきい値については、(#alerts-policies-conditions)セクションを参照してください。

高度なアラートポリシー

Directorのプロアクティブな通知およびアラート機能は、「高度なアラートポリシー」という新しいアラートフレームワークを含むように強化されています。この機能を使用すると、各要素または条件に詳細な情報を含めることでアラートを作成でき、それによりアラートの範囲に対する制御が強化されます。現在、これらのポリシーには、コスト削減とインフラストラクチャに関するアラートが含まれています。

データソース駆動型のアラートである高度なアラートポリシーの導入により、複数条件のスコープフィルタリングを使用できます。

この機能は、過剰なアラートを減らすのに役立ちます。これは、重要な問題への対応の迅速性や有効性の低下につながる可能性があります。このポリシーは、アラートポリシーの有効性と管理者からのエンゲージメントを測定するのに役立ちます。

高度なアラートポリシーは、「アラート」>「高度なアラートポリシー」>「ポリシーの作成」セクションから作成できます。

次のデータソースのいずれかを選択できます。

• マシン
• プロビジョニングサービス
• ストアフロント™
• デリバリーコントローラー™

コスト削減に関するアラート

コストを最適化するのに役立つコスト削減に関するアラートを作成できます。現在、マシンに関するアラートを作成できます。

マシンに関するアラートを作成するには、次の手順を実行します。

1. 「アラート」タブ > 「高度なアラートポリシー」をクリックします。「高度なアラートポリシー」ページが表示されます。
2. 「ポリシーの作成」をクリックします。「高度なアラートポリシーの作成」セクションが表示されます。

3. データソースドロップダウンリストから「マシン」を選択します。コスト削減条件とそれに対応する条件タイプが表示されます。

   Directorの高度なアラートポリシー(/ja-jp/citrix-virtual-apps-desktops/2507-ltsr/media/advanced-alert.png)

4. 必要に応じて、次の条件タイプを選択します。

   • 電源管理対象マシンが起動に失敗しました
   • 電源管理対象マシンがシャットダウンに失敗しました
   • 稼働時間の長い電源管理対象マシン
5. 選択した各条件について、特定のパラメーターと対応するオプションを選択します。

6. 選択した条件タイプの警告および重大なメトリックを設定します。

   • 稼働時間の長い電源管理対象マシンについて：

     • 稼働時間しきい値を超過したマシンの数
     • 再アラート間隔（分）。間隔は最低60分です。

   • 電源管理対象マシンが起動に失敗した場合、および電源管理対象マシンがシャットダウンに失敗した場合：

     • 稼働時間しきい値を超過したマシンの数
     • サンプリング間隔（分）間隔は30分の倍数にできます
     • 再アラート間隔（分）再アラートは60分の倍数にできます
7. 必要に応じて、選択したアラートの再アラート間隔をスケジュールします。
8. アラートの範囲を定義します。

9. 通知チャネルを設定します。これはメールまたはWebhookにできます。

   1. 次のチェックボックスを選択できます。

      • WebhookにJSONペイロードを添付ファイルとして含めます
      • メールにCSVファイルを添付ファイルとして含めます

   詳細については、アラートコンテンツの機能強化を参照してください。

10. アラート名や説明（オプション）などのアラートの詳細を入力します。
11. 保存をクリックします。アラートが作成されます。

インフラストラクチャ監視用アラート

次のサポートされているCitrix Virtual Apps and Desktops™コンポーネントの健全性を監視するために、アラートを作成できます。

• プロビジョニングサービス

  

• ストアフロント

  SF高度なアラートポリシー(/ja-jp/citrix-virtual-apps-desktops/2507-ltsr/media/advanced-alerts-storefront.png)

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

  DDC高度なアラートポリシー(/ja-jp/citrix-virtual-apps-desktops/2507-ltsr/media/advanced-alerts-ddc.png)

インフラストラクチャ監視のセットアップが完了すると、Directorで利用可能なヘルスデータを使用して、必要なコンポーネントのアラートを設定できます。管理者は、電子メールまたはWebhookを介したJSONペイロードで重要なアラートを受信するための条件、スコープ、および通知媒体を設定できます。Provisioning ServiceおよびDelivery Controllerの場合、アラートのスコープをサイトレベルまたは個々のサーバーレベルのいずれかとして選択できます。たとえば、Provisioning Serviceの場合、「すべてのProvisioning Service」を選択すると、サイトに2つのサーバーがある場合でも、サイト全体に対して1つのアラートのみを受信します。これはサイトレベルのアラートと見なされます。発生したアラートは、分析と管理のためにCitrix Alertsセクションでも利用できます。

新しく導入されたインフラストラクチャポリシーの一部として、アラート条件は次の4つのセクションに分類されます。

• 到達可能性
• 依存サービス
• 影響
• リソース使用率

各カテゴリ内の条件は、組織の優先順位に基づいて、重大および警告の重大度で設定できます。これらのアラートの再アラート間隔をスケジュールすることもできます。

アラート > Citrixアラートポリシーセクションからインフラストラクチャポリシーを作成できます。必要なカテゴリを選択し、ポリシーに必要な条件を選択できます。ポリシーの作成方法の詳細については、「アラートポリシーの作成」を参照してください。ポリシーが作成された後、Citrix Alertsページでポリシーを編集、削除、または無効にすることができます。

各カテゴリおよびコンポーネントでサポートされている条件の詳細については、以下を参照してください。

• プロビジョニングサービス ヘルス指標
• ストアフロント ヘルス指標
• デリバリーコントローラーの健全性メトリック

以下のデータは、電子メールまたはCitrixアラートページでアラートとして受信されます。

ポリシーのスコープを定義する

アラートのスコープを定義し、例外を追加できます。アラートは選択されたスコープに対してのみ生成され、例外の追加を使用して除外されたサブスコープはアラート生成に含まれません。この機能は、詳細なレベルでアラートを作成するのに役立ちます。

メールまたはWebhook URLを介して通知を作成できます。アラートを受信する希望の言語を選択することもできます。また、メールの場合は.CSVファイル添付で、Webhook URLを介してはJSONペイロードでアラートパラメーターを受信するオプションを選択することもできます。添付ファイルには、必要なパラメーターの詳細が含まれています。詳細については、「アラートコンテンツの機能強化」(/ja-jp/citrix-virtual-apps-desktops/2507-ltsr/director/site-analytics/alerts-notifications#enhancements-on-alert-content)を参照してください。

次のデータは、メールまたはCitrix Alertsページでアラートとして受信されます。

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-->

障害が発生したマシンの割合(/ja-jp/citrix-virtual-apps-desktops/2507-ltsr/media/powershell-failedmachine.png)

上の画像から、ポリシーが作成され、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の追加(/ja-jp/citrix-virtual-apps-desktops/2507-ltsr/media/powershell-add-wehook.png)

Webhook URLを追加するスクリプトの例:

Set-MonitorNotificationPolicy –Uid 10  –Webhook  'https://hooks.slack.com/triggers/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'
<!--NeedCopy-->

作成されたポリシーの詳細を取得

Get-MonitorNotificationPolicy -Uid 10
<!--NeedCopy-->

アラートポリシーを作成する

アラートポリシーを作成するには、たとえば、特定のセッション数条件が満たされたときにアラートを生成するには、次の手順を実行します。

1. アラート > Citrixアラートポリシー に移動し、たとえば、マルチセッションOSポリシーを選択します。
2. 作成 をクリックします。
3. ポリシーに名前を付けて説明し、アラートがトリガーされるために満たす必要がある条件を設定します。たとえば、ピーク接続セッション、ピーク切断セッション、およびピーク同時合計セッションの警告数と重大数を指定します。警告値は重大値より大きくしてはいけません。詳細については、アラートポリシーの条件を参照してください。
4. 再アラート間隔を設定します。アラートの条件が引き続き満たされている場合、この時間間隔でアラートが再度トリガーされ、アラートポリシーで設定されている場合はメール通知が生成されます。却下されたアラートは、再アラート間隔でメール通知を生成しません。
5. スコープを設定します。たとえば、特定のデリバリーグループに設定します。

6. 通知設定で、アラートがトリガーされたときに誰にメールで通知する必要があるかを指定します。アラートポリシーでメール通知設定を行うには、メールサーバー構成タブでメールサーバーを指定する必要があります。

   1. アラートコンテンツを.CSV添付ファイルまたはJSONペイロードを介して受信することもできます。そのためには、次のチェックボックスを選択します。

      • JSONペイロードをWebhookの添付ファイルとして含める
      • CSVファイルをメールの添付ファイルとして含める

   注：

   .CSV添付ファイルおよびJSONペイロードオプションを介してアラートコンテンツを受信する機能は、現在、一部のアラートでのみ利用可能です。詳細については、「アラートコンテンツの機能強化」を参照してください。

7. 保存をクリックします。

スコープに20以上のデリバリーグループが定義されたポリシーを作成すると、設定の完了に約30秒かかる場合があります。この間、スピナーが表示されます。

最大20のユニークなデリバリーグループ（合計1000のデリバリーグループターゲット）に対して50を超えるポリシーを作成すると、応答時間が増加する可能性があります（5秒以上）。

アクティブなセッションを含むマシンをあるデリバリーグループから別のデリバリーグループに移動すると、マシンパラメータを使用して定義されている誤ったデリバリーグループアラートがトリガーされる可能性があります。

注：

アラートポリシーを削除した後、そのポリシーによって生成されたアラート通知が停止するまでに最大30分かかる場合があります。

アラートコンテンツの機能強化

Director のアラート機能が強化され、CSV 添付ファイルと JSON ペイロードが含まれるようになりました。この機能強化により、電子メールで CSV 添付ファイルとして、または Webhook がある場合は JSON ペイロードとしてアラートの詳細を取得できます。この CSV 添付ファイルまたは JSON ペイロードを使用すると、詳細レベルで豊富なコンテンツを受信でき、問題の迅速な特定と解決に役立ちます。

現在、この機能強化は次のアラートでのみ利用可能です。

• マシンの稼働時間
• 電源オン失敗アクション
• 電源オフ失敗アクション
• 未登録マシン (%)

この機能を使用するには、アラートに移動して、次のチェックボックスを選択します。

• Webhook に JSON ペイロードを添付ファイルとして含める
• 電子メールに CSV ファイルを添付ファイルとして含める

以下は、Citrix Alert Policies セクションのスクリーンショットです。

以下は、Advanced Alert Policies セクションのスクリーンショットです。

CSV 添付ファイル

次の表は、サポートされているすべてのアラートの .CSV 添付ファイルの列を示しています。

ウェブフックペイロード

未登録マシン割合アラート

{
  "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分に設定されています。

接続セッションのピーク

• Directorのセッション傾向ビューで、接続セッションのピークを確認します。
• セッション負荷に対応するのに十分な容量があることを確認します。
• 必要に応じて新しいマシンを追加します

切断セッションのピーク

• Directorのセッション傾向ビューで、切断セッションのピークを確認します。
• セッション負荷に対応するのに十分な容量があることを確認します。
• 必要に応じて新しいマシンを追加します。
• 必要に応じて切断されたセッションをログオフします

同時実行セッションの合計ピーク

• Directorのセッション傾向ビューで、同時実行セッションのピークを確認します。
• セッション負荷に対応するのに十分な容量があることを確認します。
• 必要に応じて新しいマシンを追加します。
• 必要に応じて、切断されたセッションをログオフします。

CPU

CPU使用率のパーセンテージは、プロセスを含むVDA全体のCPU消費量を示します。個々のプロセスによるCPU使用率の詳細については、対応するVDAのマシン詳細ページで確認できます。

• マシン詳細 > 履歴使用率の表示 > 上位10プロセスに移動し、CPUを消費しているプロセスを特定します。プロセスレベルのリソース使用状況統計の収集を開始するには、プロセス監視ポリシーが有効になっていることを確認してください。
• 必要に応じてプロセスを終了します。
• プロセスを終了すると、保存されていないデータが失われます。

• すべてが期待どおりに機能している場合は、将来的に追加のCPUリソースを追加します。

  注：

  リソース監視を有効にするポリシー設定は、VDAが搭載されたマシンでのCPUおよびメモリのパフォーマンスカウンターの監視に対して、デフォルトで許可されています。このポリシー設定が無効になっている場合、CPUおよびメモリの状態に関するアラートはトリガーされません。詳しくは、「監視ポリシー設定」を参照してください。

  スマートポリシー条件：

  • スコープ：デリバリーグループ、マルチセッションOSスコープ
  • しきい値：警告 - 80%、重大 - 90%

メモリ

メモリ使用率のパーセンテージは、プロセスを含むVDA全体のメモリ消費量を示します。個々のプロセスによるメモリ使用量の詳細については、対応するVDAのマシン詳細ページで確認できます。

• マシン詳細 > 履歴使用率の表示 > 上位10プロセスに移動し、メモリを消費しているプロセスを特定します。プロセスレベルのリソース使用状況統計の収集を開始するには、プロセス監視ポリシーが有効になっていることを確認してください。
• 必要に応じてプロセスを終了します。
• プロセスを終了すると、保存されていないデータが失われます。

• すべてが期待どおりに機能している場合は、今後、追加のメモリを増設してください。

  注:

  リソース監視を有効にするポリシー設定は、VDAがインストールされているマシンでのCPUおよびメモリのパフォーマンスカウンターの監視に対して、デフォルトで許可されています。このポリシー設定が無効になっている場合、CPUおよびメモリの状態に関するアラートはトリガーされません。詳細については、「監視ポリシー設定」を参照してください。

  スマートポリシー条件:

  • スコープ: Delivery Group、マルチセッションOSスコープ
  • しきい値: 警告 - 80%、重大 - 90%

接続失敗発生率

過去1時間における接続失敗の割合。

• 試行された総接続数に対する総失敗数に基づいて計算されます。
• Directorの接続失敗傾向ビューで、構成ログから記録されたイベントを確認します。
• アプリケーションまたはデスクトップに到達可能かどうかを判断します。

接続失敗件数

過去1時間における接続失敗の数。

• 設定ログから記録されたイベントについて、Director Connection Failures Trendsビューを確認します。
• アプリケーションまたはデスクトップに到達可能かどうかを判断します。

アイシーエー® アールティーティー (平均)

平均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ラウンドトリップ時間。少なくとも1つのセッションでICA RTTがしきい値を超えると、アラートがトリガーされます。

失敗したマシン (シングルセッション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週間あたりの時間数 - マシンが1週間あたりにオンになっている時間数を指定でき、6時間ごとに計算されます。設定できる1週間あたりの最大時間数は168時間です。
• 1か月あたりの時間数 - マシンが1か月あたりにオンになっている時間数を指定でき、毎日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>
<!--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-->

アラートの一括解除

この機能は、管理者のアラート管理プロセスを最適化し、柔軟性を提供し、アラート疲労を軽減します。管理者は、時間、種類、またはカテゴリに基づいてアラートを一括で解除でき、メンテナンス中やハイパーバイザーなどの環境を扱う際のアラート管理を簡素化します。

アラートの一括解除は、管理者がワークロードを効率的に管理し、大量のアラートに圧倒されるのを防ぐのに役立ちます。

アラートを一括解除する手順

1. アラート > Citrixアラートタブに移動します。アラートが表示されます。

   

2. 解除したいアラートをフィルタリングするには、ソース、カテゴリ、状態、または期間からオプションを選択します。特定のアラートが表示されます。
3. 特定のアラートの横にあるチェックボックスを選択するか、上部にあるチェックボックスを選択してすべてのアラートを選択します。
4. 「却下」をクリックします。アラートの却下を確認する通知が表示されます。
5. 「はい」をクリックします。選択したアラートは却下済みとしてマークされ、アラートのステータスがそれに応じて更新されます。

PowerShell SDK を使用したウェブフックの構成

PowerShell SDK を使用した Webhook 構成機能により、管理者は Webhook プロファイルの作成、変更、削除、および一覧表示を行うことができます。この機能は、ヘッダー、認証タイプ、コンテンツタイプ、ペイロード、および Webhook URL の指定を可能にすることで、Webhook 構成の柔軟性を提供します。

注：

サポートされているペイロード形式はテキストであり、エンドユーザーは Webhook でテキストを有効にする必要があります。

最新のペイロード形式は次のとおりです。

{"text": "This is a message from a Webex incoming webhook."}
<!--NeedCopy-->

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>"

Add-MonitorWebhookProfile -Name "profile_slack" -Description "webhook profile for slack" -Url $url -Headers $headers -PayloadFormat $payloads
<!--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 "profile_azure" -Description "webhook profile for azure function with Authentication" -Url $url -Headers $headers -PayloadFormat $payloads
<!--NeedCopy-->

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

Webhook プロファイルを更新する

Webhook プロファイルを更新するには、次の PowerShell サンプルコマンドを使用できます。

$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プロファイルの一覧を取得する

利用可能なすべての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-->

ハイパーバイザーアラートの監視

Director はハイパーバイザーの健全性を監視するためのアラートを表示します。XenServer® および VMware vSphere からのアラートは、ハイパーバイザーのパラメーターと状態の監視に役立ちます。ホストのクラスターまたはプールが再起動されたり利用できなくなったりした場合にアラートを出すため、ハイパーバイザーへの接続ステータスも監視されます。

ハイパーバイザーアラートを受信するには、Web Studio でホスティング接続が作成されていることを確認してください。詳細については、「接続とリソース」を参照してください。ハイパーバイザーアラートは、これらの接続のみが監視されます。

これらのアラートは、しきい値に達するか、しきい値を超えると表示されます。ハイパーバイザーアラートには、次の種類があります。

• 致命的 — ハイパーバイザーアラームポリシーの致命的なしきい値に達したか、しきい値を超過した
• 警告 — ハイパーバイザーアラームポリシーの警告しきい値に達したか、しきい値を超過した
• 却下済み — アクティブなアラートとして表示されなくなったアラート

この機能には、Delivery Controller バージョン 7 1811 以降が必要です。Director の古いバージョンをサイト 7 1811 以降で使用している場合、ハイパーバイザーアラートの数のみが表示されます。アラートを表示するには、Director をアップグレードする必要があります。

次の表は、ハイパーバイザーアラートのさまざまなパラメーターと状態について説明しています。

注記:

アラートの設定に関する詳細については、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で「最大セッション数」ポリシーを設定した場合に適用されます。