サーバー監視ツール

ec001サーバーの障害について、ご迷惑をおかけし、申し訳ございません。
各種ログを調査し、早急なる原因の特定に努める所存です。

以下対策が必要な状況と今後の対応について。

現在のところ、eth0の転送がダウン前に急激に増加していたことから（通常なら50KB/秒が1000KB/秒近くに跳ね上がった）、CGサイトなどが大手ニュースサイトに一気に取り上げられ掲載され、アクセス過多に陥って処理の大幅な遅延が発生したという可能性を念頭において調査しています。
（CGサイトの公開する画像ファイルへのアクセスはサイズも大きかったり、大量に呼び出し要求があったりするのでかなりの負荷になります。）
現在はアクセスが多かったサイトの特定およびApache側の調整を行う段階です。

今回、サーバー監視ツールは正常動作していたものの、通知が無かったという点について、サーバー監視ツールの改良を行うことが急務となりました。

現在のサーバー監視ツールはCGI PROXYのperlスクリプトを改造し、閲覧ができる(接続が確立する)場合はtrue,タイムアウトする場合はfalseとして判定しメールを送るシステムとなっています。
ただ、今回のように断続的な場合、負荷がかかって重いという状態の場合、接続が確立するとtrueとなる今の監視ツールは基本的設計に欠陥があるということが今回の障害で証明されてしまいました。

監視対象サーバー側で自分でLAを取得し、一定の値になったらメールを送信する仕掛けもできるのですが、本来の処理に集中させたいという考えから今まで導入を見送っていました。

ただ、そういうことを言っていられない事態が発生していますので、監視対象サーバー側ではアクセスしたらLA(1分平均）をXMLで吐くようにし、監視側でそれを取得、一定の値および取得できない場合にメールを送信させるシステムに変更します。
今回の取得できない場合の判定は接続の確立有無ではなく、配列に値が入らない場合で判定し、重くて接続は確立するのだがコンテンツが来ないという場合でも通知が行くようにします。

というか、本家サイトも一緒に落ちるのはまずいだろ…常識的に考えてorz
きちんと独立したサーバーに移動させることも検討しないとですね…。

いろいろ言い訳を並べてなんだというエントリーになりそうですが、
全ては当方の管理力不足です。スレでも指摘されていますが、
サーバーダウンはめったに起きてはいけないのです。
それが最近多発しているというのは、こちらの監視システムおよび急激なWebアプリケーションの変化に対応できるサーバー環境・設定の整備が追い付いていないという指摘を受けても仕方ないのではないか、そう考え、根本的な対策が急務となっていることを痛感いたしました。
このたびの障害につきましては、衷心よりお詫び申し上げます。
誠に申し訳ございませんでした。