AWSでもZabbixを使うべき?EC2監視におけるメリットや手順を改めて解説。

    OSSの統合監視ツールとして高いシェアを誇る「Zabbix」。オンプレミス環境で多く利用されてきたツールですが、AWS環境での活用事例も多いようです。

    AWSにも「Amazon CloudWatch」といった監視サービスがあるにもかかわらず、Zabbixを利用する理由は、どこにあるのでしょうか?EC2インスタンスなどの監視におけるメリットや、設定手順などを改めて解説します。

    Amazon CloudWatchではなく、Zabbixを利用する理由

    AWS環境では、インフラに関してはすべてAWS側で運用されますが、EC2インスタンス自体の運用、および、その上に構築したアプリケーションなどは、利用者が責任をもって運用する必要があります。つまり、アプリケーションがきちんと稼働していることを監視し、異常が発生した場合の対処は、利用者自身で行わなければならない、ということ。そこで、監視を行うためのツールとして有力候補となるのが「Zabbix」です。

    Zabbixは、オンプレミスに加えて、クラウド環境・仮想環境などを統合的に監視できることが特長。Amazon CloudWatchの標準では、AWSリソース(CPUやメモリなど)の監視に限定されるのに対し、Zabbixでは、アプリケーションの状態まで細かく監視することが可能です。そのほか、Zabbixならではのメリットを整理しました。

    複数AWSアカウントの環境も統合的に監視

    Amazon CloudWatchでは、AWSアカウント単位で監視を行います。Zabbixは、複数のAWSアカウントの環境、すなわち複数のアカウントから構成される業務システムを統合的に監視できます。また、閾値による単純なアラートだけではなく、複数の閾値や条件によって複合的に異常を検知することも可能です。

    運用の実態に即した、細かな通知設定が可能

    Amazon CloudWatchは、異常発生時にはメッセージで通知することができます。例えば、メンテナンスによるシステム停止であれば、メッセージ通知は不要のはず。そこでZabbixでは、こういったケースを細かく設定でき、不要なメッセージを抑制することが可能になります。本当に対処が必要な異常時のみ通知することで、確実な対処につながります。

    メトリクス(監視ログ)の保存期限がない

    Amazon CloudWatchの場合、メトリクスの保存期限は最大15ヵ月。しかも、15ヵ月保存できるのは、1時間単位での監視のみであり、監視間隔を60秒未満に設定すると最大3時間までしか保存できません。Zabbixでは、情報の粒度を変化させずに、メトリクスを長期保存することが可能です。

    Zabbixで、AWS環境を監視するための手順

    AWS環境でZabbixを利用する場合、EC2インスタンス・DBインスタンスを作成し、そこへZabbixをインストールすることになります。インストール後の設定に関しては、基本的にオンプレミスと同じで、下記の内容を順次設定する流れとなります。

    1. ユーザアカウント(ZabbixのAdminユーザのほかに、運用で利用するユーザを作成)
    2. Zabbixホスト・エージェント(どこからデータを収集してくるかを設定)
    3. アイテム(どのようなデータを収集するかを設定)
    4. トリガー(データがどのような状態になったら異常かを定義)
    5. アクション(異常が発生した際に実行するアクションを定義)

    このほかAWS固有の設定として、AWS IAMでZabbix用に必要な権限をもったユーザの作成などを行えば、ZabbixでAWS環境のアプリケーションなどを監視できるようになります。

    監視ニーズにあわせたツールの使い分けを

    企業のシステムは、単体で動作するものばかりではなく、複数システムが連携してデータなどをやり取りし、全体として整合性を担保するものも少なくありません。こういった環境において、複数のサーバやシステムを横断して監視し、異常を検知できるZabbixは有効と言えます。例えば、DBを利用するWebアプリケーションにおいて、Webアプリケーションサーバに異常が発生した場合は、データを無効とする、といった対処も可能になります。

    一方で、Zabbixは設定項目が多く、なにをどのように監視し、どのような状態になったら異常なのか。また、その場合の対処まできっちり、運用を設計しなければなりません。もちろん、クリティカルなシステムなどではこういった設計が不可欠ですが、比較的簡易なシステムの「プロセスが停止したら、とりあえず再起動」といった対処を行うケースでは、Zabbixによる監視はアンマッチです。

    こういった場合に有効なのが「SIOS AppKeeper」。EC2インスタンス上で稼働するアプリケーションのサービス(プロセス)を監視し、異常時には該当するアプリケーションを再起動する。というシンプルな監視・運用を実現します。

    当然ですが、どのシステムでも「必ずZabbixを使わなければならない」わけではありません。監視の内容によって、適したツールを使い分けることで、より効率的な運用を実現できるのではないでしょうか。

    SIOS AppKeeperもぜひEC2の監視と復旧運用の選択肢に加えてみてください。

    SNSでもご購読できます。