運用を支える監視システムを構築する

デジタル（システム）の中のアナログ（人間）

第1回と第2回では主に、冗長構成によってネットワークの可用性を高める方法について解説してきました。第3回では、ネットワークを安定して稼働し続けるために必要な運用監視について解説します。

ネットワークを構築したら、ネットワーク機器やサーバー機を監視します。よくある監視の実際として、まずは死活監視があります。定期的に「ping」コマンドを発行してネットワークの到達性をチェックします。ネットワークが生きている場合は、次にポート監視です。Webサーバーの80番や443番（HTTPS）、メール・サーバーの25番や587番（SMTP_AUTH）など、アプリケーションが応答するポートに対して実際にアクセスを行い、アプリケーションが稼働していることを確認します。

このほか、監視対象の上で動作して細かい監視データを収集する専用プログラム（エージェント）を用いた監視も一般的です。特に、ネットワーク監視／管理の世界では、SNMP（Simple Network Management Protocol）と呼ぶエージェント／サーバー型プロトコルが有名です。ネットワーク機器やサーバー機がSNMPのエージェント機能を備えており、外部のSNMPマネージャ・ソフトから監視／管理できます。

オープン・ソースでも、優れた監視ソフトが多数存在します。監視データのグラフ化では、SNMPなどを用いて「RRDtool」で収集したデータを簡単にグラフ化できる「cacti」（図1-A）や、古くから親しまれているMRTG（RRDToolの従来版に相当）が有名です。サーバーのリソース状態を監視するソフトとしては、サーバー監視用に専用のエージェントを用意している「Nagios」（図1-B）などが有名です。

スリーセブンワークスでも、こうした監視システムから得られる情報を顧客企業に提供するサービスを提供しています。例えば、サーバー機の負荷状態やディスク容量など監視したいポイントをcactiでグラフ化してWebブラウザ経由で常時閲覧できるようにする仕組みです。

こうしたオープン・ソースのグラフ化ツールや監視ソフトに関する情報は、すでに多数存在しています。Web上に解説資料も充実しています。このため、本記事ではツールの導入方法や機能に関する説明は省きます。代わりに、ユーザー企業がこれらのツールを設置した後で、実際にどう運用していくべきかを解説します。

監視のしくみとしきい値

監視においては、まずは“しきい値”の設定が重要です。障害監視におけるしきい値とは、どのラインを越えたら障害として検知するかを定めた値です。

ping監視におけるしきい値は単純です。ping監視では、小さなパケットを対象サーバー（ネットワーク機器）へ送信し、応答が帰ってくることで対象のネットワーク・カードが生きていて応答を返してきていることを確認します。ここでは、「応答のあり/なし」が しきい値となります。応答があれば正常、無ければ通知、というように、ごく簡単に切り分けられる監視となります。

ポート監視でも同様に、しきい値は単純です。TCPやUDPのプロトコルで該当するポートにアクセスし、「サービス用のポートが開いている/いない」（または、期待する返答を返す/返さない）を確認します。障害を検知する方法としては、ping同様に簡単です。

では、いわゆるパケット・ロスが発生している場合はどうでしょうか。

ping監視の場合、10回あたり5回以下の応答しかなかった場合は、障害と見なしてもよいでしょう。この際、もしping監視で1回だけの「応答あり/なし」を確認していたら、応答が1回でも帰ってこなかったら障害となってしまいます。ここで、余裕を持って10回あたり3回返ってこなければ障害として認識する監視システムを構築してみるとよいかもしれません。

この「さじ加減」がしきい値であり、監視を行ううえでとても重要なポイントとなります。

監視項目「ロード・アベレージ」も重要

しきい値を定める対象となる監視項目の1つに、サーバー機やネットワーク機器の「ロード・アベレージ」（単位時間あたりの平均的な負荷）があります。これは、負荷を確認できる基礎的な数字です。一般的に「1.00」までの状態が機器に負担をかけずに機能を使っている状況を差し、「1.00」を超過した場合には何らかの理由で機器に負荷がかかっている状態を指します。

サーバー機のロード・アベレージは、CPU/メモリの利用状況などを総合的に観察しており、値は「0.00」から「600.00」以上になることもあります。このため、「1.00」までを正常値として監視するのは問題です。ファイルを一時的にコピー／圧縮したり、メモリ常駐型のアプリケーションを使っている場合などでは、ロード・アベレージが常時「2.00」付近を示すサーバーも多く存在するからです。サーバーの用途によっては、瞬間的な数値で「10.00」以上を示すこともよくあります。

つまり、これら一部のサーバーについても、監視の面では「継続的にロード・アベレージが3.00以上を示していたら障害として検知」などのような、監視の「さじ加減」が必要になるわけです。特に、実際に運用したところ監視データがしきい値付近で推移してしまう場合は、一時的にしきい値を見直すことも大切です。

技術者の技量に左右される「さじ加減」や「しきい値」などは、監視と障害検知の段階で必須となるだけでなく、障害を検知した後でも重要です。検知した障害の通知を受け取って判断するのはエンジニアだからです。サービスの目視確認や専用ツールによるサービス確認、実際にサーバーにログインしたうえでの確認など、本当に障害が起こっているのかを確認する初期対応が必要です。

たった一言で「24時間対応」と表現されてしまう運用監視ですが、優れたエンジニアによる運用保守面がとても重要であることを理解していただきたいと思います。日々の運用の下、システムを守るエンジニアが障害の発生に備えて待機する必要があるのです。

次ページ以降では、障害を検知し、対処していくための具体的なノウハウを解説します。