CloudWatchがあればZabbixとできること大して変わらないし
「CloudWatchでだいたいの要件は満たせそうですね。」
とおっしゃる方もいらっしゃるようですが私たちServerworksが、そして私伊藤がなぜZabbixをおすすめするのか今回はそのことについてお話ししたいと思います。
統合監視ができる
CloudWatchはあくまでもAWSの中の事象だけを見ます。
しかし実際のシステム運用ではAWSだけでなく他のクラウドシステムやオンプレミス、
クラウドとの接続ポイントとなるネットワーク機器など、監視すべき部分はAWSの中だけではありません。
そういった場合すべてを統合的に見られる監視ツールが必要となります。
またAWSの中だけであったとしてCloudWatchではアカウント毎に表示されることになります。
たとえば経費分割のために1つの会社で事業部毎に別々のAWSアカウントを運用している。
しかし監視・障害対応については専門の部署で一元的に行いたい、そんな場合にもやはり横断的に値を収集・監視できるツールが必要になるでしょう。
複合的な判定ができる
CloudWatchではCPUやネットワークトラフィックなど、Metrics毎に閾値を指定することができます。
ですがCPUとメモリの値を組み合わせた複合的な障害判定を行う事はできません。
Zabbixであれば取得した値を元に、さらに数値計算を行った結果を判定したり複数の値を組み合わせて障害判定を行ったりすることが可能です。
またシステム全体で統一的な閾値を設定しながら一部のインスタンスだけ閾値を変えたりという設定をCloudWatchで行うのはなかなか難しいのではないでしょうか。
Zabbixであればテンプレートとマクロを使うことによって統一的な一定水準の監視を行いながら個別の閾値などにも柔軟に対応することが可能です。
メンテナンス設定ができる
Zabbixではスケジューリングに基づいて通知を抑止する複数の機能があります。
たとえばインスタンスの定期再起動やバッチ処理に伴う一時的なCPU高負荷などを通知の対象からはずす事ができます。
これは障害監視システムがオオカミ少年にならないためにも必要な機能ではないでしょうか。
通知連携ができる
CloudWatchの場合、障害を検知した場合の通知先はAmazon Simple Notification Service（Amazon SNS）になります。
Amazon SNSからHTTPトリガーやAutoScalingアクション、メール通知などが可能です。
しかしその際に通知される通知文言は、ある程度固定されたものになります。
Zabbixの場合はメールやSMS、Jabberの他、任意のスクリプトや、監視対象のAgent自体とも連携することが可能です。
このため、CloudWatchと同じようにHTTPトリガーやAutoScalingを実行することもできますし、
さらにAPIによってインスタンスそのもののStop/Startや、インスタンス内部のプロセスなどに対してもリスタートなどのアクションを実行することが可能です。
また、SlackやTwitterなどの各種SNS（Social Networking Service）サービスとも連携することができます。
過去にさかのぼってデータを確認することができる
CloudWatchのメトリクスの保存期間は2週間ですがZabbixであれば、任意の日数保存することができます。
たとえば月次処理の負荷や季節キャンーペーンの負荷など1ヶ月や数ヶ月単位での負荷状況の違いを確認したい場合
Zabbixのように長期間にわたるデータの蓄積が必要になるでしょう。
さらにサーバーワークスでは、ZabbixAgentによる監視だけでなくCloudWatchのメトリクスをZabbixに集約する仕組みも構築しています。
CloudWatchのデータをより長期間にわたり蓄積することで、シーズンイベントなどに適した傾向分析を行うことも可能となります。
比較表
| 機能 | CloudWatch | Zabbix |
| 監視範囲 |
AWSサービス EC2のOS外部情報 |
OSの内部情報 ネットワーク |
| AWS以外の統合監視 | × | ○ |
| 複数のメトリクスを組み合わせた障害判定 | × | ○ |
| メトリクスの演算 | × | ○ |
| 閾値のテンプレートと個別変更 | △ | ○ |
| メンテナンス設定 | × | ○ |
| 障害通知 | Amazon SNS |
メール Jabber SMS 任意スクリプト |
| インスタンス制御 |
AutoScaling EC2制御 |
AutoScaling Cloud Automater連携 インスタンスOS上での任意コマンド実行 |
| 他システム連携 | Amazon SNS経由 |
任意スクリプト 連携ソリューション |
| データの保存期間 | 2週間 | 設定により長期間保持可能 |
まとめ
確かにAWS上のリソースの値を確認してAutoScalingやRoute53の切り替えをするだけであればCloudWatchだけでも十分な機能を持っています。
しかし実際の運用自動化や高度化、継続的なシステムの進化のためにはやはりZabbixのような長期的なデータ保持期間や
高度なシステム連携機能が必要になってくると私は考えています。
せっかくAWSを利用するのであれば、ITシステムだけでなく運用の自動化や高度化も検討されてはいかがでしょうか。
そのためにもZabbixとサーバーワークスは皆様の力になれると信じています。
またそうであり続けられるよう努力したいと思っています。
Zabbixの導入をご検討されている方、もっと効果的にZabbixを使いたいと考えている方、
ZabbixやAWSでお困りの方は是非サーバーワークスにご連絡ください！
追記
記事を読んでいただいた皆様から反応をいただきましたので、少し補足します。
CloudWatchはAWSを利用する上で必要な情報を提供してくれます。
だからこそサーバーワークスではZabbixAgentによる監視だけではなく、CloudWatchのメトリクス情報をZabbixに集約する仕組みを開発し利用しています。
しかしCloudWatchによるメトリクスの範囲はクラウドの仮想インフラとしての部分そしてマネージドサービスの範囲での情報です。
これはAWSの共有責任モデルにあるとおり、EC2インスタンス上のOSやその内部のアプリケーションの管理・監視・運用は利用者の責任となるからです。
custom metricsという手段もないわけではないですが、Zabbixほどの自由度・粒度でそれを構築することはかなりの手間を伴うことになるでしょう。
CloudWatchは必要だけれど「クラウドで世界をもっと働きやすく」をいうビジョンを実現するためにはCloudWatchだけではまだたりない。という事だと思います。
