ユーザーからの「何か遅い」その原因を10分で特定するための
仕組みと手順

システム利用者から寄せられる「何か遅い」という声。それは管理者が耳をふさぎたくなるクレーム第一位だろう。一人のユーザーが言っているなら時間が解決してくれるのを待つという選択をとる管理者もいるのではないだろうか。しかし、その声が多くなるとそれでは済まされない。社内にいる従業員からの声であれば会社の生産性が低下していることになる。ECサイトのユーザーであれば即売上に影響する。ここでは、「簡単」で「安価」な仕組みを利用して遅延の原因を特定し解決するまでのケーススタディに加え、原因を特定するために必要な条件とソリューションを紹介する。

10分で遅延の原因を特定し
一時対応する

「ブラウザのページ表示が非常に遅くて支店の社員がみな困っている。至急直してほしい。」
大阪の拠点にいる社員からそう連絡が入った。難易度の高い要求だと思いつつ時計を確認する。

簡単なヒアリングをしてから、Webブラウザで監視システムの管理画面を覗く。日本地図上に東京の本社とデータセンター、大阪を含む複数の拠点に設置された主要なサーバーやネットワーク機器がアイコンで表示され、ネットワーク構成のコアとなる部分が可視化されている(図1)。

見てすぐに気づいたのが大阪の拠点とデータセンターをつなぐ回線が赤くなっている点だ。平常時は緑。連絡の内容と合わせ、明らかにここに問題が潜んでいそうだ。次にその赤い回線がつながっている大阪拠点側のルーターの状況を確認してみる。

ルーターのアイコンをクリックすると監視システムがSNMPで収集した情報が可視化されており、そのルーターのIPアドレスなどの機器の基本情報、CPU使用率や温度など機器の状態が一目で把握できる。ルーターのポート毎のイメージもあり、アクティブなポートも一目瞭然だ。これによるとこのルーター自体は問題なさそうだ(図2)。ひとつ気になる情報があるとするなら、コンフィグが3点修正されているという表示があることくらいだ。念のためコンフィグも確認すると最近SNMPが有効化されているようだったが、今回の問題とは関係なさそうだと判断した。

ここで一度、日本地図の構成図に戻り、今度は赤色の回線をクリック。するとインタフェースの情報が可視化される。監視システムがSNMPで取得したルーターを通過するinとoutのトラフィック量が時系列でグラフになっている。昨日の夜からそのトラフィック量が100%に張り付いている(図3)。ここに原因が潜んでいそうだ。

ここまでの確認でルーターには問題がないこと、そして「いつ」から「どこ」のインタフェースの帯域が逼迫していたのかはわかった。つまり、この障害による影響範囲はわかった。連絡があった通り、大阪拠点の全社員の業務に影響が出ているのは間違いなさそうだ。しかし、これだけでは原因の特定までには至っていない。次に知りたいのが、トラフィック量が100%に張り付いているのは「なぜ」かだ。

画面を下に少しスクロールする。そこにはトラフィックのアプリケーション毎の内訳グラフが表示されている。これはSNMPではなくxFLowを可視化したグラフだ。httpやhttps、ssh、microsoft-ds、snmpといった名称でアプリケーション毎にどれくらいのトラフィック量が占有しているか把握できる。昨日の夜から帯域を圧迫しているのはSNMPの通信だった(図4)。さらに、表のトップに表示されている「snmp」というアプリケーション名をクリックし、送信元IPと宛先IPの一覧を確認する。見ると送信元IPはデータセンターにある「xxx.xxx.xxx.01」で、宛先IPは大阪拠点に25件あるIPだった。なぜかデータセンター内の1つのIPアドレスから大阪拠点内の複数のIPアドレスにSNMPの通信が大量に流れている。

次に監視システムの検索機能でこのIPアドレス「xxx.xxx.xxx.01」を検索してみる。するとデータセンターにある「monitoring-test」という名前のついた仮想サーバーであることがわかった。このサーバー名でなんとなく察しがついてきた。検索結果のサーバー名をクリックすると今度はそのサーバーの状態など基本情報を示した画面が表示される。画面の左下のメモ欄を見ると部下の連絡先番号に合わせてこのサーバーを立てた目的が記されていた。「監視テスト中」。

どうやら自身のスキル向上を目的に試験的に監視システム構築を試みたようだ。ルーターのSNMPを有効化したのも彼か。そのやる気は買おう。しかし、上司に相談もなく実施するのは問題だ。

それはさておき、大阪拠点の社員は今も業務に支障が出て困っている。一刻も早く復旧させなくては。あいにく部下は、今日は終日研修だ。ここはスピードを重視し監視システムからTelnetでルーターの設定を変更する。ACLの設定を変更し、問題のサーバーから拠点に向けた通信を遮断することにした。

大阪拠点に連絡。通信速度が改善されていることが確認できた。
ふう。
時計を確認する。

連絡を受けてから10分くらいか。上等だ。

 以上は、ゾーホージャパン ManageEngine & WebNMS事業部 技術部の磯部太佑氏が自社主催のセミナーで講演する内容の一部だ。10分で障害をクリアできたという話だが、読者の環境で同じ事態になったらどれくらいの時間がかかるだろうか?

システム遅延の原因を特定できない理由