【IIS7】 運用しやすいサーバーへ - 新トレース機能

個人的なお話をすると私はマイクロソフトの企業向けの製品サポート契約（プレミアサポート）を結んでいただいているお客様向けの担当者を3年ほどやっていた経験があります。その後 マネージャー（課長クラス）もやった訳ですが、まあ そんなことは置いておいて、今回は何を言いたいかというとこういうことです。マイクロソフトのアプリケーションプラットフォームは内部で問題が発生した際に高スキルの開発者やマイクロソフト内で解析ができる人にとってはデバッギングレベルのツールがいくつかあって辿り着きたいところに辿りつけるんですが、初見で何が起きているかをとりあえず知りたい運用現場ではこれでは厳しいと思います。これはマイクロソフトの開発陣も理解しており、製品開発のデザインにこの辺りをなんとかしようと Longhorn Server に向けては色々と考えて実装に向かってます。で、話をタイトル通りに戻すと IIS7 にもこの発想で Failed Request Tracing という機能がつきます。

何ができるかというと 例えばCPUが100%になっているサーバーがあると警告が上がってサーバールーム、あるいは監視できる端末のところに行ったとします。今までであれば動けばタスクマネージャーやパフォーマンスモニタを見てプロセスを特定する方向で見ていくでしょう。まあ IIS7 でもここは同じかもしれません。違うのは、IIS7で実装される新しい管理ツール内でトレースを有効にし、アプリケーションプール単位で消費しているCPUやメモリーの状態を確認でき、さらに最新でどのURLをワーカープロセスが処理しているかを見ることができます。これは大きいです。いきなりアプリに近いところでアタリがつきますので。ただ現在のビジネスアプリは部品化を進めている関係上、そのURLをアクセスするのが色々なルートからだったりするでしょう。これにはFailed Request Tracing をオンにしてもっと深いトレースをとります。

Failed Request Tracing はWebが返す例えば404あるいは500系のエラーなどでフィルターしてトレースを出力できます。そしてリクエストがされてからパイプライン上に乗ってくるすべてのリクエストをトレースできます。これは何を意味するかというと一連の処理の流れが全部記録することができるということであり、アプリ的にどのように流れたかを追うのではなくて IIS が実際に処理した内容を順に見れるようになるということです。無論、多くをトレースすることによるディスク消費やパフォーマンスの低下を考慮して環境に最適なフィルターを調整しなければいけませんが、今までのように再現を繰り返して問題を起こすより前にもっと情報が取得できるようになります。

「メモリダンプ、あるいは当該プロセスのダンプを取得いただけないでしょうか？」というお願いを何度したか記憶できないくらい回数が多いですが、IIS7やLonghornの監視機能を使えばお客様がそもそもマイクロソフトに問合せる前にもっとサーバーの状態がわかるという言うみんなハッピーな状態がようやく実現できそうな感触で私は個人的にすごくうれしいです。ただ、実践の現場はそれほど甘くないことも知っていますので問題解析のフローを考える際にこんなのがあるとか言ってたなと覚えていただけていれば幸せです。

Comments

• Anonymous
  January 01, 2003
  TechNet Blogs