SysTrack の導入を始めると、「なぜ Visualizer の表示に2-3日待たないといけないのか?」と言う事を不思議に思われる方は多いのではないでしょうか。

表示が遅いときにレイクサイドからDeployツールから 以下のようなコマンドを依頼されて何のおまじないをしているのだろう?と思われた方もいるかもしれません。

エンドポイントに対して実行するコマンド
1)    Read Configuration Now
2)    Run Inventory Now
3)    Process Views Now
4)    Run Condense Now

マスターに対して実行するコマンド
1)    Refresh Visualizers Now

何となくエージェントのアップロード処理をコンデンスと言う事を知っている方もコンデンスとRefresh Visualizers Now だけでいいのでは?と思われるかもしれません。

これらのコマンドについてなぜ必要なのかを理解して頂くと、SysTrack エージェントのデータアップロードについて理解が深まるのではないかと思うので少し詳しく説明させて頂きます。

各コマンドについて理解する

1)    Read Configuration Now

実はこの処理は Visualizerの表示においてはそれほど重要ではありません。

ほとんどの Visualizer データがデフォルトのSysTrack エージェントの Configuration (エージェント構成)で正しく表示されるようになっているためです。

しかし、このコマンドによって、最新のエージェント構成を強制的に読み込ませることが出来ます。

Windows の GPOで例えると gpupdate /force に近い処理だと思って頂けると分かりやすいかもしれません。

このコマンドを実行しない場合、SysTrack エージェントはデフォルトで24時間に一度構成の変更を読み込みます。

2)    Run Inventory Now

SysTrack は数多くのインベントリ情報を収集しています。これらは、OS構成、ハードウェア情報、ソフトウェア情報、ネットワーク情報など多種のデータを更新しています。

SysTrackではこれらのインベントリを50種類程度に分けてそれぞれを適切な間隔で更新しています。(60分に一度程度のものから7日に一度程度のものまであります)

ここで、Run Inventory Nowコマンドを実行するとこれらの更新処理が走ります。

インベントリ更新はSysTrackエージェントの中では重い処理になるため、取得時間のタイミングでCPU使用率やIOPSなどが高いと判断すると取得をスキップします。

これは Run Inventory Now コマンドを実行した場合も同様です。

これらはIPアドレスやエージェントのバージョン情報など更新された後直ちにアップロードされるものもありますが、通常はSysTrack エージェントのCondenseフォルダ配下に一時ファイルが生成されます。

3)    Process Views Now

SysTrack エージェントはデフォルトで重要なテーブルは集約してアップロードされますが(コンデンス処理)、分析に必要なエージェントは System Viewと言う形で収集データを定義して部分的にアップロードされています。

これはダッシュボードのカスタマイズにおいても非常に重要な処理なのですが、このコマンドはこれらの System Viewの更新を行います。

System View はエージェント構成の「Views」で詳細を確認していますが、少し複雑で通常は1日に1回実行され、実行時間帯は各System Viewで個別に設定されています。

ここで計算された値もView毎にエージェントの Condenseフォルダ配下に一時ファイルとして格納されます。

4)    Run Condense Now

SysTrack のコンデンス処理は大きく二つの意味があります。

一つは集約レコードの送信で、SysTrackの特定のデータを集約してマスターサーバーにアップロードします。これにより累積の性能情報や利用状況データをマスターサーバーからも把握できるようになります。
もう一つは各種アップロード処理で、2) や3) の処理で生成された一時データや VMP用のデータなどをこの処理でまとめてアップロードします。

SysTrackのデータは負荷のかかる更新は出来るだけ時間を分散して実施し、変更やアップロードはまとめて行うようにしています。
この処理はデフォルトで24時間に一度行い、端末毎にランダマイズされた時間でアップロードが行われます。このため特定の時間帯にアップロードが集中することはありません。

ここで、注意すべき点は、コンデンスを実行するときには2)や3)の処理が必ず完了しているとは限らない事です。Viewやインベントリは半分しか更新されていないかもしれませんが、ここではこのときにあるものだけを送り、残りは次回にアップロードされます。

5)    Refresh Visualizers Now

コンデンスで生成された情報は直ちにVisualizer用のテーブルに反映されるのではなく別のテーブルに格納されています。
ここからアップロードされたエージェントの最新の情報を元にVisualizer 用のテーブルを更新する処理が Refresh Visualizers Now になります。

図解してみる - コンデンス処理と Visualizerのデータ更新

レイクサイドのドキュメントなどでこれらが分かりやすく書かれた資料が無いかを探してみたのですが、あまりいいものが無かったので図解してみました。

本当はもう少しかっこよく書きたかったのですが、絵心が無くてすみません。

前述の1) から 5) の処理はすべて非同期に行われるため、Visualizerが更新されるときに使用するデータはコンデンスされたものだけなので必ずしもエージェントがその日に収集した情報(のうちサーバーにアップロードするべきもの)がすべて含まれているとは限らない事があるため、ややエージェントによって更新が遅く見えるものが出てきます。これらの問題を補正するために 1) ~ 5) のコマンドを手動で実行します。

図解してみる - コンデンス処理と Visualizerのデータ更新

ここで少し上記の図をじっくり見てみます。

図を見ると、Viewの更新データを示す緑の丸は1から3までありますが、コンデンスの時間に更新されていたものは1と2だけになります。3の更新時間はコンデンスより後であったためです。

書いていませんが、インベントリでも同様の事が起こりえます。

この3のデータは Visualizerのデータを更新するときには更新されているので一見Visualizerとエージェントのデータに整合性が無いように思えるかもしれませんがこれは更新タイミングの違いによって起こりうることです。

また、コンデンスの直前にVisualizerの更新が終わってしまったら次回の更新はまた24時間後になるので、その端末については最大で48時間近く更新されない事になります。

このようなタイムラグの問題を避けるため、SysTrackのPOCでは構築時にVisualizer のデータは急いで確認せず、3-4日経ってから正常に取得できているかを確認して頂き、集計データが落ち着く14日程度経ってからデータの確認を一緒に行わせて頂いています。

SysTrack はこのような仕組みのため常時データを上げるような想定をしておらず、アップロード時にSysTrack サーバーが落ちていてもあまり気にしません。

ローカルにある一時ファイルはそのままにしてアップロード処理を諦め、次回のコンデンス処理時にまとめてアップロードされます。

非永続デスクトップ環境についての補足事項

「アップロードするデータを一時フォルダに保存する」と聞くと、インスタントクローン/リンククローンやMCS/PVSなど非永続デスクトップ環境の問題をよく目にしている方は心配に思うかもしれません。

アップロードされないままログオフしたらディスクがリフレッシュされて永遠にアップロードされない事が場合によっては起きるかもしれないためです。

このような問題は起こりうるので、非永続デスクトップ環境では、ログオフ時に強制的にCondenseを行うように設定しておきます。

Policies And Settings > Condensing Settings > Force Condense on Logoff: True

更新間隔を変えたい場合

System Viewの更新間隔などは変更できませんが、いくつかの更新間隔は変更してより短い間隔で更新を行うようにすることが出来ます。

POCや比較的小規模な環境ではサーバーの負荷が上がっても更新頻度が上がった方が便利なことがあるので必要に応じて変更を検討してみてください。

1. Visualizerの更新間隔の変更(マスター側)

Deploy Tool で Configuration > Global Configuration Items を選択し、以下のメニューを確認します。

 Visualizers > Update > Interval (Hours): 24 (デフォルト)

上記の値を24からより小さな値に変更します。
8時間の業務中に一度は更新されるようにしたいのであれば4-8程度の値にすることを検討します。

2. コンデンスの間隔の変更(エージェント構成)

エージェント構成から、以下の項目を変更します。

Policies And Settings > Condense Settings > Condensing Interval : 24

上記の値を24からより小さな値に変更します。
8時間の業務中に一度は更新されるようにしたいのであれば4-8程度の値にすることを検討します。

※ インベントリの更新間隔は多数の設定項目があるためここでは紹介しません。
興味がある方は Policies And Settings の Inventory Management 配下の「xxx Interval」のような項目を確認してみてください。

参考

KBA: Learn about the Initial Population of the Datasets for the Visualizers