XenApp and XenDesktop

データの粒度と保持

データ値の集計

Monitor Serviceは、ユーザーセッションの使用状況、ユーザーログオンパフォーマンスの詳細、セッション負荷分散の詳細、および接続とマシンの障害情報など、さまざまなデータを収集します。データはカテゴリに応じて異なる方法で集計されます。OData Method APIを使用して提示されるデータ値の集計を理解することは、データを解釈するために不可欠です。例:

  • 接続されたセッションとマシン障害は一定期間に発生します。したがって、それらは期間中の最大値として公開されます。
  • ログオン期間は時間の長さを測定するものであるため、期間中の平均値として公開されます。
  • ログオン数と接続障害は一定期間に発生した回数であるため、期間中の合計値として公開されます。

同時データ評価

セッションは、同時であると見なされるためには重複している必要があります。ただし、時間間隔が1分の場合、その1分間のすべてのセッション(重複しているかどうかにかかわらず)は同時であると見なされます。これは、間隔のサイズが非常に小さく、精度を計算するのに伴うパフォーマンスオーバーヘッドが追加される価値に見合わないためです。セッションが同じ時間内に発生しても、同じ分内に発生しない場合、それらは重複しているとは見なされません。

サマリーテーブルと生データの相関

データモデルは、メトリックを2つの異なる方法で表します。:

  • サマリーテーブルは、メトリックの集計ビューを分、時間、日単位の粒度で表します。
  • 生データは、セッション、接続、アプリケーション、およびその他のオブジェクトで追跡される個々のイベントまたは現在の状態を表します。

API呼び出し間またはデータモデル自体内でデータを関連付けようとするときは、次の概念と制限を理解することが重要です。

  • 部分的な間隔のサマリーデータなし。 メトリックのサマリーは、長期間にわたる履歴トレンドのニーズを満たすように設計されています。これらのメトリックは、完全な間隔についてサマリーテーブルに集計されます。データ収集の開始時(利用可能な最も古いデータ)または終了時の部分的な間隔については、サマリーデータは存在しません。1日の集計(Interval=1440)を表示する場合、これは最初と最新の不完全な日にはデータがないことを意味します。これらの部分的な間隔には生データが存在する可能性がありますが、集計されることはありません。特定のデータ粒度について、最も早い集計間隔と最も遅い集計間隔は、特定のサマリーテーブルから最小および最大のSummaryDateを抽出することで判断できます。SummaryDate列は間隔の開始を表します。Granularity列は集計データの期間の長さを表します。
  • 時間による相関。 メトリックは、上記のように完全な間隔についてサマリーテーブルに集計されます。これらは履歴トレンドに使用できますが、生イベントはトレンド分析のために集計されたものよりも現在の状態をより正確に反映している場合があります。サマリーデータと生データの時間ベースの比較を行う際には、発生する可能性のある部分的な間隔や期間の開始と終了についてはサマリーデータが存在しないことを考慮する必要があります。
  • 見逃されたイベントと潜在的なイベント。 集計テーブルに集約されるメトリックは、イベントが見逃されたり、集計期間に対して潜在的である場合、わずかに不正確になる可能性があります。Monitor Serviceは正確な現在の状態を維持しようとしますが、見逃されたイベントや潜在的なイベントのために、集計テーブルの集計を過去に遡って再計算することはありません。
  • 接続の高可用性。 接続HA中、現在の接続のサマリーデータ数にギャップが生じますが、セッションインスタンスは引き続き生データで実行されます。
  • データ保持期間。 サマリーテーブルのデータは、生イベントデータのスケジュールとは異なるグルーミングスケジュールで保持されます。データは、サマリーテーブルまたは生テーブルからグルーミングによって削除されたため、欠落している可能性があります。保持期間は、サマリーデータの粒度によっても異なる場合があります。粒度の低いデータ(分単位)は、粒度の高いデータ(日単位)よりも早くグルーミングされます。グルーミングによってある粒度からデータが欠落している場合でも、より高い粒度で見つかる可能性があります。API呼び出しは要求された特定の粒度のみを返すため、ある粒度でデータが受信されないからといって、同じ期間のより高い粒度でデータが存在しないという意味ではありません。
  • タイムゾーン。 メトリックはUTCタイムスタンプで保存されます。サマリーテーブルは、時間単位のタイムゾーン境界で集約されます。時間単位の境界に該当しないタイムゾーンの場合、データが集約される場所に関して多少の不一致が生じる可能性があります。

粒度と保持期間

Directorによって取得される集約データの粒度は、要求された時間 (T) スパンの関数です。ルールは次のとおりです。

  • 0 < T <= 1時間の場合、1分単位の粒度を使用
  • 0 < T <= 30日間の場合は、1時間単位の粒度を使用
  • T > 31日間の場合は、1日単位の粒度を使用

集約データから取得されない要求データは、生のセッションおよび接続情報から取得されます。このデータは急速に増加する傾向があるため、独自のグルーミング設定があります。グルーミングにより、関連データのみが長期的に保持されます。これにより、レポート作成に必要な粒度を維持しながら、パフォーマンスが向上します。Platinumライセンスのサイトをご利用のお客様は、グルーミング保持期間を希望の保持日数に変更できます。変更しない場合は、デフォルトが使用されます。

設定にアクセスするには、Delivery Controller™で次のPowerShellコマンドを実行します。

asnp Citrix.*
 Get-MonitorConfiguration
 Set-MonitorConfiguration -<setting name> <value>

<!--NeedCopy-->

グルーミングの制御には、次の設定が使用されます。

設定名 影響を受けるグルーミング デフォルト値 Platinum (日数) プラチナ以外でのデフォルト値 (日数)
  1 グルームセッション保持日数 セッション終了後のセッションおよび接続レコードの保持 90 7
  2 グルーム失敗保持日数 マシン障害ログおよび接続障害ログレコード 90 7
  3 グルームロードインデックス保持日数 ロードインデックスレコード 90 7
  4 グルームデリーテッドリテンションデイズ LifecycleStateが「削除済み」であるマシン、カタログ、デスクトップグループ、およびハイパーバイザーエンティティ。これにより、関連するセッション、セッション詳細、概要、障害、またはロードインデックスのレコードも削除されます。 90 7
  5 グルームサマリーズリテンションデイズ デスクトップグループサマリー、障害ログサマリー、およびロードインデックスサマリーのレコード。集計データは日次粒度で提供されます。 90 7
  6 グルームマシンホットフィックスログリテンションデイズ VDAおよびコントローラーマシンに適用されたホットフィックス 90 90
  7 分単位の保持日数 集計データ - 分単位の粒度 3 3
  8 時間単位の保持日数 集計データ - 時間単位の粒度 32 7
  9 アプリケーションインスタンスの保持日数 アプリケーションインスタンスの履歴 90 0
  10 通知ログ整理保持日数 通知ログ記録 90  
  11 リソース使用状況生データ整理保持日数 リソース使用率データ - 生データ 1 1
  12 リソース使用状況分データ整理保持日数 リソース使用率サマリーデータ - 分単位の粒度 7 7
  13 リソース使用状況の時間データ整理保持日数 リソース使用率サマリーデータ - 時間単位 30 7
  14 リソース使用状況日次データの保持日数 リソース使用率サマリーデータ - 日単位 90 7
  15 プロセス使用状況生データの保持日数 プロセス使用率データ - 生データ 1 1
  16 プロセス使用状況分データ整理保持日数 プロセス使用率データ - 分単位の粒度 3 3
  17 プロセス使用状況時間データ整理保持日数 プロセス使用率データ - 時間単位の粒度 7 7
  18 プロセス使用状況日データ整理保持日数 プロセス使用率データ - 日単位の粒度 30 7
  19 セッションメトリクスデータの整理保持日数 セッションメトリックデータ 1 1
  20 マシンメトリクスデータの整理保持日数 マシンメトリックデータ 3 3
  21 マシンメトリクス日次サマリーデータの整理保持日数 マシンメトリックサマリーデータ 90 7
  22 アプリケーションエラー整理保持日数 アプリケーションエラーデータ 1 1
  23 アプリケーション障害整理保持日数 アプリケーション障害データ 1 1

注意: Monitor Serviceデータベースの値を変更した場合、新しい値を有効にするにはサービスを再起動する必要があります。Monitor Serviceデータベースへの変更は、Citrixサポートの指示の下でのみ行うことをお勧めします。

グルーミング保持に関する注意事項: GroomProcessUsageRawDataRetentionDays、GroomResourceUsageRawDataRetentionDays、およびGroomSessionMetricsDataRetentionDaysはデフォルト値の1に制限され、GroomProcessUsageMinuteDataRetentionDaysはデフォルト値の3に制限されます。プロセス使用状況データは急速に増加する傾向があるため、これらの値を設定するPowerShellコマンドは無効になっています。さらに、ライセンスベースの保持設定は次のとおりです。

  • Premiumライセンスのサイト - 上記のグルーミング保持設定を任意の日数に更新できます。
  • Advancedライセンスのサイト - すべての設定のグルーミング保持は31日に制限されます。
  • その他のすべてのサイト - すべての設定のグルーミング保持は7日に制限されます。

例外:

  • GroomApplicationInstanceRetentionDays という設定項目は、Premiumライセンスが適用されているサイトでのみ、その設定を行うことが可能です。
  • GroomApplicationErrorsRetentionDays および GroomApplicationFaultsRetentionDays の設定項目については、Premiumライセンスが適用されているサイトでのみ、その保持期間が最大で31日間に制限されることになります。

データを長期間保持すると、テーブルサイズに以下の影響があります。

  • 時間単位のデータ。 時間単位のデータがデータベースに最大 2 年間保持される場合、1000 のデリバリーグループを持つサイトでは、データベースが次のように増加する可能性があります。

    1000 デリバリーグループ x 24 時間/日 x 365 日/年 x 2 年 = 17,520,000 行のデータ。集計テーブルにこれほど大量のデータがあると、パフォーマンスへの影響は甚大です。ダッシュボードデータはこのテーブルから取得されるため、データベースサーバーへの要件は大きくなる可能性があります。過度に大量のデータは、パフォーマンスに劇的な影響を与える可能性があります。

  • セッションおよびイベントデータ。 これは、セッションが開始され、接続/再接続が行われるたびに収集されるデータです。大規模なサイト (10 万ユーザー) の場合、このデータは非常に速く増加します。たとえば、これらのテーブルの 2 年分のデータは 1 TB を超え、ハイエンドのエンタープライズレベルのデータベースが必要になります。

データの粒度と保持