Nagios、Zabbix…いろいろな運用監視ツールの評価ポイント
監視ツールの目的
今回は、ITシステムの運用監視業務の現場で用いられている、監視ツールについて見ていく。
監視ツールの目的はいうまでもなく、
- 監視対象となるサーバーやネットワークなどのシステムリソースの状態を可視化し、
- インシデントが発生したときに即座に対応できるようにすること
であり、そのためのモニタリングツールだ。監視対象に対して、「監視項目を設定」し、「監視情報を収集」し、何らかの状態変化が発生したときに「通知」を行う。
以前の記事でも触れているが、アールワークスでは、システム運用のベースとなる統合監視ツールとして、「Pandora FMS」を採用している。このツールは、単なる監視ツールの域を超えて、統合運用管理システムとして導入している。
以降では、他の監視ツールについても見ていきながら、「Pandora FMS」の採用に至った経緯についても説明する。
OpenViewよりも柔軟な監視ツール探し
アールワークスでは、長年、「HP OpenView NNM」(Network Node Manager)を採用してきた。
OpenViewは、
- きめ細かな監視項目の設定ができること。
- 大規模な監視にも向いていること。などを特徴としており、数多くのシステム運用の現場で採用されている、非常に堅牢なシステムである。
通信キャリアでは、通常、交換機などの独自のネットワーク機器や、システムノード(装置)を多数運用していることから、ネットワークの管理には、独自の管理システムを開発し、運用することが多い。しかし、そのような独自開発された管理システムでさえも、OpenViewをソフトウェア基盤として、独自に拡張している事例が多く見られる。こういったことからも、OpenViewの信頼性の高さが伺える。
このようなOpenViewであるが、アールワークスでの運用監視業務にはそぐわないものとなってきていた。その理由は、以下の通りである。
- 監視設定が複雑で、操作にスキルが要求される。
- 専門のシステム運用担当者向けを想定した複雑な画面で、顧客に画面を見せることが難しい。
- 監視対象の規模が大きくなるに伴い、コストも跳ね上がる。
アールワークスのシステム運用業務において、どのようなツールが最適なのかを再検討した結果、監視ツールに求める条件は、次のようなものとなった。
- 顧客と監視対象の状況を共有できる「わかりやすい画面」。
- 新人社員を運用業務に投入するまでの教育コストを抑えたい。
- 頻繁に発生する監視設定の投入、監視業務の立ち上げコストを抑えたい。
- 顧客の監視対象システムの規模、ノード数、さらに顧客のサイト数の増加に対して、緩やかな伸びのライセンス料の体系にしたい。
- 監視ツールとして運用しながら、業務に応じて拡張が可能であること。
つまり、OpenViewという重厚長大なシステムが、「アールワークスの業務にマッチしていない」という結論になった。そこで、OpenViewに代わり、上記に挙げた我々が求める監視ツールを探す旅が始まった。上記の条件のうち、(4)と(5)の条件を重視し、オープンソースプロダクトの中から探すこととなった。候補となったのは、他にもいくつかあったが、主要なものとしては、次の通りだ。
Nagios(ナギオス)
オープンソース監視ツールの代表格(図1)。コミュニティで開発されているプラグインが大変豊富にあり、機能面では不足することはまずないと思われる。ただ、監視項目の設定は、テキストエディターで設定ファイルを書き換えることで行う必要があり、業務と照らし合わせた結果、設定投入時のケアレスミスを防ぎたいという要望から、採用は見送ることになった。
また、監視項目を追加するたびに、監視システムの再起動が必要であることも弊社の業務にそぐわないという判断がなされた。
Hobbit(現Xymon)(シモンまたはサイモン)
多機能な商用監視ツールである「Big Brother」(BB)の代替えを目指して開発されたもの。今では、ほぼBBからの置き換えが可能となっている、非常にGUI(Graphical Uswer Interface)が洗練された監視ツールだ(図2)。
BBで不得手とされた、大規模ネットワークの監視なども行えるようになっているなど、一部BBを凌駕するほどの機能を持つ。GUIは大変優れているHobbitだが、残念なことに、監視項目設定は、設定ファイルをテキストエディターで編集し、システムを再起動する必要がある。その結果、先のNagiosと同様、採用には至らなかった。
Hinemos(ヒネモス)
IPA(独立行政法人情報処理推進機構)の支援のもと、NTTデータで開発されたシステム管理ツール(監視専用ツールではない、図3)。前述した2つと違い、監視設定は、専用クライアントからGUIで設定が可能であり、監視設定完了後の設定反映に、システムの再起動を必要としない。また、設定データはリレーショナルデータベースに格納されるので、設定入力時のケアレスミスも軽減できることが期待できる。ただ、プラグイン機能など、監視項目の拡張性がないことが難点だと言えよう。
設定用のクライアントは、プログラマーにはなじみの開発環境である、Eclipse上に構築された専用クライアントが必要となる。そのため、アールワークスが求めた、「顧客と監視状況を共有するためのプラットフォーム」として利用することは難しいものであった。また、監視クライアントと監視サーバー間で、多様なプロトコルや、多数のポートを使用しており、ファイアウォールを跨ぐのが困難なため、この点においても、「顧客と監視状況を共有するためのツール」としては厳しいと判断した。
Zabbix(ザビックス)
これまで見てきた監視ツールからすると後発のプロダクトだが、ラトビアのZabbixSIA社により精力的に開発が行われており、今やオープンソースのデファクトスタンダード(業界標準)となる勢いの「Zabbix」だ(図4)。商用サポートを行うベンダーもあり、業務で採用するうえでは、魅力的なポイントの1つだ。
監視項目の設定は、WebブラウザーからWebアプリケーションとして設定できるし、設定後のシステム再起動も不要である。また設定データも、リレーショナルデータベースに格納されるので、ケアレスミスによるシステムダウンの可能性も低い。唯一難があるとすれば、プラグイン方式を採用していないので、監視項目の追加が少し煩雑といったところだろうか。ただし、独自のスクリプトを用意すれば、どのような監視項目を追加することも可能であるなど、システムとしてはとても魅力的なものだった。
Pandora FMS(パンドラ エフエムエス)
スペインのArtica社が開発する監視ツールである(図5)。Zabbixと同様、開発ベースはオープンソースに軸足を置きつつ、Artica社はそれとは別にエンタープライズ版(商用ライセンス)も用意している。
システムとしてのアーキテクチャは、通常のWebアプリケーションであり、サーバーはPerl、収集データはMySQLに格納され、WebコンソールはPHPアプリケーションといったように非常にわかりやすい。監視項目はプラグイン方式で、運用しながら追加ができ、即座にWeb監視画面に反映される。Perl、MySQL、PHP、シェルスクリプトといった慣れ親しんだテクノロジーで開発されており、ソースコードへのアプローチも敷居が低いものであった。
監視設定やアラートの設定など、日常のオペレーションもすべてWebブラウザー上のGUI画面からの操作が可能であり、複数の異なる権限を設定することで、社内運用担当者と顧客との間で、同じ画面を見ながら監視状況の共有が可能である。最後まで候補に残った前述のZabbixと比較すると、圧倒的に画面レイアウトが初心者にわかりやすく、「これならお客様に直接見せることができる」と評価し、採用に至った。
以降の記事で具体的な実践例を挙げるが、Pandora FMSまたはそれをベースに利用したASPサービス「SoNar」(ソナー)を前提とした記述となっている。
※画面写真などは2012年当時のものです。