平成17年度テクニカルエンジニア（ネットワーク）午後Ⅱ 問Ⅱ設問3解答と解説
目次
解答
(1)障害事例１ ディスク使用率
障害事例２ パケットエラー発生率
障害事例３ CPU使用率 または メモリ使用率
(2)起動時のメッセージから正常にサービスが利用できることを確認するため（33字）
解説
(1)
K君は業務システムやグループウェアのサーバに対してはping監視を実施していましたが、それだけでは十分ではありません。なぜなら、pingの応答が正常に返ってきたとしても実際のアプリケーションレベルでは使用できない不具合が起こりえるからです。実際に障害事例の１～３のケースでは、アプリケーションとしては使えない状態になっていますが、ping監視は正常に応答が返ってきていたと考えられます。
では監視ツールによって追加で監視すべき項目は何なのか？というのがこの問題です。障害事例毎にみてみましょう。
障害事例１
ISDN、TAおよびping監視に問題がない、つまりネットワーク経路上には問題がなく、障害の原因は受発注ファイルを書き込む領域が確保できていないということでした。
不要なファイルを定期的に削除してディスクの保存領域を確保することができればこの問題は回避できますが、それでは担当者の負荷もかかりますし、人間なので作業を忘れてしまうことも考えられます。日々の運用作業はできる限り自動化、システム化することが望ましいのです。
そのためには監視項目として受発注サーバのディスク使用率を追加すればよいでしょう。ディスクの使用率が一定の値を超えると警報として上がるようにしておけば、運用担当者が作業を忘れてしまうことはありません。また、不要なファイルの削除作業も定期的に行うことはなく、必要なときだけ実施すればよいので運用負荷は低減します。
障害事例２
障害の原因はL3SWの故障だったため、L3SWを交換して復旧しています。この場合もアプリケーションサーバとデータベースサーバへのping監視は問題なく、サーバのログ調査で初めて異常を発見しました。
ここで１つの疑問があります。サーバへのping監視トラフィックもL3SWを経由するにもかかわらず、なぜping監視は異常とならなかったのでしょうか？それはL3SWの壊れ方に関係しています。L3SWが完全に通信断となってしまえば当然ping監視で異常を検知できたのですが、今回の例は伝送エラーの発生というものでした。一方、問１(4)で解説したping監視の図をみれば分かるように、pingは連続して4回NGにならないと監視サーバは障害として検知しない仕組みになっています。
つまり、伝送エラーが発生してパケットロスが多くの割合で発生していたとしても、4回のうち1回でもpingの応答が返ってくれば監視サーバは障害を検知しないのです。
これを防ぐためには、L3SWのエラー発生率を監視すればよいでしょう。パケットエラーが一定の割合で発生した時に警報として上がるようにすれば、ping監視で検知できない障害も知ることができます。
障害事例３
障害の原因は、グループウェアサーバの性能不足でした。性能不足でアプリケーションのレスポンスが悪化したが、ping監視の応答は問題なかったというケースです。これを防ぐためには、サーバの性能に関するリソースの状況を監視として追加することになります。具体的にはCPU使用率やメモリ使用率となるでしょう。
(2)
サーバやサービスを起動した際には、想定しているサービスが正常に稼動しているかどうかをログで確認するのが一般的でしょう。設定ファイルに間違いがあった場合など、サービスが正常に起動していないことがあります。それに気づかずにそのまま運用に入ってしまうと、監視サーバからのサービス監視で異常を検出することはできるでしょうが、障害対応として後から慌てることになってしまいます。それ以前に、そもそも最初に正常にサービスが起動しているかどうかを確認しておけば間違いはありません。
よって起動メッセージを確認する理由は
起動時のメッセージから正常にサービスが利用できることを確認するため
となります。
【参考URL】
