データの粒度と保持

データ値の集計

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

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

同時データ評価

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

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

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

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

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

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

データの粒度と保持

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

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

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

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

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

注意：

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

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

• Premiumライセンスサイト - すべての設定のグルーミング保持期間は1000日に制限されています (Citrixは365日を推奨しています)。
• Advancedライセンスサイト - すべての設定のグルーミング保持期間は31日に制限されています。
• その他のすべてのサイト - すべての設定のグルーミング保持期間は7日に制限されています。

例外：

• GroomApplicationInstanceRetentionDays can be set only in Premium licensed sites.
• GroomApplicationErrorsRetentionDays and GroomApplicationFaultsRetentionDays are limited to 31 days in Premium licensed sites.

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

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

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

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