これまで「いまさら聞けないAWS」をテーマに、Amazon Web Service（以下、AWS）の中から『コスパ最高の「Amazon Glacier」は本当にお徳か？実際に計算してみた』『AWSのリソースが丸わかり！意外と知られていないConfigが運用保守に超絶便利』について紹介してきました。
今回は、構築したシステムを安定運用するために欠かすことのできないモニタリング環境の設定を、AWSの監視サービスAmazon CloudWatchの機能を利用する方法を紹介します。Amazon CloudWatchの機能のひとつ「CloudWatch Logs」を使います。
CloudWatch Logsでできること
CloudWatch Logsとは、AWSが提供しているログ監視サービスです。EC2インスタンスのOSログやアプリケーションログを収集し、リアルタイムでモニタリングします。
Amazon CloudWatchとは、AWSで実行するアプリケーションのモニタリングサービスです。（中略）Amazon CloudWatch を使用して、システム全体のリソース使用率、アプリケーションパフォーマンス、およびオペレーションの状態について可視性を得ることができます。これらの洞察を使用して対応し、アプリケーションのスムーズな動作を維持できます。
CloudWatch Logs では、主に下記のことができます。
- ログの蓄積（保存期間を設定できます）
- 特定文字のフィルタリング
- フィルタパターンに一致したものをグラフ化
- Amazon SNS（Simple Notification Service）と連携したアラート設定
また、以下のようにCloudWatch Logsで収集したログの後続処理をほかのAWSサービスに連携ができるので、ログ分析、可視化といったほかの処理を加えた使い方もできます。
- 収集したログデータをS3へバッチエクスポートする
- 収集したログデータをリアルタイムにLamdaで処理
- 収集したログイベントをリアルタイムにKinesisへ投入する
監視運用するにあたってひと通りの機能は揃っています。では、CloudWatch Logsを使ってApacheのエラーログの監視設定からアラート通知までの設定を試してみましょう。
Apacheのエラーログの検出
Step1 IAMロール、テストインスタンスの作成
- CloudWatch Logsを利用するには監視対象のインスタンスへCloudWatch Logs用のIAMロールを割り当てる必要があります。CloudWatch Logs用のIAMロールを作成します。
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "logs:*" ], "Effect": "Allow", "Resource": "*" } ] }［備考］
マネージメントコンソールからIAMロールを作成する場合は、でCloudWatch Logs用のポリシーを選択してください。- ロールの一覧画面から［新しいロールの作成］をクリック
- 今回は「TECH-AWS-CLOUDWATCHLOGS」というロール名を入力し［次のステップ］をクリック
- AWSサービスロールから［Amazon EC2］の右横の［選択］をクリック
- CloudWatch Logs用のポリシーにチェックを入れ、［次のステップ］をクリック
- 確認画面でロールの設定情報を確認後、問題なければ［ロールの作成］をクリックしロールを作成
- テスト用インスタンスを作成し、IAMロールを割り当てます。テスト用インスタンス作成する際、［インスタンスの詳細の設定］で先程作成したIAMロールをインスタンスに割り当てます。
※既存のインスタンスにIAMロールを割り当てることはできません。
- インスタンスが作成できたら、EIPを割り当てます。
※EIP割り当て手順は［Elastic IP アドレスをインスタンスに割り当てる］を参照してください。 - sshでログインし、以下のコマンドでApacheをインストールして起動します。
$ sudo yum install -y httpd $ sudo service https start - インスタンスのIPアドレス（http:/XXX.XXX.XXX.XXX）にアクセスし、Apacheの初期ページが表示されることを確認します。
Step2 CloudWatch Logsエージェントのインストール、設定、サービス起動
- 以下のコマンドで、テスト用インスタンスにCloudWatch Logsエージェントをインストールします。
$ sudo yum install -y awslogs ～省略～ ======================================================================================================================================== Package Arch Version Repository Size ======================================================================================================================================== Installing: awslogs noarch 1.1.2-1.10.amzn1 amzn-updates 8.8 k Installing for dependencies: aws-cli-plugin-cloudwatch-logs noarch 1.3.3-1.15.amzn1 amzn-updates 69 k Transaction Summary ======================================================================================================================================== Install 1 Package (+1 Dependent package) ～省略～ Complete! - awscli.confファイルの編集
AWS CLI設定ファイルを編集します。東京リージョンでCloudWatch Logsを利用するため、regionをap-northeast-1に設定します。/etc/awslogs/awscli.conf [plugins] cwlogs = cwlogs [default] region = ap-northeast-1 - awslogs.confファイルの編集
awslogs.confを開き、最後尾へ下記を追加し、Appacheのエラーログを転送するように設定します。
※デフォルトでは/var/log/messagesが記載されていますが、今回は監視不要なので記述を削除します。/etc/awslogs/awslogs.conf [/etc/httpd/logs/error_log] datetime_format = [%a %b %d %H:%M:%S %Y] file = /etc/httpd/logs/error_log buffer_duration = 5000 log_stream_name = {instance_id} initial_position = start_of_file log_group_name = /etc/httpd/logs/error_log［備考］
log_group_nameで指定した名前が、マネージメントコンソールで表示されますので、識別しやすい名前を設定してください。 - 以下のコマンドでawslogsサービスを起動します。
$ sudo service awslogs start Starting awslogs: [ OK ] - 以下のコマンドでawslogsサービスを自動起動するようにしておきましょう。
$ sudo chkconfig awslogs on $ sudo chkconfig --list awslogs awslogs 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Step3 マネージメントコンソールからCloudWatch上のログファイルを確認
- しばらくしてから、マネージメントコンソールからCloudWatchの画面から［ログ］をクリックすると、Apacheのエラーログが出力されています。
- ［ロググループ名］-［インスタンスID］の二階層構成になっており、監視対象ログが増えても管理しやすそうです。
- ［インスタンスID］をクリックすると、収集したログデータが確認できます。
※ログデータから特定文字の検索や表示日時、時刻を絞って表示できます。
Step4 メトリックスフィルターの設定
- CloudWatch Logsで検知させる文字列を設定します。ロググループ名の画面から、該当にチェックを入れ［メトリックフィルタの作成］をクリックします。
- フィルターパターンに検知させる文字列を記載します。今回はエラー404を検出するように設定します。「File does not exist」と入力し、［メトリックスの割り当て］をクリックします。
［備考］
［パターンのテスト］をクリックすればフィルターパターンにヒットするかのテストが可能です。 - ［メトリックス名］を入力し［フィルタの作成］をクリックしフィルタを作成します。今回は「test_word」という名前で作成します。
［備考］
［フィルタ名の名前］は「2」で入力したフィルターパターンを元に自動入力されますので、必要に応じて変更してください。 - メトリックスフィルタが作成されました。
- ブラウザからEC2インスタンスのIPアドレスに存在しないファイル名（http:/XXX.XXX.XXX.XXX/test01.htmlなど）でアクセスし、Apacheのエラーログを出力させます。
- 「4」の画面からでメトリックス名「test_word」をクリックします。
- 対象メトリックスにチェックを入れると、以下のようにフィルターパターン一致したものがグラフ化されます。
※見にくいですがグラフ右端の縦軸”1″のところに印がついています。
Step5 アラーム作成、メール通知
続いて、作成したメトリックスフィルタにアラームを設定しましょう。
- CloudWatchダッシュボードからログをクリックし、メトリックスフィルタが［1フィルタ］と表示されている所をクリックします。
- メトリックスフィルタの画面が表示されますので、［アラームの作成］をクリックします。
- アラームの設定画面が表示されますので、ⅰ～ⅲの設定情報を入力し、［アラームの作成］をクリックするとアラートが作成されます。
- アラーム名、アラームの説明を入力
- アラームの閾値を設定
今回は、フィルターパターンに1回以上マッチしたらメールを送信 - 通知先のメールアドレスの設定。［新しいリスト］をクリックすると矢印のように送信先のメールアドレスを入力できる
［備考］
新たにメールアドレスを登録した場合は以下のような確認画面が表示されます。
送信先に設定したメールアドレスに以下のようなメールが届いているので確認用のリンクをクリックしましょう。
- アラートが作成されました。
- ブラウザからEC2インスタンスのIPアドレスに存在しないファイル名（http:/XXX.XXX.XXX.XXX/test01.htmlなど)でアクセスし、Apacheのエラーログを出力させます。
- 無事、アラートメールが送信されました！
CloudWatch Logsのメリット、デメリットまとめ
同じ監視サービスのZabbixなどと比べると、監視サーバを立てる必要がないため、ログ監視導入までの初期設定がサクっとできました。
Zabbixの場合、そもそも作成したサーバが監視対象として認識しないといったケース（Zabbixサーバ側の設定不具合）がありましたが、CloudWatch Logsの場合はそんな心配もありません。一方、Zabbixなど他の監視ツールに比べて料金が高いという声もあるので、そういった点はデメリットにあげられるかもしれません。
［メリット］
- ログ監視を開始するまでの設定が手軽
- 他のAWSリソースと連携した設定が可能
- 別途、監視サーバを立てる必要がない
［デメリット］
- Zabbixなど他の監視ツールと比較すると料金が割高になる
- 当然ながら物理サーバの監視はできない
気になるCloudWatch Logsの料金については下記の通りです。
1か月で100GBのログを取り込み、圧縮されて20GBになる（AWS側で圧縮される）とすると、計算式は下記となります。
100GB × 91.2円 ＋ 20GB × 3.96円 = 9200円
AWS以外のクラウド環境やオンプレミス環境を含めた総合監視する場合や、複雑な文字列を検知させたい場合はZabbixの利用が向いているかもしれません。監視すべき部分がAWS内で完結する場合や、簡易的なログ監視をサクっと設定したい場合はCloudwatch logsが便利だと感じました。
今回はApacheのエラーログ監視について紹介しましたが、AWS CloudWatchは他にも使い道がいろいろあります。何よりもAmazon CloudWatch自体は無料で始められ、無料利用枠内で利用できるアプリケーションも多数用意されています。AWSを活用している人はぜひAWS CloudWatchも試してみてください！
（記事提供：D2Cスマイル）
