アラートと通知
アラートは、Monitorのダッシュボードやその他の上位レベルのビューに、警告および重大なアラートシンボルとともに表示されます。アラートは1分ごとに自動的に更新されます。また、オンデマンドでアラートを更新することもできます。
警告アラート(琥珀色の三角形)は、条件の警告しきい値に達したか、それを超えたことを示します。
重大なアラート(赤い円)は、条件の重大なしきい値に達したか、それを超えたことを示します。
アラートに関する詳細情報は、サイドバーからアラートを選択するか、サイドバーの下部にあるGo to Alertsリンクをクリックするか、Monitorページの上部からAlertsを選択することで表示できます。
アラートビューでは、アラートをフィルタリングおよびエクスポートできます。たとえば、過去1か月間の特定のデリバリーグループの失敗したマルチセッションOSマシン、または特定のユーザーのすべてのアラートなどです。詳細については、「レポートのエクスポート」を参照してください。
Citrix®アラート
Citrixアラートは、Citrixコンポーネントから発生するアラートです。Citrixアラートは、MonitorのAlerts \> Citrix Alerts Policyで構成できます。構成の一部として、設定したしきい値を超えた場合に、個人やグループに電子メールで通知を送信するように設定できます。Citrixアラートの設定の詳細については、「アラートポリシーの作成」を参照してください。
スマートアラートポリシー
事前定義されたしきい値を持つ一連の組み込みアラートポリシーは、デリバリーグループおよびマルチセッションOS VDAのスコープで利用できます。組み込みアラートポリシーのしきい値パラメーターは、Alerts \> Citrix Alerts Policyで変更できます。 これらのポリシーは、サイトに少なくとも1つのアラートターゲット(デリバリーグループまたはマルチセッションOS VDA)が定義されている場合に作成されます。また、これらの組み込みアラートは、新しいデリバリーグループまたはマルチセッションOS VDAに自動的に追加されます。
組み込みアラートポリシーは、Monitorデータベースに対応するアラートルールが存在しない場合にのみ作成されます。
組み込みアラートポリシーのしきい値については、「アラートポリシーの条件」セクションを参照してください。
高度なアラートポリシー
Monitorのプロアクティブ通知およびアラート機能は、高度なアラートポリシーという新しいアラートフレームワークを含むように強化されました。この機能を使用すると、各要素または条件に詳細な情報を含めてアラートを作成できるため、アラートの範囲に対する制御が強化されます。現在、これらのポリシーには、コスト削減とインフラストラクチャに関するアラートが含まれています。
データソース駆動型アラートである高度なアラートポリシーの導入により、複数条件のスコープフィルタリングを使用できます。
この機能は、重要な問題への対応の迅速性や有効性の低下につながる可能性のある過剰なアラートを減らすのに役立ちます。このポリシーは、アラートポリシーの有効性と管理者からのエンゲージメントを測定するのに役立ちます。
アラート > 高度なアラートポリシー > ポリシーの作成セクションから、高度なアラートポリシーを作成できます。 次のデータソースのいずれかを選択できます。
-
マシン
-
プロビジョニングサービス
-
StoreFront™
コスト削減に関するアラート
コストを最適化するのに役立つコスト削減に関するアラートを作成できます。現在、マシンに関するアラートを作成できます。
マシンに関するアラートを作成するには、次の手順を実行します。
-
アラートタブ > 高度なアラートポリシーをクリックします。高度なアラートポリシーページが表示されます。
-
ポリシーの作成をクリックします。高度なアラートポリシーの作成セクションが表示されます。
-
データソースドロップダウンリストからマシンを選択します。コスト削減条件と対応する条件タイプが表示されます。
-
必要な条件タイプを以下から選択します。
-
電源管理対象マシンが起動に失敗しました
-
電源管理対象マシンがシャットダウンに失敗しました
-
稼働時間が長い電源管理対象マシン
-
-
選択した各条件について、特定のパラメーターと対応するオプションを選択します。
-
選択した条件タイプに対して、警告およびクリティカルのメトリックを設定します。
-
稼働時間が長い電源管理対象マシンの場合:
-
稼働時間しきい値を超過したマシンの数
-
再アラート間隔(分):間隔は最低60分です
-
-
電源管理対象マシンが起動に失敗しましたおよび電源管理対象マシンがシャットダウンに失敗しましたの場合:
-
稼働時間しきい値を超過したマシンの数
-
サンプリング間隔(分):間隔は30分の倍数にできます
-
再アラート間隔(分):再アラートは60分の倍数にできます
-
-
-
必要に応じて、選択したアラートの再アラート間隔をスケジュールします。
-
アラートのスコープを定義します。
-
通知チャネルを設定します。これはメールまたはWebhookにすることができます。
-
次のチェックボックスを選択できます。
-
JSONペイロードをWebhookに添付ファイルとして含める
-
CSVファイルをメールに添付ファイルとして含める
-
-
-
アラート名や説明(オプション)などのアラートの詳細を入力します。
-
保存をクリックします。アラートが作成されます。
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™コンポーネントの健全性を監視するアラートを作成できます。
-
プロビジョニングサービス
-
StoreFront
-
クラウドコネクタ
-
コネクタアプライアンス
インフラストラクチャ監視 のセットアップが完了すると、Monitor で利用可能なヘルスデータを使用して、必要なコンポーネントのアラートを設定できます。管理者は、電子メールまたは Webhook を介した JSON ペイロードで重要なアラートを受信するための条件、スコープ、および通知媒体を設定できます。発生したアラートは、分析と管理のために 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/<TeamId>/<WorkflowId>/<Token>'
作成されたポリシーの詳細を取得
Get-MonitorNotificationPolicy -Uid 10
アラートポリシーを作成する
アラートポリシーを作成するには、たとえば、特定のセッション数基準が満たされたときにアラートを生成する場合:
-
アラート \> 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 Alert Policiesセクションのスクリーンショットです。
強化されたアラート(/en-us/citrix-daas/media/csv-and-webhook.png)
以下は、Advanced Alert Policiesセクションのスクリーンショットです。
強化されたアラート(詳細)(/en-us/citrix-daas/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分に設定されています。
ピーク接続セッション
-
ピーク接続セッションについては、モニターセッショントレンドビューを確認してください。
-
セッション負荷に対応する十分な容量があることを確認してください。
-
必要に応じて新しいマシンを追加する
ピーク切断セッション
-
「Monitor Session Trends」ビューで、ピーク時の切断されたセッションを確認します。
-
セッション負荷に対応できる十分な容量があることを確認します。
-
必要に応じて、新しいマシンを追加します。
-
必要に応じて、切断されたセッションをログオフします。
ピーク時の同時合計セッション数
-
Monitor の「Monitor Session Trends」ビューで、ピーク時の同時セッションを確認します。
-
セッション負荷に対応できる十分な容量があることを確認します。
-
必要に応じて、新しいマシンを追加します。
-
必要に応じて、切断されたセッションをログオフします。
CPU
-
必要に応じてプロセスを終了します。
-
プロセスを終了すると、保存されていないデータが失われます。
-
すべてが期待どおりに機能している場合は、今後さらに CPU リソースを追加します。注記:ポリシー設定「リソース監視を有効にする」は、VDAがインストールされたマシンでのCPUおよびメモリのパフォーマンスカウンターの監視のために、デフォルトで許可されています。このポリシー設定が無効になっている場合、CPUおよびメモリの状態に関するアラートはトリガーされません。詳細については、「監視ポリシー設定」(/ja-jp/citrix-virtual-apps-desktops/policies/reference/virtual-delivery-agent-policy-settings/monitoring-policy-settings.html)を参照してください。スマートポリシー条件:
-
範囲: デリバリーグループ、マルチセッションOSの範囲
-
しきい値: 警告 - 80%、危険 - 90%
-
メモリ
メモリ使用率は、VDA上の全体的なメモリ消費量(プロセスによるものを含む)を示します。個々のプロセスによるメモリ使用量に関する詳細な情報は、対応するVDAのマシン詳細ページから取得できます。
-
マシン詳細 > 履歴使用率の表示 > 上位10プロセスに移動し、メモリを消費しているプロセスを特定します。プロセスレベルのリソース使用状況統計の収集を開始するには、プロセス監視ポリシーが有効になっていることを確認してください。
-
必要に応じてプロセスを終了します。
-
プロセスを終了すると、保存されていないデータが失われます。
-
すべてが期待どおりに機能している場合は、将来的にメモリを追加してください。注記:ポリシー設定「リソース監視を有効にする」は、VDAがインストールされたマシンでのCPUおよびメモリのパフォーマンスカウンターの監視のために、デフォルトで許可されています。このポリシー設定が無効になっている場合、CPUおよびメモリの状態に関するアラートはトリガーされません。詳細については、「監視ポリシー設定」(/ja-jp/citrix-virtual-apps-desktops/policies/reference/virtual-delivery-agent-policy-settings/monitoring-policy-settings.html)を参照してください。スマートポリシー条件:
-
範囲: デリバリーグループ、マルチセッションOSの範囲
-
閾値: 警告 - 80%、危機的 - 90%
-
接続失敗率
過去1時間の接続失敗の割合。
-
試行された総接続数に対する総失敗数に基づいて計算されます。
-
構成ログから記録されたイベントについては、接続失敗トレンドの監視ビューを確認してください。
-
アプリケーションまたはデスクトップが到達可能であるかどうかを判断します。
接続失敗数
過去1時間の接続失敗数。
-
構成ログから記録されたイベントについては、接続失敗トレンドの監視ビューを確認してください。
-
アプリケーションまたはデスクトップが到達可能であるかどうかを判断します。
ICA® RTT (平均)
平均ICAラウンドトリップ時間。
-
根本原因を特定するために、Citrix ADMでICA RTTの内訳を確認してください。詳細については、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週間に稼働する時間を指定でき、6時間ごとに計算されます。設定できる週あたりの最大時間は168時間です。
-
月あたりの時間 - マシンが1ヶ月に稼働する時間を指定でき、毎日1回計算されます。月あたりの最大時間は720時間です。 設定できる再アラート間隔の最小値は60分です。警告および重大アラートセクションで、マシンの稼働時間しきい値を超過するマシンの数を入力できます。また、任意のマシンに対して例外を追加することもできます。
たとえば、このアラートに5つのデリバリーグループが追加されており、最初のデリバリーグループと4番目のデリバリーグループでマシンの数が警告または重大なしきい値を超えた場合、アラートは最初のデリバリーグループと4番目のデリバリーグループに対して個別にトリガーされます。
このアラートは、管理者がマシンの稼働時間を分析するのに役立ち、この分析に基づいて管理者はコストの最適化を支援できます。また、電子メールでCSV添付ファイルとして、またはWebhookの場合にはJSONペイロードを介してアラートの詳細を受け取ることもできます。
平均ログオン時間
過去1時間に発生したログオンの平均ログオン時間。
-
ログオン時間に関する最新のメトリックを取得するには、監視ダッシュボードを確認してください。短期間に多数のユーザーがログオンすると、ログオン時間が増加する可能性があります。
-
原因を絞り込むために、ログオンのベースラインと内訳を確認してください。詳細については、「ユーザーログオンの問題の診断」を参照してください。スマートポリシー条件:
-
スコープ: デリバリーグループ、マルチセッション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>
既存のアラートポリシーに 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\>}
ServiceNow を使用してアラートポリシーを構成する
アラートポリシーを構成して、ServiceNow (SNOW) に直接通知を送信し、ITサービス管理 (ITSM) ワークフローとのシームレスな統合を可能にすることができます。この統合により、Citrix Monitor で生成されたアラートが ServiceNow に自動的に転送され、一元的な追跡、エスカレーション、インシデント解決が可能になります。
ServiceNow 統合の利点
-
統合されたアラート管理: システムを切り替えることなく、Citrix Monitor インターフェイス内で直接 ServiceNow インシデントを作成、更新、管理できます。
-
自動ITSM構成: Monitor は、Webhook URL など、必要な ServiceNow 構成を自動的に取得し、手動設定の複雑さを軽減します。
-
合理化されたインシデント対応: アラートは ServiceNow に転送され、一元的なインシデント追跡と解決が行われるため、運用効率が向上します。
前提条件
ServiceNow 統合を構成する前に、以下を確認してください。
-
ITSM Adapter サービスで ServiceNow インスタンスが構成されていること。
-
Monitor でアラートポリシーを管理するための必要な権限があること。
ServiceNow 統合ステータスの確認
ITSM Adapter サービスとの統合ステータスは、Monitor > 統合とデータエクスポート ページで確認できます。このページには以下が表示されます。
-
現在の統合ステータス:
-
開始: ITSM Adapter 統合が構成されていないことを示します。初期設定プロセスを開始するには、このオプションを選択します。
-
管理: ITSM Adapter 統合がアクティブで稼働中であることを示します。ServiceNow 統合設定を表示または変更するには、このオプションを選択します。
-
-
関連付けられた ServiceNow インスタンス URL (ServiceNow インスタンスが ITSM Adapter で構成されている場合にのみ表示されます)。
ServiceNow統合ステータス(/en-us/citrix-daas/media/snow-integration-status.png)
ServiceNow通知でアラートポリシーを構成する
ServiceNowに通知を送信するようにアラートポリシーを構成するには、次の手順を実行します。
-
アラート > Citrixアラートポリシー に移動し、ポリシーカテゴリ(例: マルチセッションOSポリシー)を選択します。
-
作成 をクリックして新しいポリシーを作成するか、既存のポリシーを選択して 編集 をクリックします。
-
必要に応じてポリシー条件を構成します。
-
通知設定 セクションで、ServiceNow統合 オプションを探します。
-
ITSMアダプターが利用可能な場合:
-
チェックボックスをオンにして、このポリシーのServiceNow経由のアラート通知を有効にします。
-
関連付けられたServiceNowインスタンスURLが参照用に表示されます。
-
ポリシーにすでにWebhookが構成されている場合、ServiceNow統合を有効にすると既存のWebhook構成が上書きされることを警告メッセージで通知します。
ServiceNowアラートポリシーが有効(/en-us/citrix-daas/media/snow-alert-policy-enabled.png) -
-
ITSMアダプターが利用できない場合:
-
ITSM統合が現在構成されていないことを示すメッセージが表示されます。
-
統合設定にアクセスするには、開始 をクリックします。詳細については、ドキュメントを参照してください。
「ServiceNowアラートポリシーが構成されていません」(/en-us/citrix-daas/media/snow-alert-policy-not-configured.png) -
-
-
保存をクリックしてポリシーを保存します。
構成されると、ポリシー条件を満たすアラートは自動的にServiceNowに転送され、ITSM構成に基づいてインシデントまたはイベントとして管理できます。
アラートの一括解除
この機能は、管理者のアラート管理プロセスを最適化し、柔軟性を提供し、アラート疲労を軽減します。管理者は、時間、種類、またはカテゴリに基づいてアラートを一括解除でき、メンテナンス中やハイパーバイザーおよびその他の環境を扱う際のアラート管理を簡素化します。
アラートの一括解除は、管理者がワークロードを効率的に管理し、大量のアラートに圧倒されるのを防ぐのに役立ちます。
アラートを一括解除する手順
-
アラート > Citrixアラートタブに移動します。アラートが表示されます。「一括アラート」(/en-us/citrix-daas/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 "webhookprofile1" -Description "Description" -Url $url -Headers $headers -PayloadFormat $payloads -Platform Slack -Type Webhook -MethodType POST
承認ヘッダー付きで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
例:
プロファイルが作成されたら、データベースで確認できます。また、新しく作成された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 -Platform Slack -Type Webhook -MethodType POST
例:
すべての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
ローカルホストキャッシュ構成同期失敗アラートの監視
ローカルホストキャッシュを使用すると、Cloud ConnectorがCitrix Cloudへの接続を失った場合でも、ユーザーセッションを続行できます。ローカルホストキャッシュで使用されるキャッシュは、ローカルホストキャッシュモードがアクティブ化されたときに最新の構成を保証するために、プライマリデータベースと定期的に同期されます。ローカルホストキャッシュと構成同期プロセスに関する詳細については、ローカルホストキャッシュを参照してください。構成同期が3回以上連続して失敗した場合、Citrix Monitorは管理者へ警告アラートを送信します。
構成同期の失敗を管理者に通知するために、Citrix Monitorにローカルホストキャッシュ - 構成同期の失敗という事前定義されたアラートポリシーが導入されました。新しく導入されたポリシーは、Monitor > Citrix Alertsで確認できます。事前定義されたポリシーを変更して、メール受信者またはWebhookを追加または編集し、アラート管理ツールまたはITSMツールでプロアクティブな通知を受け取ることができます。
ローカルホストキャッシュ - 構成同期の失敗アラートポリシーのスコープは、サイトのみに限定されます。
ハイパーバイザーアラートの監視
Monitorは、ハイパーバイザーの健全性を監視するためのアラートを表示します。Citrix Hypervisor™およびVMware vSphereからのアラートは、ハイパーバイザーのパラメーターと状態の監視に役立ちます。ハイパーバイザーへの接続ステータスも監視され、ホストのクラスターまたはプールが再起動された場合、または利用できない場合にアラートが提供されます。
ハイパーバイザーアラートを受信するには、管理タブでホスティング接続が作成されていることを確認してください。詳細については、接続とリソースを参照してください。これらの接続のみがハイパーバイザーアラートについて監視されます。次の表に、ハイパーバイザーアラートのさまざまなパラメーターと状態について説明します。
| アラート | サポートされているハイパーバイザー | トリガー元 | 条件 | 構成 |
|---|---|---|---|---|
| CPU使用率 | シトリックス ハイパーバイザー、ヴイエムウェア ブイスフィア | ハイパーバイザー | CPU使用率アラートのしきい値に達したか、超えた場合 | アラートしきい値はハイパーバイザーで構成する必要があります。 |
| メモリ使用量 | シトリックス ハイパーバイザー、ヴイエムウェア vSphere | ハイパーバイザー | メモリ使用量アラートしきい値に達したか、超過しました | アラートしきい値はハイパーバイザーで構成する必要があります。 |
| ネットワーク使用量 | シトリックス ハイパーバイザー、ヴイエムウェア vSphere | ハイパーバイザー | ネットワーク使用量アラートしきい値に達したか、超過しました | アラートしきい値はハイパーバイザーで構成する必要があります。 |
| ディスク使用量 | ヴイエムウェア vSphere | ハイパーバイザー | ディスク使用量アラートしきい値に達したか、超過しました | アラートのしきい値はハイパーバイザーで構成する必要があります。 |
| ホスト接続または電源状態 | ヴイエムウェア ブイスフィア | ハイパーバイザー | ハイパーバイザーホストが再起動されたか、利用できません | アラートはVMware vSphereにプリビルドされています。追加の構成は不要です。 |
| ハイパーバイザー接続が利用できません | Citrix ハイパーバイザー、VMware vSphere | デリバリーコントローラー | ハイパーバイザー(プールまたはクラスター)への接続が失われたか、電源がオフになったか、再起動されました。このアラートは、接続が利用できない間、1時間ごとに生成されます。 | アラートはDelivery Controllerにプリビルドされています。追加の構成は不要です。 |
注:
アラートの構成の詳細については、Citrix XenCenter Alerts を参照するか、VMware vCenter Alertsのドキュメントを確認してください。
メール通知設定は、Citrix Alerts Policy > Site Policy > Hypervisor Health で構成できます。ハイパーバイザーアラートポリシーのしきい値条件は、ハイパーバイザーからのみ構成、編集、無効化、または削除でき、Monitorからはできません。ただし、メール設定の変更やアラートの解除はMonitorで行うことができます。
重要:
-
1日以上経過したすべてのハイパーバイザーアラートは自動的に却下されます。
-
ハイパーバイザーによってトリガーされたアラートはMonitorでフェッチされ、表示されます。ただし、ハイパーバイザーアラートのライフサイクル/状態の変更はMonitorに反映されません。
-
ハイパーバイザーコンソールで正常、却下、または無効になっているアラートはMonitorに表示され続け、明示的に却下する必要があります。
-
Monitorで却下されたアラートは、ハイパーバイザーコンソールでは自動的に却下されません。
ハイパーバイザーの健全性という新しいアラートカテゴリが追加され、ハイパーバイザーアラートのみをフィルターできるようになりました。これらのアラートは、しきい値に達するか超えると表示されます。ハイパーバイザーアラートは次のいずれかです。
-
重大 — ハイパーバイザーアラームポリシーの重大なしきい値に達したか、超えた場合
-
警告 — ハイパーバイザーアラームポリシーの警告しきい値に達したか、超えた場合
-
却下済み — アクティブなアラートとして表示されなくなったアラート