仮想化された環境では，仮想サーバーに対する物理リソースの配分が動的に変化する。これはリソースの最適化を目指すものであり，それ自体に問題はない。ただ，このリソース配分のバランスが崩れると，性能劣化を招いたり，障害を起こしたりする。このときサイロ型の管理をしていると，こうした障害の原因がどのコンポーネントに起因しているのかを特定するのに時間がかかり，結果としてユーザーからのクレームを増幅させてしまう。これが前回述べた「見えざる課題」である。
例えばユーザーが仮想化されたインフラのWebサーバーにアクセスできない場合があったり，Webアプリケーションの使用中に応答性能が落ち込むといった障害が発生したとしよう。データ・センター側のヘルプデスク担当者は，ユーザーからのクレームを受け付け，想定される障害原因の担当部門にエスカレーションする。
ところがサイロ型モニタリングが主流になっている現状では，サービス・インフラを構成する部門ごとにエキスパートが組織されているケースが多く，返ってくる回答は「Webサーバーのプロセスは正常に動いています」とか，「ネットワーク機器は正常です」といった内容であることが少なくない。こうなると，ヘルプデスク担当者の障害対応がループしてしまう。こうした例は色々なところから聞こえてくる。
特に最近のITインフラは従来のようなクライアント・サーバー型ではなく，負荷分散装置，Webサーバー，アプリケーション・サーバー，データベース，それぞれを結ぶネットワークという具合に，何層にもわたるマルチティア型の構造に変わりつつある。マルチティア型のシステムでは，サービス・デリバリに関与するすべてのアプリケーション，仮想サーバー，ネットワークが影響を及ぼし合う。
こうした複数のサーバーが，仮想化機能を搭載した少数の物理サーバー上で入り交じって稼働する環境になると，障害原因特定のハードルは高くなる。ユーザーから「Webアクセスの応答性能が落ちた」と言われた場合にすぐに原因を突き止めるには，エンド・ツー・エンドでの応答性能のモニタリングと同時に，仮想サーバー，アプリケーション，ネットワークのそれぞれの応答性能のモニタリング，そしてそれぞれの相関関係を分析できる障害原因分析（root-cause diagnosis）の仕組みが必要である（図1）。
仮想化環境の管理用には，ベンダーが提供する専用ツールがあると考えるかもしれない。確かに各社が提供している。ただ，これもサイロ型モニタリングの域を出ないのが実情だ。仮想化製品ベンダーが提供する管理ツールの多くでは，モニタリングする項目は，1台の物理サーバー上でいくつの仮想サーバーが動いているか，物理サーバーのCPU/メモリーがそれぞれの仮想サーバーにどれだけ割り当てられているか，仮想サーバーにどれだけのディスク・パーティション・スペースが割り当てられているかといったもの。いわば仮想サーバー自体のモニタリングである。
