第6回 他のツールとの比較 （1/3）

技術特集

1_zabbix6_tit

tit_zabbix
１）Nagiosとの比較
概要

CPUやメモリ、ハードディスクなどのリソースの状態やプロセスや サービスの状態、さらに、ログファイルに出力された文字列を判定して、 障害発生を検知し障害通知を行うことができる監視ツールです。


初期バージョンが2002年頃にリリースされていて、既に10年以上利用され続けており、さらに、コミュニティでのプラグイン開発や共有によって、様々なサービスを監視することができる実績を持っています。


Webのフロントエンドの画面イメージは、以下のようになります。


zbx_nagios_host_top


現時点では、商用のNagios XIというソフトウェアと、OSSで継続して公開されている Nagios Coreとに分かれています。

ここで取り上げるのは、OSSであるNagios Coreを対象とすることとします。

Nagios XIであれば、多くの機能が追加されているので、もしかしたら有用な機能が用意されているかもしれません。


主な機能

  • リソース監視／ログ監視／障害通知

Nagiosだけでは、取得した値をグラフ化する視覚化の機能を持ちません。
グラフ表示を行いたい場合は、他のツールと連携させる必要があります。


対応プラットフォーム

  • 監視用サーバ
  • Linux、UNIX系OS
  • 監視対象
  • Linux、UNIX系OS、Windows、SNMP 対応機器

Nagios自体はWindowsに対応していませんが、SNMP を利用したり、サードベンダーが公開しているプラグインを利用したり、NSClient++やNRPE_NTのようなエージェントをWindows上にインストールすることで、Windowsも監視することは可能です。


システム要件

net-snmpと監視で利用する各種プラグインを動かすために必要なソフトウェアが必要になります。
Webフロントエンドを利用する場合は、PHPやGDが必要となります。
Nagiosだけを動かすのであれば、DBMSは必要ありません。


インストール方法

ソースからのインストール、またはパッケージを利用したインストールになります。
ただし、後記の日本語対応が含まれるパッケージは公開されていないので、日本語対応したNagiosをインストールしたい場合は、ソースからのインストールを行うことになります。


操作設定方法

監視の設定は、設定ファイルを編集して行います。
設定ファイルを編集後、Nagiosのデーモンを再起動することで、変更した内容が反映されて監視が開始されます。


設定ファイル内では、値の取得と閾値の設定も一緒に記載するので、例えば、デフォルトで以下のような設定が用意されています。


1
2
3
4
5
6
define service{
    use                  local-service
    host_name            localhost
    service_description  Current Load
    check_command        check_local_load!5.0,4.0,3.0!10.0,6.0,4.0
    }

これは、localhostに対して、ロードアベレージを監視するための設定です。

check_local_loadというプラグインを利用して、load1、load5、load15に対して、警告レベルの閾値と致命的レベルの閾値とを設定しています。


他の監視に関しても、設定ファイル内に、どのようなプラグインを利用して、それぞれのプラグインに合わせた閾値の設定を行うわけです。


設定ファイルで監視設定を行うことができるので、監視設定をコピーして新しく追加したホストに対して同様の監視設定を行うことが簡単にできます。


日本語対応

標準では未対応です。

Webのフロントエンドの部分であれば、個人で公開されている方がいらっしゃるので、その公開されているパッチを利用することで、主要部分を日本語化して表示することができます。
ただし、公式に日本語対応したパッケージが公開されているわけではないので、ソースからインストールして環境を構築する必要があります。


ライセンス

  • GPLv2

特徴

様々な監視用のプラグインを利用することで、様々な監視を行うことができるように容易に拡張することができます。


Nagios自体は、公開されてから10年以上経過しているので、利用者の様々なノウハウが蓄積されていますし、Nagios ExchangeもしくはIcinga Exchange、The Monitoring Plugins Projectなどのサイトで、各種監視用のプラグインが公開されているので、標準で用意されているプラグインでの監視で不十分であった場合に、これらのサイトで公開されているものが参考になる場合があります。


設定がテキストファイルであるので、監視する対象のサーバが追加された際には、同様のフォーマットで設定ファイルに追記するだけで対応可能であるため、元々、設定ファイルを自動生成して対応していた環境などでは、監視対象の追加や削除の対応がしやすいため、継続して利用されるところが多いようです。


Zabbixとの違い

Nagiosでは、1度の値取得処理で複数の値を取得することが可能です。


それに対して、Zabbixでは、1度のアイテム取得処理では1つの値しか取得できません。
そのため、ZabbixでNagiosのように1度に複数の値を取得するためには、zabbix_senderなどと組み合わせて、1つの値取得処理を契機に複数の値を取得して、zabbix_senderコマンドでZabbixサーバに複数の値を送るようなスクリプトを用意して対応することになります。


そういった対応をしないと、値を取得するタイミングがずれて、本来であれば、取得できる複数の値の合計が100になるはずであったものが105とか取得タイミングのずれによって発生した値の変化によって、合計値が想定していた範囲外になってしまう場合があります。


監視データの保管方法としては、Nagiosの標準ではテキストファイルに出力されるだけです。
Nagiosだけでは、グラフ化するなど過去のデータをそのまま活用することができません。


Zabbixでは、監視の為に取得したデータはDB上に保存されますし、標準の機能として、そのデータを利用してグラフ表示することができるため、時間帯などによる変動や長期間の傾向を把握しやすくなっています。


あと、Nagios Coreには、マルチテナントと呼ばれるような機能がありません。
Webフロントエンドを利用してサービスの提供状況を参照する際に、アクセスするユーザごとに参照できるサーバや機器を分割して制限をかける機能がないため、監視するサーバやサービス毎に別のNagiosサーバを構築して監視を行う必要があります。

認証機能を有効にすることで、そのNagiosサーバ全体に対して、プロセス情報や設定情報といった分類ごとへのアクセス制限をかけることは可能のようです。


Zabbixであれば、アクセスするユーザ毎に参照できる監視対象の情報を制限することができます。
この機能を利用して、1台のZabbixサーバで監視したとしても、ユーザ毎に各自の参照可能なサーバや機器群を指定しておくことができ、関係のないサーバや機器に関する情報を参照することができないようになっています。
つまり、1台のZabbixサーバで、複数のシステムやサービスを集約して監視することができます。

また、Zabbixであれば、APIが用意されているため、他システムとの連携も比較的容易に実現できるようになっていますが、Nagios Coreにはそのような機能が用意されていないため、他のシステムとの自動連携をさせるような場合は、そのための仕組みを別途用意する必要があります。


参考URL


※Zabbixはラトビア共和国にあるZabbix SIAの商標です。
その他、本コンテンツ内で利用させて頂いた各プロダクト名やサービス名などは、各社もしくは各団体の商標または登録商標です。