デ，タの粒度と保持
デ，タ値の集計
监控服务はユーザーセッション使用状況,ユーザーログオンの処理性能の詳細,セッションの負荷分散の詳細,および接続とマシンのエラー情報を含む,さまざまなデータを収集します。デ，タはカテゴリにより異なる方法で集計されます。OData方法APIを使って示されたデータ値の集計を理解することは,データの解釈に不可欠です。次に例を示します:
- 接続セッション连接(会话)やマシンエラー(机器故障)は一定の期間の状態を示すため,その期間内の最大値として公開されます。
- ログオン期間(登录时间)は時間の長さを示す指標であるため,期間内の平均として公開されます。
- ログオン数(登录数)および接続障害(连接失败)は一定の期間に発生した数を示し,期間内の合計値として公開されます。
同時デ，タ評価
重複しているセッションは同時発生していると考える必要があります。ただし,時間間隔が1分の場合,その1分内のすべてのセッションが(重複していても重複していなくても)同時と見なされます。この間隔のサイズは非常に小さいため,精度の計算に関連するパフォーマンス上のオーバーヘッドを考慮する必要はありません。2つのセッションがその1時間内の別々の1分間に発生する場合,それらは重複しているとはみなされません。
サマリ，表と生デ，タの相関
デ:タモデルでは，以下の2:の方法でメトリックが示されます:
- サマリ，テ，ブルでは，分単位，時間単位，および日単位のメトリックを集計したものが示されます。
- 生データは,セッション,接続,アプリケーション,およびそのほかのオブジェクト内で記録された個々のイベントまたは現在の状態を示します。
データをAPIコール間またはそのデータモデル内で関連付けるときは,以下の概念および制限事項を考慮してください。
- 未完の間隔にはサマリ，デ，タがありません。メトリックサマリーは長時間での履歴傾向を示すためのものであり,完結した間隔のサマリーテーブルに集計されます。デタ収集の開始時(利用可能な最も古いデタ)や終了時の未完の間隔のサマリデタはありません。これは,1日(間隔= 1440)の集計値の場合,最初と最後の未完の1日にはデータがないことを意味します。これらの未完の間隔に生デ，タが存在しても，そのデ，タが集計されることはありません。各データ粒度の最初と最後の集計間隔は,各サマリーテーブルから最小と最大のSummaryDateを取得することで決定できます。摘要日期列は，間隔の開始時を示します。Granularity列はその集計データの間隔の長さを示します。
- 時間による関連付け。前のセクションで説明したように，メトリックスは完結した間隔のサマリ，テ，ブルに集計されます。これらの値は履歴傾向を知る目的で使用できますが,生イベントの方が集計された値よりも傾向分析に適切な状態を示している場合があります。要約データと生データの時間ベースの比較では,発生する可能性のある部分区間,または期間の開始と終了の要約データがないことを考慮する必要があります。
- 欠落▪▪ベントまたは潜在▪▪ベント集計期間で欠落または潜在しているイベントがあると,サマリーテーブルに集計されたメトリックが正確でない場合があります。监控服务では現在の状態の正確な維持が試行されますが,過去にさかのぼって欠落イベントや潜在イベントをサマリーテーブルに再集計することはありません。
- 接続の高可用性。接続の高可用性により,現在の接続のサマリーデータ数に差異が生じることがありますが,セッションインスタンスは生データ内で実行されています。
- デ，タの保持期間。サマリテブルのデタは，生ベントデタとは異なるグルミングスケジュルで保持されます。このため,サマリーテーブルまたは生テーブルのクリーンアップにより,データが消去されている場合があります。デ，タの保有期間は，サマリ，デ，タの粒度によっても異なる場合があります。低い粒度(分単位)のデタは，高い粒度(日単位)のデタよりも早くクリンアップされます。特定の粒度のデ，タが消去されていても，より高い粒度のデ，タが存在している場合があります。APIコールでは指定した粒度のデータのみが返されるため,データを取得できない場合でもその期間内のより高い粒度では取得できることがあります。
- タ▪▪ムゾ▪▪ン。格納されるメトリックのタesc escムスタンプでは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コマンドは無効になっています。また，以下はラ
- Premiumラaapl . exeセンスがあるサaapl . exeト——すべての設定のクリーンアップ保持が1000日間に制限されます(Citrixでは365日を推奨)。
- 高级ラ▪▪センスがあるサ▪▪ト—すべての設定のクリンアップ保持が31日間に制限されます。
- その他すべてのサ@ @ト—すべての設定のクリンアップ保持が7日間に制限されます。
例外：
- GroomApplicationInstanceRetentionDaysは,溢价ライセンスがあるサイトにのみ設定できます。
- GroomApplicationErrorsRetentionDaysおよびGroomApplicationFaultsRetentionDaysは，Premiumラesc escセンスがあるサesc esc escトでは31日間の制限があります。
デ，タを長期間保持すると，テ，ブルのサズにいて以下の影響が発生します:
時間単位のデ，タ。時間単位のデータを2年などの長期間保持すると,1000個のデリバリーグループがあるサイトではデータベースが以下の数式に基づいて増大します:
“1000個のデリバリーグループ×24時間/日×365日/年×2年= 17520000行のデータ”集計テーブルのデータ量が多いため,パフォーマンスに大きな影響を及ぼします。ダッシュボードのデータがこのテーブルから取得されると,データベースサーバーに対する要求が高くなることがあります。デ，タ量が過度に多いと，パフォ，マンスが大きく低下することがあります。
セッションと▪▪ベントのデ▪▪タ。各セッションの開始時および接続/再接続時に収集されるデタです。大規模サト(10万ユザなど)では，このデタの量が急速に増加します。たとえば,これらのテーブルでは2年間で1 tb以上のデータが保持され,高性能なエンタープライズレベルのデータベースが必要になります。