一般障害への対応

一般障害への対応

一般障害が発生した場合、シンプルな場合は従来型の単純な死活監視でも問題の検出が可能だが、トラブルの種類によっては意外に複雑な様相を呈することもある。こうした場合は、監視ツールの支援機能の有無が対応時間を大きく左右することになる。たとえば、あるシステムのトラブルが他のシステム上でエラーを引き起こすといった連鎖反応が起こり、エラーが大量に発生する場合などがそうだ。この場合、なんらかの障害が発生したことはすぐに分かるが、根本原因が特定できないと解決できないため、対応に時間を要してしまうことになる。このとき、人力でエラー情報を整理することももちろん不可能ではないが、ツール側に支援機能があれば作業が大幅に効率化される。

図2：System Answer G2 アラート画面（クリックで拡大）

画面例は、多数のホストでtimeoutエラーが発生し、管理画面に大量のアラートメッセージが表示されてしまっている状態だ。 もちろんこの大量のアラートを順番にチェックしても良いが、ツールにこうした連鎖反応的なエラーを整理する機能があれば、それを活用することで現状把握が容易になる。

たとえば「System Answer G2」では「トポロジー画面」が提供されており、システムの状態をネットワークトポロジーに沿って表示することが可能だ。実際に表示してみると、タイムアウトエラーを発生させているホストはすべてコアネットワークの配下に接続されていることが図示された。 こうなれば、障害がまずコアネットワークで発生し、その影響で正常なはずの他のホストにタイムアウトエラーが発生してしまった、という図式が容易に想定できる。後は、その想定が正しいかどうかをコアネットワークの状況を正確に把握することで確認すれば良い。

図3：System Answer G2 トポロジー画面（クリックで拡大）

詳細情報を大量に収集しても、具体的なアクションにつながらないのであれば情報を活用しているとは言いがたく、単に情報におぼれた状態になりかねない。同様に、大量のアラート／エラーから最も重要なものを選び出すことができなければ、こちらもアラートの海におぼれた状態になる。こうした状況から素早く脱するためには、もちろん運用管理担当者の経験やノウハウも有用だが、ツールの支援があれば誰でも容易に望ましい結果を得ることができる。

ツールの選択に際しては、実際の運用管理の現場でどれだけ効率的な作業が実現できるか、という点に留意しておく必要があるだろう。

サイレント障害への対応

サイレント障害は死活監視では発見できない場合が多く、長期的な性能監視がその威力を発揮する。場合によっては、ユーザーがまだ気づかないレベルの軽微な性能劣化が発生した時点でトラブルの発生をいち早く検知し、対処できることもある。

「System Answer G2」では長期にわたってデータを収集し、それに基づいて“平常時の状況をデータ化して保持する”「ベースライン」という機能を実装している。さらに、ベースラインと現状を比較し、ベースラインからの乖離から異常を発見してアラートを発することもできる。この機能によって、運用管理者もユーザーも気づかないようなトラブルの兆候をいち早く警告することが可能になる。

図4：System Answer G2 アラート画面（クリックで拡大）

ベースラインアラートが表示された場合、さらに詳細をグラフ表示してベースラインとの比較を行うことで、いつどのような“異常”が発生したのかを具体的に知ることができる。

図5：System Answer グラフ表示画面（クリックで拡大）

そこからさらに、「その時間にシステムに何が起こっていたのか」を具体的に突き止めるためには地道な調査が必要になるが、グラフ表示から変動発生の日時や変動のパターンが視覚的に把握できることから、何も手がかりがない状態に比べれば遙かに究明は容易だろう。 具体的な日時が特定されているだけでもログのチェックが効率化されるので、根本原因の究明作業も効率化されると期待できる。紹介した例の場合は、実際にはアプリケーションの潜在的な不具合によってデータ受信がしづらくなる事象が生じてしまうことが原因だということが後に判明している。

こうした場合は、インフラ側の問題ではないことから運用管理者が問題のすべてを独力で解決することはできないが、問題点を明確化した上でアプリケーション側の担当者に情報提供することで迅速な問題解決が可能になる。