サーバー構築のデージーネットTOP > OSS情報 >OSSのおすすめ監視サーバ・監視ツール比較17選
OSSのおすすめ監視サーバ・監視ツール比較17選
サーバを効率的に管理するのに欠かせない監視サーバですが、様々なソフトウェアがリリースされています。監視サーバは、以前は製品を利用することが多い分野でした。しかし、最近ではオープンソースのソフトウェアの機能が向上し、オープンソースソフトウェアを使う場合も多くなりました。ここでは、OSSの監視サーバの選定ポイントを紹介し、いくつかの監視サーバソフトウェアの比較をしてみます。
ネットワークサービス監視ツール
サービスレベルで正しく稼働しているかを確認します。サービス監視は、低レベルなものから高レベルなものまであります。例えば、該当サービスで利用するTCPのポートが利用できるとか、サービスプロセスが稼働しているかという監視は、比較的低レベルな監視です。より高いレベルで、WEBサーバに実際にアクセスして、レスポンスコードが正常かを確認する方法もあります。さらに、レスポンス内容までをチェックして、想定された応答が返っているかというところまでを確認する高度な監視方法もあります。ソフトウェアによって、サポートしているサービスやレベルには差がありますので、注意が必要です。
1. zabbix
Zabbixは、サーバ、ネットワーク、アプリケーションを集中監視するための統合監視ソフトウェアです。
状態監視、障害検知、通知機能を備えています。多数のプラットフォームに対応したZabbixエージェントとSNMPとSNMPトラップに対応しているため、システム全体をZabbixひとつで監視することが可能です。また、スクリプトを作成してアプリケーションの監視を独自に拡張できたり、障害検知時にもスクリプトを実行する、Zabbixエージェントにスクリプトを実行させるなど自由に拡張を行えるというのも特徴です。
ZabbixではWebインタフェースから設定を行い、収集データはMySQLに保存します。監視の設定をすべてWebインタフェースから行えるため、比較的設定が容易です。また、データベースに保存した収集データからグラフを作成し、リソース使用状況の傾向分析や障害分析を行うこともできます。
多数の対象を監視する場合のために、Zabbix Proxyという機能も用意されています。そのため、大規模なシステムの監視を行うことができます。
Zabbixは、日本でも多くの企業が商用サポートを行っていますので、必要に応じて日本語の有償のサポートを受けることが可能です。このように良いことずくめのZabbixですが、監視設定の項目が非常に多いため、監視の設定が難しく利用の難易度は高めです。また、現在の監視状態を一目で把握することが難しいという欠点があり、サードパーティの監視コンソールも登場してきています。
2. cacti
Cactiは、SNMPを使用し、監視ターゲットの統計情報を取得・グラフ化するソフトウェアです。また、Cacti Users提供のプラグインをインストールすることで監視システムとしても利用できます。zabbixに比べて、利用の難易度が低いため人気のある監視ソフトウェアです。
もともと、CactiはMRTGの代替ツールとして開発されました。MRTGがテキストファイルで設定、データを管理するのに対して、Cactiはデータの保存にRRDToolを使用しており、ホストの追加やインタフェースの追加など、すべてWEBインタフェースを通して設定変更が可能です。WEBインターフェースは、日本語化もされています。
作成されるたくさんのグラフをネットワーク機器の機種や用途などで分類し、ツリー構造で管理することができます。また、設定変更といったすべての権限を持った管理者ユーザや、グラフを見ることしか出来ない一般ユーザといったように、ユーザごとの権限を設定することもできます。LDAPを使ったユーザ管理にも対応しています。
情報を収集するプログラム（ポーラ）を高速化し、必要に応じて分散することで多数の監視対象にも対応できる設計になっています。
3. Nagios
Nagiosとは、オープンソースの統合監視ソフトウェアの中でも歴史のあるソフトウェアです。システムとネットワークの稼働状態を監視する機能を提供します。システムの異常を検知すると、それを管理者にメールで報告する機能などを備えています。利用実績や日本語の情報が多くあり、比較的情報を入手しやすいのが特徴です。
基本機能は、サーバにPINGを飛ばしての「死活チェック」と、クライアントとしてサーバにアクセスして稼働状況を監視する「アクティブ・チェック」のみです。しかし、様々なプラグインを利用することで多様なサーバ機能をチェックすることができます。TCP/UDP汎用のプラグインも用意されているため、独自プロトコルを利用したサービスレベルの監視にも対応できます。
Nagiosはデータ管理をすべてファイルベースで行っており、データベースを使用しません。障害が発生したかどうかの履歴もテキストファイルに記録するため、作成できるグラフは障害履歴に関するもののみであるという欠点があります。
4. Icinga
Icingaは、Nagiosのフォークで、GUIや外部連携を強化したソフトウェアです。Nagiosの設定やプラグインなどを、そのまま読み込んで利用することができます。Icingaでは、WebUIのIcinga Web、モバイル向けのIcinga Mobile、レポート作成と通知のIcinga Reportingなどが、コンポーネントとして提供されます。
5. munin
muninは、リソースモニタリングソフトウェアです。エージェント型でサーバから情報を収集し、Cactiと同様にRRDToolを利用してグラフ表示します。Muninには通知機能がありませんので、監視と通知に特化したNagiosと組み合わせて利用する例が多いです。
Muninは、MRTGと同様に監視時に随時グラフを作成しますので、サーバの負荷が高く、あまり多くの対象を監視することはできません。小規模なシステムを監視するのには向いています。
6. Hinemos
Hinemosは、非常に高機能な国産のオープンソースの運用管理ソフトウェアです。運用グループごとにコンピュータをグループ化し、ジョブの管理や性能管理、情報の収集蓄積などを行うことができる高機能なソフトウェアです。その機能の一つとして、状態監視をサポートしています。HTTPやSQLなどの高レベルのサービス監視や、syslogの監視も行うことができます。SNMPおよびSNMPトラップにも対応しています。
ジョブ管理に対応しているため、JP1などの製品の運用管理ソフトウェアからのリプレースで利用されることが多いようです。NTTデータ社からはエンタープライズ版が提供され、製品サポートも受けることができます。
7. Pandora FMS
Pandora FMSは、エージェントによる情報収集とSNMPの両方に対応した状態監視のソフトウェアです。オープンソース版、SaaS版、エンタープライズ版があり、SaaS版、エンタープライズ版を使えば、日本でもサポートを受けることができます。
SNMP、SNMPトラップ、エージェント型の監視のすべての方法に対応しています。メールでの通知や、外部プログラムとの連携も行うことができます。直感的で操作性に優れたコンソールを備え、スマートフォンなどからの管理にも対応していることが特徴です。また、サーバー単体でなく、サーバの集合体としてのシステムを監視することができます。複数の監視サーバを、一括管理する機能があるため、大規模なシステムの監視にも対応することができます。
ただ、オープンソース版では、監視テンプレートなどの機能が提供されていないなど、制約があります。また、構築方法や利用方法の情報が、あまり出回っていません。
稼働状況の可視化ツール
サーバシステムでは、正常にサービスが行われていることを確認するために、システムの負荷やアクセス量などを監視する必要があります。また、ネットワーク機器では、通信のエラーが起こっていないことや、通信帯域が充分にあることを監視しておく必要があります。そうした、サーバや通信機器の様々な指標となる数値を集めて、管理します。
正常な状態というのは、サーバ毎に違います。そのため、どのような状態を正常とするかは、管理者が設定する必要があります。また、状態を保存し、履歴として可視化することで、異常な状態を見える化することも重要です。
8. MRTG
MRTGは、SNMPで定期的にポーリングを行い、収集したデータをグラフ化するソフトウェアです。非常に古くから使われている稼働監視ツールです。MRTGは、perlで書かれたシンプルなソフトウェアで、HTML出力機能、設置の容易性から、広く使われています。
MRTGは、グラフ部分をPNGフォーマット、付帯情報をHTMLフォーマットで出力します。そのため、データを見るためにはWebサーバを起動しておく必要があります。収集したすべてのデータは過去2年間分保持され、過去1日間、7日間、4週間、12カ月間のトラフィックのグラフを生成します。情報の取得、グラフ化に特化しており、監視などの機能はありません。データ、設定はすべてテキストファイルで行います。監視と同時に画像ファイルを作成するため、あまり多くの対象を監視することはできません。
9. collectd
collectdは、サーバの統計情報を収集するためのオープンソースソフトウェアです。
Linuxサーバでcollectdを起動すると、定期的にサーバの統計情報を収集してデータベースに保存します。保存されたデータは、collectdに含まれるウェブインタフェース(CGI)を使用して参照することが可能です。収集データはグラフ化して表示されます。
プラグインとして提供されているモジュールをロードすることで、収集する情報を選択することができます。プラグインは数多く提供されていて、いろいろな統計情報を収集することができます。
例えば、Linuxサーバの基本的な統計情報では、CPU使用率・ディスクパーティションの使用量・ネットワークインタフェースの通信量・ロードアベレージ・メモリ使用量・スワップ使用量・TCPコネクション数等の統計情報を収集してグラフ化することができます。また、ApacheのサーバステータスやMySQLの統計情報等、サーバアプリケーションに特化した情報を収集することも可能です。
取得した統計情報を監視し、閾値を超えた場合にメール等で通知を行うこともできます。
監視コンソール
10. Grafana
Grafanaは、ダッシュボードを構築することができるOSSのソフトウェアです。Grafana Labsが開発し、オープンソースとして公開しています。Elasticsearch、influxDB、MySQL、PostgreSQL、Xabbixなどからデータを収集し、ダッシュボードとして表示することができます。ダッシュボードは、ウェブインタフェースから利用でき、グラフ作成・配置の操作も簡単に行えます。複数のZabbixを利用している環境や、多種の監視ソフトウェアが混在している環境で利用することで、管理者はシステム全体の確認すべき情報に素早くアクセスすることができるようになります。
11. Hatohol
Hatoholは、複数の監視サーバを統合して管理するソフトウェアです。ZabbixとNagiosに対応しています。複数のZabbixやNagiosから情報を収集し、状況を表示したり、イベントを管理することができます。また、監視サーバで発生したインシデントをRedmineに登録することができます。さらに、ジョブ管理の機能も持っています。
ログ管理・監視ツール
サーバのOSやアプリケーションのログ、ネットワーク機器のログなどを収集し、監視する方法です。ログは、問題の発見にも使いますが、問題の解析にも必要になります。問題の発見と解析の両方を考慮して監視ソフトウェアを選ぶ必要があります。
統合監視ソフトウェアでは、これらのすべての機能を持ったものも少なくありません。しかし、現実的には、すべての機能を一つのサーバ機器で行うことは好ましくありません。例えば、何かの障害を検知した場合には、いち早く通知を行う必要があります。しかし、障害発生時にはログが大量に出力される場合もあります。ログ監視とサービス監視を一緒に行っていると、監視サーバがログの受信や解析で過負荷になり、通知が遅れるなどの原因になってしまいます。そのため、用途によって複数の監視ソフトウェアを使い分けるのが、懸命でしょう。
12. SyLAS
SyLASは、デージーネットが作成したオープンソースのログ管理ソフトウェアです。rsyslogのログ通知機能を使って、ログの文字列をチェックし、メールで通知を送ることができます。また、ログを全文検索エンジンのElasticSearchに保管し、ログを高速に検索することができます。国産ソフトウェアですので、WEB画面は日本語表記です。
13. graylog
Graylogは、SyLASと同様にElasticSearchにログを保管し、高速検索することができる統合型のログ管理ソフトウェアです。非常に高機能なソフトウェアで、ユーザによって管理できるログを変えられたり、解析結果をグラフで可視化することができます。解析方法をあらかじめ定義して監視コンソールを作成することができるのも便利です。単体でsyslogサーバとして動作させることもできますし、HTTPやFTPなどのプロトコルでログを収集することもできます。あらかじめ、多数のネットワーク機器のログフォーマットに対応した解析パターンを用意しているのも特徴です。
ただし、画面の表示は英語です。コミュニティは他国語対応をしないと表明しています。そのため、デージーネットでは日本語の利用者マニュアルを公開しています。
14. rsyslog
rsyslogは、多くのLinuxディストリビューションで利用されているsyslogサーバのソフトウェアです。rsyslogには、ログの文字列をチェックし、必要に応じてメールで通知する機能が標準で備わっています。そのため、特別なソフトウェアを導入しなくても、ログ監視を行うことができます。
15. syslog-ng
syslog-ngも、rsyslogと同様にいくつかのLinuxディストリビューションで採用されているsyslogサーバのソフトウェアです。柔軟なフィルタリング機能や設定オプションなどが用意されているのが特徴です。syslog-ngにも、ログの文字列をチェックし、必要に応じてプログラムを起動する機能があります。この機能を使って、メールで通知を行うことができます。
16. swatch
swatchは、Simple log Watcherの略で、シンプルなログ監視機能を提供するツールです。正規表現に一致する行があった時にコマンドを実行することができます。この機能を使って、メール通知を行うことも可能です。
死活監視ツール
監視対象がネットワークからアクセスできる状態かを監視します。一般的には、PINGに応答するかという確認をします。ルータやスイッチなどのネットワーク装置の場合には、この方法で十分な場合が多いです。
17. fping
fpingは、Linux/Unixで利用可能なコマンドラインのユーティリティツールです。ファイル指定した監視対象のホスト名・IPアドレスに対して同時並列的にpingを送り、結果をまとめて報告します。IPv6にも対応しています。
cronなどを使って定期実行し、問題のあるホストだけを通知するようにすれば、非常に簡単に死活監視を行うことができます。
監視ソフトウェアの選定ポイント
監視サーバを選定する場合には、どのような対象に対して、どのような監視を行う必要があるのかを十分に考慮する必要があります。また、そもそも管理の効率化を目指して行うのですから、管理のしやすいものを選ぶ必要があります。
監視後のアクション
ほとんどの監視サーバでは、監視結果に基づいて何らかの通知やアクションを行う機能が用意されています。用途に合わせて、適切な管理方法が取れるソフトウェアを選択する必要があります。
- ＋画面上で確認
- ★
監視コンソール上で視覚的に問題点を表示します。管理者が常時状況を確認できる状態の場合には、この方法だけでも充分かもしれません。また、他の通知と組み合わせて利用すれば、状況を把握しやすくなります。
- ＋メールの送信
- ★
管理者にメールで通知します。管理者が常時コンソールを見ていられないような場合には、有効な方法です。
- ＋サービスの正常化
- ★
システムを待機系に切り替えたり、障害が発生したサーバを自動的に切り離すなど、サービスを正常化するアクションを行います。例えば、HAクラスタのソフトウェアはサービスを監視していて、異常があれば自動的に待機系のサーバにサービスを切り替える機能を持っています。これは、監視を応用した例です。
- ＋インシデントの登録
- ★
発生した問題をデータベースなどに登録し、管理者が問題管理を行いやすくします。
- ＋その他
- ★
外部連携の機能を持っているソフトウェアもあります。外部連携の機能があると、障害発生時に少しでも早く管理者に知らせるために、警告音を出す、パトランプを回す、電話を掛けるなど、様々な方法をとることができます。ちなみに、デージーネットでは、監視を行っている顧客システムでの障害発生時には、パトランプが回転し、警告音が鳴るようにしています。また、夜間にはコールセンターへの通知も行っています。
SNMP型かエージェント型か
監視ソフトウェアが監視を行う方法には、SNMP型とエージェント型があります。
SNMP
SNMP（Simple Network Management Protocol）は、多くのネットワーク機器がサポートする監視のためのプロトコルです。Windows ServerやLinuxでもSNMPがサポートされています。そのため、ほとんどの機器を監視することができます。Linuxディストリビューションで標準的に使われているNET-SNMPでは、サーバのロードアベレージ、CPU使用率、ディスク使用率、プロセスの状況など、サーバの状態監視に必要なほとんどの機能を揃えています。そのため、ほとんどのケースではSNMPでの監視で充分です。
エージェント
監視対象の機器に、監視エージェントとよばれる専用のプログラムをインストールし、それを通じて情報を収集するやり方です。SNMPよりも詳細な情報が取れます。SNMPだけでは情報が不足する場合には、エージェント型で監視ができるソフトウェアを選択します。ただし、エージェントは専用のプログラムであるため、どの機器にもインストールできるわけではありません。
トラップとポーリング
SNMPによる監視では、SNMPトラップとポーリングの2つの方法があります。SNMPトラップは、監視対象機器で何らかの障害やイベントが発生した場合に、機器から監視サーバに通知を送る方法です。一方、ポーリングは、監視サーバから定期的に状況の確認を行う方法です。
SNMPトラップを利用する利点は、即時性の高さです。問題が発生してすぐに監視サーバに通知が行われるため、管理者はすぐに問題の発生を知ることができます。SNMPトラップの通知には、UDPが使われます。しかも、問題発生時に一回だけ通知が行われます。そのため、ネットワークのトラフィックが高かったり、監視サーバの負荷が高くてパケットを受け取れなかったりすると、通知のパケットが失われて届かない場合があります。障害発生時には、ネットワークが混み合っていたり、監視サーバにも負荷がかかる状況になる場合が多いため、その危険性を認知した上で別の監視方法と組み合わせて使う必要があります。
一方、SNMPポーリングでは、監視サーバが定期的に監視対象を確認しに行きます。例えば、1分おきに監視を行う場合、障害の発生から検知までには1分のタイムラグができます。また、問題が1分以内に収束してしまった場合には、その検出もできません。しかし、問題が直らなければ何度でも通知が行われるため、継続している問題を見落とすことは、ほとんどありません。
一般的には、少しのダウンタイムも許容できないシステムの場合には、SNMPトラップと別の監視を組み合わせて使います。しかし、ほとんどの場合にはSNMPポーリングで充分だと考えられています。また、SNMPトラップとログの監視を同一のサーバで処理することは避ける必要があります。
管理性
監視サーバの管理性は、かなり重要な確認項目です。頻繁に監視対象機器の追加がある場合には、やはりGUIから設定できると便利です。また、監視結果を数値で見ても分りにくいため、グラフなどにしてGUIで表示してくれると分りやすいです。また、管理GUIは日本語対応が行わている方が使いやすいでしょう。
拡張性
監視対象の数が多い場合には、複数台の監視サーバが必要になる場合があります。そのような場合でも、対応できる拡張性があるかどうかを確認しておく必要があります。