データ粒度と保持
データ値の集計
Monitor Serviceは、ユーザーセッションの使用状況、ユーザーログオンパフォーマンスの詳細、セッション負荷分散の詳細、接続およびマシン障害情報など、さまざまなデータを収集します。データはカテゴリに応じて異なる方法で集計されます。OData Method APIを使用して提示されるデータ値の集計を理解することは、データを解釈するために不可欠です。例:
-
接続されたセッションとマシン障害は一定期間に発生します。そのため、一定期間の最大値として公開されます。
-
ログオン期間は時間の長さを測定するものであるため、一定期間の平均値として公開されます。
-
ログオン数と接続障害は一定期間の発生回数であるため、一定期間の合計値として公開されます。
同時データ評価
セッションが同時であると見なされるには、重複している必要があります。ただし、時間間隔が1分の場合、その1分間のすべてのセッション(重複しているかどうかに関わらず)は同時であると見なされます。間隔のサイズが非常に小さいため、精度を計算するのに伴うパフォーマンスオーバーヘッドは、追加される価値に見合いません。セッションが同じ時間内に発生しても、同じ分内に発生しない場合、それらは重複しているとは見なされません。
サマリーテーブルと生データの相関
データモデルは、メトリックを2つの異なる方法で表します。
-
サマリーテーブルは、分単位、時間単位、日単位の時間粒度でメトリックの集計ビューを表します。
-
生データは、セッション、接続、アプリケーション、およびその他のオブジェクトで追跡される個々のイベントまたは現在の状態を表します。
API呼び出し間またはデータモデル自体内でデータを関連付けようとするときは、次の概念と制限を理解することが重要です。
-
部分的な間隔のサマリーデータはありません。 メトリックのサマリーは、長期間にわたる履歴トレンドのニーズを満たすように設計されています。これらのメトリックは、完全な間隔についてサマリーテーブルに集計されます。データ収集の開始時(利用可能な最も古いデータ)または終了時の部分的な間隔については、サマリーデータはありません。1日の集計(Interval=1440)を表示する場合、これは最初と最新の不完全な日にはデータがないことを意味します。これらの部分的な間隔には生データが存在する可能性がありますが、集計されることはありません。特定のデータ粒度について最も早い集計間隔と最も遅い集計間隔を決定するには、特定のサマリーテーブルから最小および最大のSummaryDateを取得します。SummaryDate列は間隔の開始を表します。Granularity列は集計データの期間の長さを表します。
-
時間による相関。 メトリックは、前のセクションで説明したように、完全な間隔についてサマリーテーブルに集計されます。これらは履歴トレンドに使用できますが、生イベントはトレンド分析のために集計されたものよりも現在の状態をより正確に反映している可能性があります。サマリーデータと生データの時間ベースの比較を行う場合、発生する可能性のある部分的な間隔や期間の開始と終了にはサマリーデータがないことを考慮する必要があります。
-
見逃されたイベントと潜在的なイベント。 イベントが見逃されたり、集計期間に対して潜在的であったりする場合、サマリーテーブルに集計されるメトリックはわずかに不正確になる可能性があります。Monitor Serviceは正確な現在の状態を維持しようとしますが、見逃されたイベントや潜在的なイベントのために、サマリーテーブルの集計を再計算するために時間を遡ることはありません。
-
接続の高可用性。 接続HA中、現在の接続のサマリーデータカウントにギャップが生じますが、セッションインスタンスは引き続き生データで実行されています。
-
データ保持期間。 サマリーテーブルのデータは、生イベントデータのスケジュールとは異なるグルーミングスケジュールで保持されます。データがサマリーテーブルまたは生テーブルからグルーミングされたために、データが欠落している可能性があります。保持期間は、サマリーデータの異なる粒度によっても異なる場合があります。粒度の低いデータ(分単位)は、粒度の高いデータ(日単位)よりも早くグルーミングされます。グルーミングによってある粒度からデータが欠落している場合でも、より高い粒度で見つかる可能性があります。API呼び出しは要求された特定の粒度のみを返すため、ある粒度でデータが受信されないからといって、同じ期間のより高い粒度でデータが存在しないという意味ではありません。
-
タイムゾーン。 メトリックはUTCタイムスタンプで保存されます。サマリーテーブルは、時間単位のタイムゾーン境界で集計されます。時間単位の境界に該当しないタイムゾーンの場合、データが集計される場所に関して多少の不一致が生じる可能性があります。
粒度と保持
Monitorによって取得される集計データの粒度は、要求された時間(T)スパンの関数です。ルールは次のとおりです。
-
0 \< T \<= 30日の場合は時間単位の粒度を使用
-
T \> 31日の場合は日単位の粒度を使用
集計データから取得されない要求されたデータは、生のセッションおよび接続情報から取得されます。このデータは急速に増加する傾向があるため、独自のグルーミング設定があります。グルーミングにより、関連データのみが長期的に保持されます。これにより、レポート作成に必要な粒度を維持しながら、パフォーマンスが向上します。
| # | 設定名 | 影響を受けるスキーマテーブル | Monitorページで影響を受けるテーブルとグラフ | Premiumの保持日数 | Advancedの保持日数 |
|---|---|---|---|---|---|
| 1 | GroomSessionsRetentionDays | MonitorData.Session および Monitordata.Connection テーブル | この設定は、セッションの詳細、ユーザーセッションごとのログオン期間、トレンドページのアプリケーションベースの使用状況テーブルに影響します。 | 90 | 31 |
| 2 | GroomFailuresRetentionDays | MonitorData.MachineFailureLog および MonitorData.ConnectionFailureLog | トレンドページ: この設定は、障害タブのグラフとテーブルに影響します。 | 90 | 31 |
| 3 | GroomLoadIndexesRetentionDays | MonitorData.LoadIndex | この設定は、トレンドページの「Load Evaluator Index」タブに表示されるデータに影響します。 | 3 | 3 |
| 4 | GroomDeletedRetentionDays | LifecycleStateが「Deleted」であるMonitorData.Machine、MonitorData.Catalog、MonitorData.DesktopGroup、およびMonitorData.Hypervisorエンティティ。この設定は、関連するSession、SessionDetail、Summary、Failure、またはLoadIndexレコードも削除します。 | LifecycleStateが「Deleted」であるMachine、Catalog、DesktopGroup、およびHypervisorエンティティ。この設定は、関連するSession、SessionDetail、Summary、Failure、またはLoadIndexレコードも削除します。 | 90 | 31 |
| 5 | GroomSummariesRetentionDays | MonitorData.DesktopGroupSummary、MonitorData.FailureLogSummary、およびMonitorData.LoadIndexSummary | この設定は、トレンドページのすべてのグラフデータに影響します。 | 365 | 31 |
| 6 | GroomMachineHotfixLogRetentionDays | MonitorData.Hotfix | この設定は、マシン詳細ページに表示されるVDAホットフィックスデータに影響します。 | 90 | 31 |
| 7 | GroomHourlyRetentionDays | すべての概要テーブル | これは、トレンドページに表示される週次グラフに影響します。 | 32 | 31 |
| 8 | GroomApplicationInstanceRetentionDays | MonitorData.ApplicationInstance | この設定は、[キャパシティ管理]タブのグラフとテーブル、および[トレンド]ページのアプリケーション使用状況テーブルに影響します。 | 90 | 該当なし |
| 9 | GroomNotificationLogRetentionDays | MonitorData.NotificationLog | この設定は、Monitorに表示されるアラートに影響します。 | 90 | 該当なし |
| 10 | GroomResourceUsageRawDataRetentionDays | MonitorData.Resourceutilization | この設定は、[履歴マシン使用率]の[マシン詳細]ページに表示されるCPUおよびメモリのグラフと、[コスト最適化]領域の[ワークロードの適正化]タブでのデータ計算に影響します。 | 3 | 3 |
| 11 | GroomResourceUsageHourDataRetentionDays | MonitorData.Resourceutilizationsummary | この設定は、「履歴マシン使用率」のマシン詳細ページに表示されるCPUとメモリのグラフ、およびコスト最適化領域の「ワークロードの適正化タブ」でのデータ計算に影響します。 | 30 | 30 |
| 12 | GroomResourceUsageDayDataRetentionDays | MonitorData.Resourceutilizationsummary | この設定は、トレンドページの「マシンのリソース使用率」に表示されるCPUとメモリのグラフ、および特定の「マシンの使用率」ページに影響します。 | 365 | 31 |
| 13 | GroomProcessUsageRawDataRetentionDays | MonitorData.ProcessUtilization | この設定は、マシンの履歴使用状況ページに表示されるプロセスごとのリソース傾向情報に影響します。 | 1 | 1 |
| 14 | GroomProcessUsageHourDataRetentionDays | MonitorData.ProcessUtilizationHourSummary | この設定は、マシンの履歴使用状況ページに表示されるプロセスごとのCPUおよびメモリ使用傾向に影響します。 | 7 | 7 |
| 15 | GroomProcessUsageDayDataRetentionDays | MonitorData.ProcessUtilizationDaySummary | この設定は、マシンの履歴使用状況ページに表示されるプロセスごとのCPUおよびメモリ使用傾向に影響します。 | 30 | 30 |
| 16 | GroomSessionMetricsDataRetentionDays | MonitorData.Sessionmetrics | この設定は、ユーザー詳細ページの「セッションパフォーマンス」タブに表示されるすべてのグラフに影響します。 | 1 | 1 |
| 17 | GroomMachineMetricDataRetentionDays | MonitorData.Machinemetrics | この設定は、トレンドページの「リソース使用率」タブにあるグラフとテーブルに影響します。 | 3 | 3 |
| 18 | GroomMachineMetricDaySummaryDataRetentionDays | MonitorData.MachineMetricDaySummary | この設定は、トレンドページの「リソース使用率」タブにあるグラフと表に影響します。 | 365 | 31 |
| 19 | GroomApplicationErrorsRetentionDays | MonitorData.ApplicationError | この設定は、アプリケーションページの「アプリケーションエラー」列に表示されるエラーの詳細に影響します。 | 1 | 1 |
| 20 | GroomApplicationFaultsRetentionDays | MonitorData.Applicationfailure | この設定は、アプリケーションページの「アプリケーション障害」列に影響します。 | 1 | 1 |
注意:
Monitor Serviceデータベースの値を変更することはできません。
長期間データを保持すると、テーブルサイズに次のような影響があります。
-
時間単位のデータ。 時間単位のデータを最大2年間データベースに保持すると、1000のデリバリーグループを持つサイトでは、データベースが次のように増加する可能性があります。1000 delivery groups x 24 hours/day x 365 days/year x 2 years = 17,520,000行のデータ。集計テーブル内のこれほど大量のデータがパフォーマンスに与える影響は甚大です。ダッシュボードデータはこのテーブルから取得されるため、データベースサーバーへの要件は大きくなる可能性があります。過度に大量のデータは、パフォーマンスに劇的な影響を与える可能性があります。
-
セッションおよびイベントデータ。 これは、セッションが開始され、接続/再接続が行われるたびに収集されるデータです。大規模なサイト(10万ユーザー)では、このデータは急速に増加します。たとえば、これらのテーブルの2年分のデータは1TBを超えるデータとなり、ハイエンドのエンタープライズレベルのデータベースが必要になります。