CDP:Monitoring Integrationパターン

モニタリングツールの一元化

解決したい課題

　システムの運用作業ではモニタリング（サービス/リソース監視など）は必須で、クラウドではモニタリングサービスが提供されている。しかし、クラウドのモニタリングサービスは仮想サーバー内（OS/ミドルウエア/アプリケーションなど）の監視はできないので、独自のモニタリングシステムは必要となる。そうなると利用するモニタリングシステムが複数となってしまい、運用（特に監視）の煩雑化が課題となる。

クラウドでの解決/パターンの説明

　仮想サーバーなどはクラウドのモニタリングサービスで監視し、OS/ミドルウエア/アプリケーションなどは自前の仕組みで監視する。 クラウドのモニタリングサービスはAPIを提供しているので、自前のモニタリングシステムで、クラウドのモニタリングサービスからAPIを介して情報を取得し、クラウド側も含めた一元管理が可能となる。

実装

　EC2上に監視ソフトをインストールし、AWSのモニタリングサービス「CloudWatch」からモニタリング情報を取得する。

• 監視ソフト（Nagios、Zabbix、Muninなど）を導入する。
• CloudWatchのAPIを用いてモニタリング情報を取得し、監視ソフトに情報を書き込むプラグインを用意する。
• そのプラグインを用いてクラウドからの情報も含めたモニタリングを行う。

構造

利点

• OS/ミドルウエア/アプリケーションと同じ形式の監視を、クラウドリソースに関しても行うことができる。
• CloudWatchにおけるデータの保存期間は2週間であるが、監視ソフトにデータを取り込むことで、長期間のデータ保持が可能となる。
• クラウドリソースの状態通知に関しても、監視ソフトを利用することで、メール文面などをカスタマイズできる。

注意点

• 監視ソフト（のプラグイン）が定期的にAPIを介してCloudWatchからデータを取得するため、その分のAPI利用料が必要となる。

その他

• AWS CloudTrailを使用すると、サービスやリソースの監視以外に、AWSの各種サービスの操作（例えばEC2の起動/停止の操作、VPCの設定変更）のログを指定のS3バケットに出力できるため、このログを利用して不正利用の監視も行う事ができる。

寄贈したアーキテクト

Ninja of Three