# Detailed Diagnosis in Enterprise Networks > [!abstract] 概要 > 小規模企業ネットワークのトラブルチケットを調査し、その運用者には詳細な障害診断が必要であると結論づける。診断システムは、性能に関する問題のような一般的な障害だけでなく、エラーコードのようなアプリケーション固有の障害も診断できなければならない。また、原因をプロセスやファイアウォール設定エントリのような細粒度で特定する必要がある。著者らは、最新のオペレーティングシステムとアプリケーションが公開する豊富な情報を利用して詳細診断を実現するシステム NetMedic を構築した。NetMedic は、プロセスのような細粒度のネットワークコンポーネントの挙動と相互作用をより忠実に捉える推論問題として、詳細診断を定式化する。この問題を解く主な課題は、あるコンポーネントがいつ別のコンポーネントに影響を与えている可能性があるかを推定することである。提案手法は、過去における2コンポーネントの共同挙動を利用して、それらが現在相互に影響している可能性を推定する直感的な技法に基づく。著者らは、ライブ環境に障害を注入する実験によって、実装したプロトタイプが障害診断に有効であることを示す。障害コンポーネントは80%のケースで最も可能性の高い原因として正しく特定され、ほぼすべてのケースで上位5件の原因リストに入った。 ## 論文情報 - タイトル: Detailed Diagnosis in Enterprise Networks - 著者: Srikanth Kandula, Ratul Mahajan, Patrick Verkaik, Sharad Agarwal, Jitendra Padhye, Paramvir Bahl - 媒体: SIGCOMM 2009 - 発表年: 2009 ## 概要 NetMedicは、小規模企業ネットワークで頻発する、アプリケーション固有の症状と細粒度の原因を同時に扱う診断システムである。論文の出発点は、既存の診断システムが「マシンが故障している」ことまでは示せても、運用者が実際に修正すべきプロセス、設定、ネットワーク経路まで絞り込めないという問題である。さらに、既存手法の一部は性能・到達性などの一般的な症状に限定され、別の手法はアプリケーションの依存関係や故障モードを大量に手作業で記述する必要がある。 NetMedicは、オペレーティングシステムとアプリケーションが公開するカウンタや設定情報を、意味づけされたルールに変換せずに状態変数として収集する。ネットワークを、アプリケーションプロセス、ホストマシン、アプリケーション・マシン・ファイアウォールの設定、ネットワーク経路、通信相手集合を表す仮想コンポーネント `NbrSet` からなる依存グラフとして表現する。各コンポーネントは単一の健全性値ではなく、多数の変数からなる状態ベクトルを持つ。 診断時には、対象時刻に異常な状態を示すコンポーネントを出発点とし、過去に似た状態を示した時刻で隣接コンポーネントがどのように振る舞ったかを調べる。この条件付きの共同挙動から依存辺の影響度を推定し、影響度の高い非巡回経路と各コンポーネントの異常度を組み合わせて原因候補を順位付けする。重要なのは、個々の変数の意味やアプリケーション固有の因果規則をあらかじめ完全に知ることではなく、観測された状態変化を説明でき、かつ他の観測可能な変化では説明しにくいコンポーネントを原因候補として残す点である。 ## 問題設定 ### 運用ログから得られる要求 著者らは、小規模企業ネットワークの技術支援組織が保有するトラブルチケットを分析した。対象ネットワークは数台から数百台のコンピュータで構成され、ログは2008年2月の1か月間にわたる約45万件のケースを含む。各ケースは、運用者と支援担当者の会話や電子的なやり取りを中心とする自由記述であり、症状、影響範囲、判明していれば原因、正常時の状態、最近の変更を含む。外部支援を依頼したケースだけなので、運用者が自力で解決できた問題を代表しない。また、分類のために全体の0.1%を無作為抽出して人手で読み、不完全なケース、支援担当者間の内部連絡、パスワード忘れのような障害ではないケースを除いた。分析対象は148ケースであり、その半分だけを使った場合にも分類傾向は一貫した。 Table 1の10例は、アプリケーション固有のエラー、性能劣化、到達不能、設定変更、リソース過負荷、ソフトウェア・ドライバのバグ、計画作業の副作用を含む。例えば、IISの更新でASP.NETページだけがエラーコードを返す、無関係なプロセスが断続的にメモリを消費する、ルータのファイアウォール設定がHTTPSを遮断する、デフラグメンテーション後にリモートフォルダがアンマウントされる、クライアントのメールサーバ種別が上書きされる、といった事例である。マシン名だけを特定しても、運用者が必要とする修正対象は得られない。 Table 2の分類では、影響を受けた対象は個別アプリケーションが125件（84.5%）、マシン全体が23件（15.5%）であった。症状はアプリケーション固有の障害が88件（59.5%）、初期化失敗が19件（12.8%）、性能問題が15件（10.1%）、ハングまたはクラッシュが15件（10.1%）、到達不能が11件（7.4%）である。特定された原因は、アプリケーション以外の設定44件（29.7%）、アプリケーション設定28件（18.9%）、ソフトウェアバグ20件（13.5%）、ドライババグ10件（6.8%）、過負荷6件（4.1%）、ハードウェア障害3件（2.0%）、不明37件（25.0%）であった。設定の誤りの多くは運用者の単純な操作ミスではなく、更新やバグによる上書き、または意図した変更の副作用だった。 この調査から、診断システムには次の二つの性質が必要だと整理される。 - 詳細性: アプリケーション固有と一般的な問題の両方を検知し、プロセスが原因ならホストマシンではなくプロセスを、設定が原因ならアプリケーション全体ではなく誤った設定を提示すること。 - アプリケーション非依存性: 多数のアプリケーションの依存関係や故障モードを個別に埋め込まず、最小限のアプリケーション固有知識で動作すること。 ### 入力・出力と仮定 ネットワークは、コンポーネントを頂点、あるコンポーネントが別のコンポーネントへ直接影響しうる関係を有向辺で表す依存グラフとしてモデル化する。グラフには、同一マシン上のプロセス間や通信プロセス間の相互依存を表すサイクルも許す。各コンポーネントの時刻tの状態は、観測できる状態と観測できない状態に分かれる。NetMedicが利用できるのは前者だけであり、プロセスの内部変数のような不可視状態を直接推定しようとはしない。可視状態は、CPU使用率、メモリ使用量、I/O、応答時間、成功・失敗リクエスト数、エラーコードの割合など、コンポーネントごとに異なる複数の変数で表す。変数の意味は分析器には与えない。 診断入力は、診断対象となる1分間の時間ビンと、比較に使う過去の時間範囲である。過去の範囲は対象時刻に隣接している必要も連続している必要もないが、診断対象の障害に支配されていないことを仮定する。運用者が影響を受けたコンポーネントを指定することもでき、指定しない場合は現在異常な全コンポーネントを対象とする。出力は、影響を受けた各コンポーネントについて、それへ至る影響経路を持つ原因候補の順位付きリストである。診断対象の変化は悪化に限らず、改善を含む任意の状態変化でよい。状態変数については、小さな挙動変化が比較的小さな値の変化として現れ、大きな挙動変化が統計的に検出できるという仮定を置く。 既存モデルには三つの不足がある。第一に、コンポーネントを単一の健全性変数で表すため、例えば高負荷時だけ他プロセスへ影響するプロセスと、正常負荷時には影響しないプロセスを区別できない。第二に、故障コンポーネントは依存先を一定確率で傷つけるという単純な依存モデルであり、影響が現在状態に依存することを表せない。第三に、相互依存するコンポーネントの循環依存を扱えない。多変量状態を一変数ずつ別コンポーネントに分解する案も、変数間相互作用を増やし、数百の変数を持つ実コンポーネントの推論を複雑化するため採用しない。 ## 提案手法 ### 全体ワークフロー NetMedicの処理は、Figure 3に示される三段階からなる。 1. **コンポーネント状態の収集**: OSとアプリケーションが公開するカウンタ、通信、設定、プローブ結果を一定間隔で取得し、各コンポーネントの多変量状態として保存する。 2. **依存グラフの生成**: コンポーネント種別ごとのテンプレートから、プロセス、マシン、設定、通信相手集合、経路の直接依存辺を自動生成する。 3. **診断**: 対象時間ビンで異常度を計算し、履歴から辺の影響度を推定し、影響経路と異常度を用いて原因を順位付けする。 ### コンポーネントと状態ベクトル 現在の設計で扱うコンポーネントは、アプリケーションプロセス、マシン、アプリケーション・マシン・ファイアウォールの設定、ネットワーク経路である。マシンコンポーネントはハードウェアとOSをまとめて表す。さらに `NbrSet`（neighbor set）という仮想コンポーネントを導入する。これは、プロセスが通信する相手の集合をまとめたものであり、サーバ側ポートに基づく集約トラフィックや応答時間を状態に含める。冗長なDNSサーバの集合をクライアントから見た一つの依存先として扱ったり、複数クライアントのサーバへの集合的な影響を表したりできるため、個々の通信相手をすべて独立した依存先にするよりも適切な場合がある。 状態は1分間のビンに集約して周期的に取得する。ビンを大きくすれば収集オーバーヘッドは下がるが、短時間の障害を診断しにくくなる。Table 3のWebサーバ例では、一般変数としてプロセッサ時間、ユーザ時間、I/Oデータ量、スレッド数、ページフォルト、ページファイル量、ワーキングセットを、アプリケーション変数としてキャッシュされたファイル、接続試行数、送受信リクエスト数、Not Foundエラー数などを持つ。Table 4のコンポーネント別の例では、マシンがCPU・メモリ・ディスク・ネットワークI/O、プロセスが一般変数とアプリケーション固有変数、`NbrSet` が通信相手との入出力トラフィックと応答時間、経路が損失率と遅延、設定が関連するキー・バリュー対を持つ。 プロセスはプロセスIDではなく完全なコマンドラインで識別する。同じコマンドラインのプロセスは、マシン再起動やプロセス再起動をまたいで同じ機能コンポーネントとして扱う。プロセス状態は、資源消費や通信トラフィックのようなアプリケーション非依存の一般変数と、失敗リクエスト率や特定種別のリクエスト数のようなアプリケーション固有変数の和集合である。後者の意味を分析器が知らなくても、アプリケーションが現在の経験をカウンタとして公開していれば、アプリケーション固有の異常を診断できる。 ### 依存グラフの自動生成 コンポーネント種別ごとに、中央のコンポーネントがどの種別から直接影響を受けるかを記したテンプレートを用いる（Figure 4）。マシンは、その上で動くプロセスとマシン設定に依存する。アプリケーションプロセスは、アプリケーション設定、`NbrSet`、ホストマシン、マシン設定に依存する。同一マシン上のプロセス間の資源共有は、直接のテンプレート辺にはせず、プロセスからマシンを経由する間接依存で表す。ただし、IPパケットを伴わない共有メモリなどのプロセス間相互作用は現行実装では無視する。 `NbrSet` は、通信しているプロセス、ローカル・リモートのファイアウォール設定、ネットワーク経路に依存する。2台のマシン間の経路は、その経路へトラフィックを注入するすべてのマシンと、監視対象ネットワーク外から来るその他のトラフィックに依存する。設定コンポーネントには現時点で他の依存先を置かないため、設定変化だけで影響を説明できる場合は設定コンポーネントを原因として提示するが、何が設定を書き換えたかまでは特定しない。結果として、例えば「プロセス1 → プロセス2の `NbrSet` → プロセス2 → プロセス1」のような循環を含む複雑なグラフが得られる。 ### 履歴による影響度推定 依存辺S→Dの影響度を、辺の始点Sの現在状態と似た過去時刻に、終点Dも現在状態に似ていたかで推定する。現在の状態をS_now、D_nowとすると、直感的には \[ P(D=D_{now}\mid S=S_{now}) \] を、複雑な確率モデルを学習せずにオンデマンドで近似する。ただし条件付き確率は一般には因果性を意味しないため、著者らはこの値が実際の診断に十分有効な頻度で影響関係を反映することを経験的に利用している。 SとDがどちらか一方でも正常なら、SがDへ影響している可能性は低いとして辺重みを0.1にする。経路重みで辺重みを乗算するため、ゼロではなく0.1を使う。双方が異常なら、共存している履歴をK個の同じ大きさのチャンクに分け、各チャンクからSの状態が (S_{now}) に最も似る時刻 (t_k) を一つ選ぶ。その時刻におけるDの状態と (D_{now}) の類似度を、Sの類似度で重み付けして平均する。 \[ E(S\rightarrow D)= \frac{\sum_{k=1}^{K}(1-|D_{t_k}-D_{now}|)w_k} {\sum_{k=1}^{K}w_k},\qquad w_k=\begin{cases}1-|S_{t_k}-S_{now}|&(|S_{t_k}-S_{now}|\leq\delta)\\0&\text{otherwise}\end{cases} \] 実験ではδ=1/3、K=min(10,履歴の時間ビン数)とする。履歴を複数のチャンクに分けることで、近接した依存時刻だけに偏らず、異なる時間窓から共同挙動を集める。利用可能な履歴がない、またはSに似た状態が見つからない場合は、原因候補を早期に除外しないため、辺重みを0.8とする。 状態差分は、各変数の観測範囲で正規化した絶対差の平均である。L個の変数について、変数iの差を \[ d_i=\frac{|v^i_t-v^i_{now}|}{v^i_{max}-v^i_{min}},\qquad |V_t-V_{now}|=\frac{\sum_i d_i}{L} \] と計算する。これにより、値域の大きな変数が単独で差分を支配することを防ぐ。設定コンポーネントでは、全キー・バリューが同じなら差分0、一つでも値が変われば差分1とする。設定の単一変更でも機能的な意味を持ちうるためである。 ### 状態差分を頑健にする四つの拡張 単純な状態差分は、変数数が多く、現在の障害に関係しない変数や冗長な変数が多数あると、重要な変化を薄める。そこでNetMedicは、変数の意味を手作業で与えずに次の拡張を適用する。 - 異常度による重み付け: 各変数を等重みで扱わず、現在の診断対象に対する変数の異常度を重みとする。CPU関連の影響を診断する場合、CPUに関係する変数が異常になっているため、差分への寄与が大きくなる。 - 冗長変数の除外: コンポーネント内の変数対のPearson相関を計算し、すべての対の相関係数が0.8を超える変数のクリークから代表変数を一つだけ選ぶ。使用済みメモリ、空きメモリをバイト・キロバイト・メガバイトで重複して公開するようなケースで、一つの側面が過剰に数えられることを防ぐ。 - 隣接先との相互作用に無関係な変数の除外: あるコンポーネントの変数が隣接先のいずれかの変数と相関係数0.8を超える場合だけ、その隣接先との辺の差分計算に残す。例えば、マシンからアプリケーションプロセスへの影響を調べるとき、別プロセスから受信したエラーコードのように、その辺の相互作用を表さない変数を除く。 - 集約関係の補正: マシンのCPU使用率のようにプロセス値の合計で表される変数、サーバへの受信トラフィックのようにクライアント値の合計で表される変数を扱う。共通の変数名を持つプロセス変数を足し合わせた仮想変数を作り、マシン変数との相関が0.9を超えれば集約関係とみなす。マシン値を仮想変数で置き換え、マシンから各プロセスへの辺を計算する際には当該プロセスの寄与を差し引く。これにより、新規に現れた暴走プロセスの影響をマシン状態に埋め込まず、そのプロセス自体へ原因を寄せられる。また、過去に似たプロセス状態がない場合でも、プロセスが集約値に占める最大割合を辺重みとして使い、小さな新規プロセスを根拠なく原因にしない。 拡張後の非設定コンポーネントの状態差分は、変数差分に異常度と採用指標を掛けた重み付き平均として計算する。これらの拡張は、個々のカウンタの意味を列挙する知識ベースではなく、異常度・相関・集約性という観測可能な統計的性質から、診断に必要な変数だけを選ぶ。 ### 原因候補の順位付け Figure 5のようなグラフで、影響を受けたコンポーネントをE、候補をCとする。候補CからEまでの各非巡回経路の辺重みの幾何平均を経路重みとし、CからEへの影響I(C→E)はその最大値とする。候補自身が対象なら影響度は1である。さらにCがネットワーク内の異常コンポーネントへ及ぼす影響を、相手の異常度で重み付けして合計した全体影響S(C)を計算する。 \[ \mathrm{Rank}(C\rightarrow E)\propto \left(I(C\rightarrow E)\,S(C)\right)^{-1} \] したがって、対象へ高い影響度で到達し、同時に他の異常コンポーネントにも影響している候補ほど上位になる。Figure 5の例では、B、C、DはいずれもEへ高影響の経路を持つが、CはAにも影響しているため、全体影響の項によってBやDより高く評価される。辺重みの一部が過大評価されても、複数の異常を一貫して説明する候補を優先する設計である。 Figure 1〜Figure 12、Table 1〜Table 4を本文で参照する。以下は原本から抽出した図表画像であり、図表専用の知識節ではなく、提案手法・実験の根拠として配置する。 **Figure 1** ![[wiki/sources/_attachments/Detailed-Diagnosis-in-Enterprise-Networks/fig-01-crop.png]] **Figure 2** ![[wiki/sources/_attachments/Detailed-Diagnosis-in-Enterprise-Networks/fig-02-crop.png]] **Figure 3 / Table 4** ![[wiki/sources/_attachments/Detailed-Diagnosis-in-Enterprise-Networks/fig-03-crop.png]] ![[wiki/sources/_attachments/Detailed-Diagnosis-in-Enterprise-Networks/table-04-crop.png]] **Figure 4** ![[wiki/sources/_attachments/Detailed-Diagnosis-in-Enterprise-Networks/fig-04-crop.png]] **Figure 5 / Figure 6** ![[wiki/sources/_attachments/Detailed-Diagnosis-in-Enterprise-Networks/fig-05-crop.png]] ![[wiki/sources/_attachments/Detailed-Diagnosis-in-Enterprise-Networks/fig-06-crop.png]] **Figure 7** ![[wiki/sources/_attachments/Detailed-Diagnosis-in-Enterprise-Networks/fig-07-crop.png]] **Figure 8 / Figure 9** ![[wiki/sources/_attachments/Detailed-Diagnosis-in-Enterprise-Networks/fig-08-crop.png]] ![[wiki/sources/_attachments/Detailed-Diagnosis-in-Enterprise-Networks/fig-09-crop.png]] **Figure 10 / Figure 11 / Figure 12** ![[wiki/sources/_attachments/Detailed-Diagnosis-in-Enterprise-Networks/fig-10-crop.png]] ![[wiki/sources/_attachments/Detailed-Diagnosis-in-Enterprise-Networks/fig-11-crop.png]] ![[wiki/sources/_attachments/Detailed-Diagnosis-in-Enterprise-Networks/fig-12-crop.png]] ## 新規性 NetMedicの新規性は、細粒度の診断、豊富な多変量状態、状態依存の影響関係、アプリケーション非依存の分析を一つの推論問題に組み込んだ点にある。 - 既存の大規模ネットワーク診断がマシン単位の単一健全性値へ抽象化するのに対し、プロセス、設定エントリ、`NbrSet`、経路を別コンポーネントとして保持する。 - 「障害コンポーネントは依存先を常に傷つける」という固定規則を置かず、現在状態に似た過去の共同挙動から、辺ごとに影響度を推定する。 - 変数名やアプリケーションプロトコルの意味を診断ロジックへ埋め込まず、異常度、相関、集約関係から診断に有用な変数を自動的に選ぶ。 - 条件付き確率を因果性の厳密な証明として扱うのではなく、観測履歴から得た影響度を依存グラフ上の順位付けに使うことで、未知のアプリケーション固有障害まで同じ枠組みで扱う。 ## 実験設定 ### 評価環境 NetMedicはWindows上に実装され、データ収集部と分析部からなる。主なデータ源はWindows Performance Counter frameworkであり、OSとアプリケーションが公開する名前付きカウンタを読み取る。累積値を表すカウンタは連続読み取りの差分から現在の期間の挙動へ戻す。Performance Counterが通信プロセスを直接知らせないため、ソケットのread/writeを監視する独自ユーティリティを使い、呼び出しプロセス、両端のIPアドレスとポート、通信量、read/write間隔から応答時間を得る。経路の損失率と遅延は、通信相手への周期プローブで測り、監視範囲外へ出る経路はゲートウェイまでを測定する。マシン、ファイアウォール、アプリケーションの設定はWindowsレジストリとファイルから収集し、起動時に読み込み、以後の変更をコールバックで記録する。アプリケーション設定の所在は現状ではNetMedicへの入力である。 データ収集による平均CPU使用率は1%未満、マシンあたりの送信データ量は毎秒250バイト未満である。著者らは、この実装が現状のままでも100台規模のネットワークへ拡張可能だと見積もる。 評価には二つの環境を用いる。 - ライブ環境: 組織内の10台の利用中クライアントと1台のサーバからなる。サーバにはExchange、IIS、MS-SQLを同居させ、ボランティアが使うクライアントには日中・夜間の負荷変動や自然なノイズを残した。実サーバを計装できなかったため、自作クライアントと自作サーバ上のアプリケーションで、実際のクライアントに似た成功・失敗リクエスト数、リクエスト種別数などを出力した。 - 制御環境: 専用の3台のクライアントと1台のサーバからなる。負荷とアプリケーションを制御できるが、現実的な環境ではないため、原則として結果はライブ環境を中心に報告する。 ### 障害注入と比較手法 Table 1に対応する10種類の障害を、可能な限り報告事例と同じ症状・アプリケーションにして注入した。例えば、IISを設定変更してASP.NETページだけを提供できなくする、メールクライアントがマウント済みドライブの情報に依存するようにする、といった再現を行った。各単一障害は少なくとも5回、時刻や負荷条件を変えて注入し、収集と注入は累積で約1か月間ほぼ連続して実施した。診断には障害を含む1分間の時間窓を与え、影響を受けたコンポーネントを明示せず、ネットワーク全体の異常な側面を自動的に診断した。特に断らない限り履歴は1時間で、ライブ環境では履歴中に別の注入障害や自然発生障害が含まれうる。 比較対象の `Coarse` は、SherlockやSCOREのような既存の依存グラフ型手法を念頭に置いた粗粒度ベースラインである。グラフ自体はNetMedicと共有するが、各コンポーネントを正常・異常の一変数で表し、両端が異常な隣接コンポーネント間の影響確率を0.9、それ以外を0.1とする。原因候補の順位付け方法はNetMedicと同じにして、比較対象が異なるのは隣接コンポーネント間の影響推定と状態表現だけになるようにした。拡張の評価では、拡張なしの `Basic`、変数関係を人手でコードした `HandPicked`、異常度重み付けと自動的な変数関係推定を含むNetMedicを比較する。 ### 評価指標 評価値は、各注入障害の真の原因に割り当てられた順位である。1位が最良である。1つの障害が複数のクライアントやアプリケーションへ影響する場合は、各予測効果に対する真の原因の順位を計算し、その中央値を典型的な効果を診断したときの運用者体験、最大値を最悪の効果に対する体験として報告する。候補が約1000個あるライブ環境では、上位数位に真の原因を置くだけでも、運用者が調べる可能性のある原因を大きく減らせる。 ## 実験結果 ### グラフ規模と状態量 ライブ環境の依存グラフは、11台のマシン上で約1000コンポーネント、約3600辺である。各マシンには平均約70プロセスがあり、辺の大部分はマシンとその上のプロセスのような同一マシン内の依存である。異なるマシンを結ぶ辺は少なく、グラフはマシンごとのクラスタに分かれる。このため、マシン数に対するグラフ規模は概ね線形に増加する。プロセスは平均35状態変数を持ち、その約半分が資源使用量などの一般変数、残りがアプリケーション固有変数である。IISサーバは128個のアプリケーション固有変数を公開し、マシンも100個を超える状態変数を持つ。 ### 単一障害の診断精度 Figure 7(a)では、ライブ環境の注入障害について、NetMedicは80%の障害で真の原因の中央値順位を1とした。1件を除くすべてのケースで中央値順位は5以下であり、最大順位も中央値から大きく離れないケースが多かった。障害コンポーネントは、ほぼすべてのケースで上位5件に入った。アプリケーション固有の設定異常、到達不能、リソース過負荷、ネットワーク遅延を、同一の細粒度グラフと履歴推論で扱えている。 Coarseでは、真の原因を1位に置けたケースは15%未満であり、60%以上のケースで中央値順位が10を超えた。Figure 7(b)の制御環境でもNetMedicは有効だった。一方、Coarseは環境が小さくノイズも少ないため改善し、最悪20%のケースの中央値順位は8以上であったのに対し、ライブ環境では35以上であった。細粒度状態と状態依存の辺重みが、利用中デスクトップに伴う同時多発的な異常を処理するうえで重要である。 ### なぜCoarseを上回るか Figure 8(a)では、各障害の時間帯に異常となるコンポーネントの割合が20〜40%と高い。Coarseは異常かどうかだけで辺を評価するため、同時に異常なだけの無関係なコンポーネントまで高影響の辺で接続する。NetMedicは各コンポーネントの多変量状態と状態依存性を使い、両端が異常でも実際には影響していない辺を低く評価できる。 Figure 8(b)では、影響確率が0.75を超える高重み辺の割合がCoarseで35〜45%、NetMedicで10〜15%となり、NetMedicは約3分の1まで減らした。高重み辺が少なくなることで、異常効果へ強く接続される偽の原因候補が減り、真の原因の順位も改善する。単に異常判定の閾値を上げたり、異常変数を複数要求したりする方法では、真の原因や原因から効果へ至る中間コンポーネントを正常と誤判定して候補から除く危険がある。 ### 拡張の効果 Figure 9(a)で、拡張なしのBasicは真の原因を1位に置く頻度が44%であり、Coarseの14%よりは良いが、最悪20%のケースではCoarseより高い順位になるほど不安定だった。異常度による重み付けと変数関係の自動推定を含むNetMedicは、真の原因を1位に置く頻度を80%まで高め、障害の半分について順位を大きく改善した。性能障害は多くのコンポーネントへ副作用を及ぼすため、変数を等重みにするBasicより拡張の恩恵が大きい。 人手で診断に関係する変数を指定したHandPickedの性能はNetMedicに近かった。つまり、変数の意味をアプリケーションごとにハードコードしなくても、異常度と変数関係の推定から同程度の情報を抽出できた。Figure 9(b)では、異常度拡張だけでもBasicより80パーセンタイルと95パーセンタイルの順位を改善し、変数関係を加えたNetMedicでさらに改善することが示される。 ### 複数同時障害 10種類の単一障害から2つを選ぶ45組のうち、同じアプリケーションプロセスへ影響するため干渉する9組を除き、36組の非干渉な障害対を注入した。Figure 10では、NetMedicは80%以上の効果で真の原因の中央値順位を1とした。単一障害より最大順位は悪化するが、中央値の劣化はなく、平均的には効果と原因を対応づけられることを示した。Coarseでは中央値順位が1となるのは15%だけであった。Coarseの20〜60パーセント点が単一障害時よりよく見える部分は、複数障害実験にCoarseが比較的扱いやすい障害種別が多かったためであり、手法自体が複数障害に強いことを意味しない。 ### 履歴長と自然発生異常 Figure 11は5、30、60、90分の履歴を比較する。30分または90分は、従来の60分と同程度の性能であった。5分では10%の障害で中央値順位が20を超えたため、ほとんどの障害には30分程度の履歴で足りると結論づける。履歴は完全に正常である必要はなく、実験でも別の障害を含む履歴を利用した。日中と夜間のように、より動的な時間帯の履歴を使うと偶発的な接続を除きやすいという予備的な証拠もあるが、最適な履歴の性質は今後の課題として残る。 自然発生異常の評価では、5時間の監視中に自作クライアントを稼働させず、異常プロセスを含む10個の1分間区間を選び、30分の履歴で診断した。NetMedicは75%のケースで、異常なプロセス自身を原因とした。Coarseでは5%だけであった。NetMedicが異常な被影響プロセスを高順位に置いたケースを人手で調べると、ほぼすべてでウイルススキャンまたは同期ユーティリティが上位原因であり、短時間に資源を消費する実際の原因を特定していた。 ## 考察 NetMedicが運用者に提供する価値は、症状からマシンを探す作業を、プロセス・設定・経路へ向けた順位付き調査へ変える点にある。例えば同一サーバへの応答時間が高い二つのクライアントのうち、一方のクライアントが過剰なリクエストを送っていれば、そのクライアントからサーバを経由して被害側クライアントへ至る高影響経路を形成できる。被害側クライアントのホストが正常なら、そのホストからの影響を低くして、無関係な同時異常を除外できる。 本手法の中心である履歴利用は、アプリケーションの意味論を知らずに「現在のSの状態が、過去にどのようなDの状態と共起したか」を調べることで、単なる同時異常と影響の可能性を分ける。全辺の重みを完全に推定する必要はなく、真の原因から効果へ至る経路上の十分な辺を低く、または高く正しく評価できれば順位付けに有効である。実験では、細粒度状態を保ったことで、ノイズの多いライブ環境でもCoarseほど偽の高重み辺が増えなかった。 ただし、この重みは厳密な因果効果ではない。論文自身も条件付き確率が一般に因果性を測るわけではないことを認め、実用上十分に影響関係を反映するという仮定を置いている。未観測の状態、交絡する同時変更、誤った依存テンプレートがある場合には、履歴上の共起を影響と誤認しうる。設定変更の原因となった更新プログラムやユーザ操作を追跡しないため、設定コンポーネントを原因として示せても、設定を書き換えた主体までは分からない。 大規模化では二つの課題がある。第一は、異常度と辺重みを大きな依存グラフで計算することだが、コンポーネントごと・辺ごとに独立して計算でき、監視対象マシンへ分散できる。同一マシン内の辺が大半で、個別辺の計算には高速な相関計算法も利用できる。第二は、データ収集・保存・類似履歴検索であり、軽量収集、圧縮、時系列類似検索の既存技術を組み合わせる必要がある。現行実装はWindowsのPerformance Counter、レジストリ、ソケット監視に依存し、Linux版は将来課題である。 ## 強み / 弱点・課題 ### 強み - トラブルチケットで多数を占めたアプリケーション固有のエラー、初期化失敗、性能問題、到達不能を同じモデルで扱える。 - プロセス、設定、通信相手集合、経路まで原因候補を細粒度に保ち、マシンが既に分かっている運用者にも修正対象を提示できる。 - アプリケーションの変数意味論を診断器へ埋め込まず、OS・アプリケーションが公開するカウンタと履歴から関係を推定できる。 - 多変量状態、異常度、冗長性、隣接先との相関、集約関係を使い、ライブ環境のように多数のコンポーネントが同時に異常となる状況で偽の影響辺を減らせる。 - 単一障害だけでなく、非干渉な同時障害対と、クライアントを動かさない自然発生の資源消費プロセスにも有効性を示した。 ### 弱点・課題 - 入力する依存グラフが実際の依存関係を欠く場合、真の原因から効果への経路を作れない。現行テンプレートでは共有メモリなどIP通信を伴わないプロセス間相互作用を扱わない。 - 条件付き確率に基づく辺重みは因果性の証明ではなく、履歴が現在と異なる場合や、同時に変化した未観測要因がある場合に誤る可能性がある。 - 現在と似た状態が履歴にないときは辺に0.8というデフォルト重みを与えるため、未知の状態や短い履歴では候補の絞り込みが弱い。実験でも5分履歴は30分以上より悪化した。 - 性能障害は多くのコンポーネントへ副作用を及ぼすため、設定障害よりも多くの偽異常を生み、真の原因の順位が下がる場合がある。複数同時障害でも最悪順位は劣化した。 - アプリケーション設定の所在は手動入力であり、設定を変更したプログラムや運用者までは追跡しない。将来はパッケージ管理情報やアプリケーションの読み出し追跡から自動推定する構想である。 - 評価は実サーバを計装できない制約のもとで、主に障害注入に依存する。10種類の障害を各5回以上試したが、実運用の全障害分布を代表するものではない。Linuxへの移植と大規模ネットワークでの収集・保存・検索が今後の課題である。 ## 出典 - [[.raw/papers/Detailed-Diagnosis-in-Enterprise-Networks.pdf]] - [[.raw/papers/Detailed-Diagnosis-in-Enterprise-Networks.txt]]