SysTrack ではメトリック毎に収集間隔などを調整してデータの収集量を調整していますが、特に重要なパフォーマンスカウンターに関するメトリックは 15秒間隔で収集し、1日に一度アップロードしています。(このアップロードやアップロードのためのデータ処理のことをSysTrackでは “Condense” と呼びます)

これらのメトリックデータを単純に1年間保持すると、

(60秒/15秒) * 60 分 * 24 時間 * 365日 = 2,102,400個 /年

となり1つのカウンターだけで200万個以上のデータを保持することになり、データベースサイズやディスクサイズへの影響が大きくなります。
このようにメトリックの粒度(収集間隔)とデータサイズはトレードオフの関係にあるため、どの製品でもこれらの考え方については製品の思想が強く反映されます。 SysTrack ではデータをロールアップしながら保持するアプローチを取っているのですが、データの持ち方は非常にユニークなので、はじめに混乱しやすいポイントの一つです。今日はこの話について掘り下げます。

SysTrackのデータ収集のタイムラインとデータ保持期間

SysTrack のエージェントからのデータ収集は大きく以下のようなデータのタイムラインを持っています。

収集間隔 データ種類 詳細
ライブ アラート・アラーム 各エージェントで検知したアラートやアラーム情報は検知後直ちにサーバーに通知されます
15秒 パフォーマンスカウンター
(ローカルDB)
このデータにアクセスするときには SysTrack Masterから直接端末のローカルDBにアクセスして表示します
5分 システムの健全性情報 vScape などを通じて確認するシステム毎のリアルタイム健全性情報は5分間隔で収集されます。端末ごとに1,571バイトのUDPパケットが、5分に一度(ランダム化されています)アップロードされます。
24時間 各エージェントに格納されているローカルデータベースの情報 15秒間隔のデータは10分おきのSummary情報として、ロールアップしてからアップロードされ、システムやソフトウェアのインベントリも最適化された形でアップロードされます

SysTrackではパフォーマンスカウンターの性能データはSysTrack Master側に持たずにエージェント内で保持し、グラフ化など分析が必要な時にエージェントに直接問い合わせて表示するような仕組みで動いています。
これらのデータは以下のようなロールアップを行いながら3年間保持されます。

15秒のデータは10分間隔 → 2時間間隔 とロールアップされていきますが、取得時は15秒間隔で取られるため、上の表には入っていません。
この点についてもう少し掘り下げてみます。

SysTrack でのパフォーマンスカウンターの収集間隔とデータ保持期間

種類 収集間隔 保持期間(デフォルト) データの場所
Detail 15秒 3日間 ローカルDB
Resolve や VisualizerのAnalysisツールでアクセス
Summary 10分 30日 ローカルDB
Trending 2時間 3年 ローカルDB

メトリック保持間隔の比較

このような話を聞いたときに vCenter のパフォーマンスチャートのデータ保持期間を思い浮かべた方もいるかもしれません。
vCenter のロールアップと比較してみましょう。

(例)vCenter メトリックのロールアップ

種類(間隔-保持期間) 収集間隔 (秒) 保持期間 (分) 1 年分のデータ数
リアルタイム(20秒 - 1時間) 20 60 180
過去1日(5分 - 1日) 300 1440 288
過去1週間(30分 - 1週間) 1800 10080 336
過去1か月(2時間 - 1か月) 7200 43200 360
過去1年(1日 - 1年) 86400 525600 365
合計 1529

このように見てみるとvCenter の場合、メトリックの粒度よりも短い保持期間で積極的にロールアップし、1つのパフォーマンスカウンター当たりのメトリック保持数を少なくしてvCenter データベースへのサイズ影響を極小化する事を重視しているのが分かります。

5分間隔でメトリックを収集・保持するようなアプローチの場合、同様の計算を行うと
(60分/5分)* 24時間 * 365日 = 105,120  個/年
となり1年で10万個近いデータを保持することになります。
これは等間隔でロールアップせずにデータを保持することを前提に考えた場合、5分くらいがちょうどいいと判断されたのではないかと思います。
注: vRealize Operations を想像された方もいるかもしれませんので念のため補足すると、こちらの場合データの保持期間はデフォルトで半年ですので上記の例は必ずしも当てはまりません(VMware KB 2147600

ここでSysTrackのデータ保持期間を見てみます。

SysTrackのパフォーマンスカウンターのデータ収集量

種類(間隔-保持期間) 収集間隔 (秒) 保持期間 (分) 1 年分のデータ数
Detail (15秒 – 3日) 15 4320 17280
Summary(10分 – 30日) 60 43200 4320
Trending (2時間 – 3年) 7200 1576800 4380
合計 25980

このように約2.6万程度のデータ収集となり、15秒間隔と言う粒度の細かいデータを取りながらデータの保持量は5分間隔で取った場合と比較しても約4分の1程度に収まっているのが分かります。

データアップロードの最適化と Condense

データ粒度を細かくしたときのもう一つの問題はデータ収集サーバーとのトラフィック増加と負荷の問題です。

SysTrack では15秒と言う細かい粒度でのデータを保持しますが、ネットワークトラフィックやサーバーの負荷を避けるためこれらのデータはサーバーにアップロードせず、1日に1回必要な情報だけをアップロードします。Condense の実行時間は一斉アップロードを避けるためにランダム化されており、スケジュール設定は出来ません。
エージェント毎のアップロード間隔(デフォルト:24時間)と前回の実行時間はレジストリキーから確認できます。

アップロード間隔:HKEY_LOCAL_MACHINE\SOFTWARE\LakesideSoftware\LsiAgent\CondenseThread\ClientWakeupInterval (デフォルト:86,400秒=24時間)
前回実行時間: HKEY_LOCAL_MACHINE\SOFTWARE\LakesideSoftware\LsiAgent\Settings\LastCondenseDateTime

このときも収集したデータをまとめてすべて上げてしまうとデータ量が非常に大きくなるため、ある程度データを最適化してサーバーにアップロードし、アップロードサイズを最適化します。これが “Condense” と言う処理のポイントです。

Condenseの主な対象データ

  • アプリケーションの利用データ
  • アラームの履歴
  • システムの変更履歴
  • Web の利用履歴

Condenseの詳細ロジックは公開しておりませんが、この処理の中でアプリケーションの利用データなどは同じアプリケーション毎にまとめたりしながら重要な情報を失わないようにサーバーにアップロードしています。1日にアップロードするデータはこのようにして100KB 以内に抑えることが出来ています。

ローカルDBを使用した分散DBアーキテクチャを取ることによりもう一つ別のメリットも生まれました。 SysTrackはエージェントと常時通信するようなアーキテクチャではないため、モバイルユーザーのようなサーバーに常時サーバーとつながっていることが出来ない端末もサポートすることが出来ます。

15秒間隔のデータを確認する

このような点を踏まえて SysTrackの15秒間隔のデータを見てみましょう。
15秒間隔は Resolve ツールの Blackbox ツールやGraphingツールからも確認できますが、今回は Visualizerから確認してみます。
Visualizer の「Analysis」から特定のシステムの System > % Total CPU を30日分出力してみます。

このように出力すると、なかなか気が付きませんが、上の図で緑の破線で示した部分は3日分のデータサイズなのでマウスをホーバーして動かしながらメトリック間隔を見てみると15秒間隔で表示されていることが分かります。
4日以上前から残りの部分(黒の破線)の部分については同様にして確認してみると、10分間隔で表示されたデータがプロットされているのが分かります。
つまり Visualizer はMasterサーバーに収集されたサマリーデータのみを表示しているイメージが強い方もいるかもしれませんが、Visualizer でも Analysis ツールを使った出力はエージェントに接続して15秒間隔のメトリックにアクセスしています。

SysTrack のエージェントが負荷を抑えながらたくさんの有用なデータを扱うことが出来るのは収集データを単純に増やすだけでなく、このような細部の最適化が行われている事が重要なポイントとなっています。

興味を持たれた方は以下のブログ記事やホワイトペーパーもご参照ください。

参考情報

Lakeside Software ブログ
Getting Real About Real-Time: 3 Steps to Historical & Real-Time Digital Experience Monitoring
SysTrack 概要 – ワークスペース環境の改善は見える化から

ホワイトペーパー
Getting Real About Real-Time
SysTrack Resolve 概要
サービスデスクソリューション