いまさら聞けないAWS:エラー検出からアラートまで5ステップでできるCloudWatch Logs
こんにちは、技術開発部 園部です。
これまで「いまさら聞けないAWS」をテーマに、Amazon Web Service(以下、AWS)の中から「Amazon GlacierとS3の連携」「リソースの構成変更履歴を管理するAWS Config」について2回に渡ってご紹介しました。
いまさら聞けないAWS:Amazon GlacierとS3の連携―ご利用は計画的に
https://www.d2c-smile.com/201605137062
いまさら聞けないAWS:AWS Configを活躍させよう―あまり知られてないけども
https://www.d2c-smile.com/201607117426
今回は、構築したシステムを安定運用するために欠かすことのできないモニタリング環境の設定を、AWSの監視サービスAmazon CloudWatchの機能を利用して行う方法を紹介してみようと思います。使うのはAmazon CloudWatchの機能のひとつである「CloudWatch Logs」です。
検証:Apacheのエラーログを検出させてみた
1. IAMロール、テストインスタンスの作成
2. CloudWatch Logsエージェントのインストール、設定、サービス起動
3. マネージメントコンソールからCloudWatch上のログファイルを確認
4. メトリックスフィルターの設定
5. アラーム作成、メール通知
CloudWatch Logsでできること
CloudWatch Logsとは、AWSが提供しているログ監視サービスです。
EC2インスタンスのOSログやアプリケーションログを収集し、リアルタイムでモニタリングします。
Amazon CloudWatchとは、AWSで実行するアプリケーションのモニタリングサービスです。(中略)Amazon CloudWatch を使用して、システム全体のリソース使用率、アプリケーションパフォーマンス、およびオペレーションの状態について可視性を得ることができます。これらの洞察を使用して対応し、アプリケーションのスムーズな動作を維持できます。
引用元:https://aws.amazon.com/jp/cloudwatch/
CloudWatch Logs では、主に下記のことができます。
・ログの蓄積(保存期間を設定できます)
・特定文字のフィルタリング
・フィルタパターンに一致したものをグラフ化
・Amazon SNS(Simple Notification Service)と連携したアラート設定
また、以下のようにCloudWatch Logsで収集したログの後続処理を他のAWSサービスへ連携させることができ、ログ分析、可視化といった他の処理を加えた使い方もできますね。
・収集したログデータをS3へバッチエクスポートする
・収集したログデータをリアルタイムにLamdaで処理
・収集したログイベントをリアルタイムにKinesisへ投入する
ひとまず、監視運用するにあたってひと通りの機能は揃っているようです。
では、CloudWatch Logsを使ってApacheのエラーログの監視設定からアラート通知までの設定を試してみましょう。
Apacheのエラーログを検出させてみた
① CloudWatch Logsを利用するには監視対象のインスタンスへCloudWatch Logs用のIAMロールを割り当てる必要があります。
CloudWatch Logs用のIAMロールを作成します。
[備考]
マネージメントコンソールからIAMロールを作成する場合は、でCloudWatch Logs用のポリシーを選択してください。
ⅰ.ロールの一覧画面から[新しいロールの作成]をクリックします。
ⅱ.ロール名を入力し[次のステップ]をクリックします。
今回は「TECH-AWS-CLOUDWATCHLOGS」と言う名前のロールを作成します。
ⅲ.AWSサービスロールから[Amazon EC2]の右横の[選択]をクリックします。
ⅳ.CloudWatch Logs用のポリシーにチェックを入れ、[次のステップ]をクリックします。
ⅴ.確認画面でロールの設定情報を確認します。
問題なければ[ロールの作成]をクリックしロールを作成します。
② テスト用インスタンスを作成し、IAMロールを割り当てます。
テスト用インスタンス作成する際、[インスタンスの詳細の設定]で先程作成したIAMロールをインスタンスに割り当てます。
※既存のインスタンスにIAMロールを割り当てることはできません。
③ インスタンスが作成できたら、EIPを割り当てます。
※EIP割り当て手順は下記を参照下さい。
[Elastic IP アドレスをインスタンスに割り当てる]
http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/GettingStartedGuide/getting-started-assign-eip.html
④ sshでログインし、以下のコマンドでApacheをインストール⇒起動します。
⑤ インスタンスのIPアドレス(http:/XXX.XXX.XXX.XXX)にアクセスし、Apacheの初期ページが表示されることを確認します。
① 以下のコマンドで、テスト用インスタンスにCloudWatch Logsエージェントをインストールします。
② awscli.conf ファイルの編集
AWS CLI設定ファイルを編集します。東京リージョンでCloudWatch Logsを利用するため、regionをap-northeast-1に設定します。
③ awslogs.confファイルの編集
awslogs.confを開き、最後尾へ下記を追加し、Appacheのエラーログを転送するように設定します。
※デフォルトでは/var/log/messagesが記載されていますが、今回は監視不要なので記述を削除します。
[備考]
log_group_nameで指定した名前が、マネージメントコンソールで表示されますので、識別しやすい名前を設定してください。
④ 以下のコマンドでawslogsサービスを起動します。
⑤ 以下のコマンドでawslogsサービスを自動起動するようにしておきましょう。
① しばらくしたら、マネージメントコンソールからCloudWatchの画面から[ログ]をクリックしてみると・・・。
Apacheのエラーログが出力されています。
[ロググループ名]-[インスタンスID]の二階層構成になっており、監視対象ログが増えても管理しやすそうです。
[インスタンスID]をクリックすると、収集したログデータが確認できます。
※ログデータから特定文字の検索や表示日時、時刻を絞って表示することができます。
① CloudWatch Logsで検知させる文字列を設定します。
ロググループ名の画面から、該当にチェックを入れ[メトリックフィルタの作成]をクリックします。
② フィルターパターンに検知させる文字列を記載します。今回はエラー404を検出するよう設定します。
「File does not exist」と入力し、[メトリックスの割り当て]をクリックします。
[備考]
[パターンのテスト]をクリックすればフィルターパターンにヒットするかのテストが可能です。
③ [メトリックス名]を入力し[フィルタの作成]をクリックしフィルタを作成します。
今回は「test_word」という名前で作成します。
[備考]
[フィルタ名の名前]は②で入力したフィルターパターンを元に自動入力されますので、必要に応じて変更してください。
④ メトリックスフィルタが作成されましたね。
⑤ ブラウザからEC2インスタンスのIPアドレスに存在しないファイル名(http:/XXX.XXX.XXX.XXX/test01.htmlなど)でアクセスし、Apacheのエラーログを出力させます。
⑥ ④の画面からでメトリックス名「test_word」をクリックします。
⑦ 対象メトリックスにチェックを入れると、以下のようにフィルターパターン一致したものがグラフ化されます。
※見にくいですがグラフ右端の縦軸”1″のところに印がついています。
続いて、作成したメトリックスフィルタにアラームを設定してみましょう。
① 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側で圧縮される)とすると、計算式は下記となります。
AWS以外のクラウド環境やオンプレ環境を含めた総合監視する場合や、複雑な文字列を検知させたい場合はZabbixの利用が向いているかもしれませんが、監視すべき部分がAWS内で完結する場合や、簡易的なログ監視をさくっと設定したい場合はCloudwatch logsが便利だと感じました。
今回はApacheのエラーログ監視について紹介しましたが、AWS CloudWatchは他にも使い道がいろいろあるかと思います。何よりもAmazon CloudWatch 自体は無料で始めることができ、無料利用枠内で利用できるアプリケーションも多数用意されています。AWSを活用している方はぜひAWS CloudWatchも試してみてください!