データの粒度と保持
データ値の集計
监控服务はユーザーセッション使用状況,ユーザーログオンの処理性能の詳細,セッションの負荷分散の詳細,および接続とマシンのエラー情報を含む,さまざまなデータを収集します。データはカテゴリにより異なる方法で集計されます。OData方法APIを使って示されたデータ値の集計を理解することは,データの解釈に不可欠です。例：
- 接続セッション连接(会话)やマシンエラー(机器故障)は一定の期間の状態を示すため,その期間内の最大値として公開されます。
- ログオン期間(登录时间)は時間の長さを示す指標であるため,期間内の平均として公開されます。
- ログオン数(登录数)および接続障害(连接失败)は一定の期間に発生した数を示し,期間内の合計値として公開されます
同時データ評価
重複しているセッションは同時発生していると考える必要があります。ただし,間隔として1分を指定した場合,1分以内に発生するすべてのセッションは(重複しているかしていないかに関係なく)すべて同時であるとみなされます。つまり,間隔のサイズが非常に小さいため,精度の計算に関係するパフォーマンス上のオーバーヘッドを考慮する必要はありません。2つのセッションがその1時間内の別々の1分間に発生する場合,それらは重複しているとはみなされません。
サマリー表と生データの相関
データモデルでは,以下の2つの方法でメトリックが示されます:
- サマリーテーブルでは,分単位,時間単位,および日単位のメトリックを集計したものが示されます。
- 生データは,セッション,接続,アプリケーション,およびそのほかのオブジェクト内で記録された個々のイベントまたは現在の状態を示します。
データをAPIコール間またはそのデータモデル内で関連付けるときは,以下の概念および制限事項を考慮してください。
- 未完の間隔にはサマリーデータがありません。メトリックサマリーは長時間での履歴傾向を示すためのものであり,完結した間隔のサマリーテーブルに集計されます。データ収集の開始時や終了時のサマリーデータはありません。1日（間隔=1440）の集計値の場合、最初と最後の未完の1日にはデータがないことを意味します。これらの未完の間隔に生データが存在しても、そのデータが集計されることはありません。各データ粒度の最初と最後の集計間隔は、各サマリーテーブルから最小と最大のSummaryDateを取得することで決定できます。SummaryDate列は、間隔の開始時を示します。Granularity列はその集計データの間隔の長さを示します。
- 時間による関連付け。前述のように,メトリックは完結した間隔のサマリーテーブルに集計されます。これらの値は履歴傾向を知る目的で使用できますが,生イベントの方が集計された値よりも傾向分析に適切な状態を示している場合があります。集計値と生データとを時間ベースで比較する場合,未完の間隔や間隔の最初と最後にサマリーデータがないことを考慮する必要があります。
- 欠落イベントまたは潜在イベント集計期間で欠落または潜在しているイベントがあると,サマリーテーブルに集計されたメトリックスが正確でない場合があります。监控服务では現在の状態の正確な維持が試行されますが,過去にさかのぼって欠落イベントや潜在イベントをサマリーテーブルに再集計することはありません。
- 接続の高可用性。接続の高可用性により,現在の接続のサマリーデータ数に差異が生じることがありますが,セッションインスタンスは生データ内で実行されています。
- データの保持期間。サマリーテーブルのデータは,生イベントデータとは異なるグルーミングスケジュールで保持されます。このため,サマリーテーブルまたは生テーブルのクリーンアップにより,データが消去されている場合があります。データの保持期間は,サマリーデータの粒度によっても異なる場合があります。低い粒度(分単位)のデータは,高い粒度(日単位)のデータよりも早くクリーンアップされます。特定の粒度のデータが消去されていても,より高い粒度のデータが存在している場合があります。APIコールでは指定した粒度のデータのみが返されるため,データを取得できない場合でもその期間内のより高い粒度では取得できることがあります。
- タイムゾーン。格納されるメトリックのタイムスタンプではUTCが使用されます。サマリーテーブルは1時間区切りのタイムゾーンごとに集計されます。1時間区切りのタイムゾーンに属さない場合は、データの集計先に不整合が生じることがあります。
データの粒度と保持
导演で取得される集計データの粒度は,要求された時間(T)の関数です。以下の規則があります。
- 0 < T < = 1時間の場合は分単位の粒度
- 0 < T < = 30日の場合は時間単位の粒度
- T > 31日の場合は日単位の粒度
集計データから取得されないデータを要求すると,生のセッション(会话)および接続(连接)情報から取得されます。このデータの量はすぐに大きくなるため,専用のスケジュールでクリーンアップされます。クリーンアップにより,意味のあるデータのみが長期間保持されます。これにより,レポートに必要な粒度を維持しながら良好なパフォーマンスが提供されます。高级版では,クリーンアップが開始されるまでの日数をカスタマイズできます。
設定にアクセスするには,交付控制器で以下のPowerShellコマンドを実行します:
asnp Citrix。＊Get-MonitorConfiguration Set-MonitorConfiguration - | 設定名 | 対象データ | デフォルト値(溢价,日数) | デフォルト値(溢价以外,日数) | |
|---|---|---|---|---|
| 1 | GroomSessionsRetentionDays | セッション終了後のセッションレコードと接続レコードの保有 | 90 | 7 |
| 2 | GroomFailuresRetentionDays | MachineFailureLogレコードおよびConnectionFailureLogレコード | 90 | 7 |
| 3. | GroomLoadIndexesRetentionDays | LoadIndexレコード | 90 | 7 |
| 4 | GroomDeletedRetentionDays | “删除”LifecycleStateがである机エンティティ,目录エンティティ,DesktopGroupエンティティ,およびHypervisorエンティティ。関連する会话レコード,SessionDetailレコード,总结レコード,失败レコード,またはLoadIndexレコードも削除されます。 | 90 | 7 |
| 5 | GroomSummariesRetentionDays | DesktopGroupSummaryレコード,FailureLogSummaryレコード,およびLoadIndexSummaryレコード。集計データ(日単位) | 90 | 7 |
| 6 | GroomMachineHotfixLogRetentionDays | VDAマシンおよび控制器マシンに適用された热修复补丁 | 90 | 90 |
| 7 | GroomMinuteRetentionDays | 集計データ(分単位) | 3. | 3. |
| 8 | GroomHourlyRetentionDays | 集計データ(時間単位) | 32 | 7 |
| 9 | GroomApplicationInstanceRetentionDays | アプリケーションインスタンスの履歴 | 90 | 0 |
| 10 | GroomNotificationLogRetentionDays | 通知ログレコード | 90 | |
| 11 | GroomResourceUsageRawDataRetentionDays | リソース使用率データ(生データ) | 1 | 1 |
| 12 | GroomResourceUsageMinuteDataRetentionDays | リソース使用率サマリーデータ(分単位) | 7 | 7 |
| 13 | GroomResourceUsageHourDataRetentionDays | リソース使用率サマリーデータ(時間単位) | 30. | 7 |
| 14 | GroomResourceUsageDayDataRetentionDays | リソース使用率サマリーデータ(日単位) | 90 | 7 |
| 15 | GroomProcessUsageRawDataRetentionDays | プロセス使用率データ(生データ) | 1 | 1 |
| 16 | GroomProcessUsageMinuteDataRetentionDays | プロセス使用率データ(分単位) | 3. | 3. |
| 17 | GroomProcessUsageHourDataRetentionDays | プロセス使用率データ(時間単位) | 7 | 7 |
| 18 | GroomProcessUsageDayDataRetentionDays | プロセス使用率データ(日単位) | 30. | 7 |
| 19 | GroomSessionMetricsDataRetentionDays | セッションメトリックデータ | 1 | 1 |
| 20. | GroomMachineMetricDataRetentionDays | マシンメトリックデータ | 3. | 3. |
| 21 | GroomMachineMetricDaySummaryDataRetentionDays | マシンメトリックサマリーデータ | 90 | 7 |
| 22 | GroomApplicationErrorsRetentionDays | アプリケーションエラーデータ | 1 | 1 |
| 23 | GroomApplicationFaultsRetentionDays | アプリケーション障害データ | 1 | 1 |
注意：
监控服务データベースの値を変更した後でその値を適用するには,このサービスを再起動する必要があります。监控服务データベースの値の変更は,Citrixサポート担当者からの指示があった場合のみ行ってください。
GroomProcessUsageRawDataRetentionDays、GroomResourceUsageRawDataRetentionDaysおよびGroomSessionMetricsDataRetentionDaysの設定はデフォルト値の1に制限されていますが,GroomProcessUsageMinuteDataRetentionDaysはデフォルト値の3に制限されています。プロセス使用データが急速に増加する傾向があるため,これらの値を設定するPowerShellコマンドは無効になっています。以下は,ライセンスごとのその他の保持設定です。
- 溢价ライセンスがあるサイト——前述のクリーンアップ保持設定を任意の日数に更新できます。
- 先进ライセンスがあるサイト——すべての設定のクリーンアップ保持は31日間に制限されています。
- その他すべてのサイト——すべての設定のクリーンアップ保持は7日間に制限されています。
例外：
- GroomApplicationInstanceRetentionDaysは,溢价ライセンスサイトでのみ設定できます。
- GroomApplicationErrorsRetentionDaysおよびGroomApplicationFaultsRetentionDaysは,溢价ライセンスサイトでは31日間の制限があります。
データを長期間保持すると,テーブルのサイズについて以下の影響が発生することがあります:
時間単位のデータ。時間単位のデータを2年などの長期間保持すると,1000個のデリバリーグループがあるサイトではデータベースが以下の数式に基づいて増大します。
“1000個のデリバリーグループ×24時間/日×365日/年×2年= 17520000行のデータ”集計テーブルのデータ量が多いため,パフォーマンスに大きな影響を及ぼします。ダッシュボードのデータがこのテーブルから取得されることを考慮すると,データベースサーバーに対する要求は高くなります。データ量が過度に多いと,パフォーマンスが大きく低下します。
セッションとイベントのデータ。各セッションの開始時および接続/再接続時に収集されるデータです。大規模サイト(100000ユーザーなど)では,このデータの量が急速に増加します。たとえば,これらのテーブルでは2年間で1 tb以上のデータが保持され,高性能なエンタープライズレベルのデータベースが必要になります。