【AWS】Amazon CloudWatch Logs でログ収集をやってみた

1.はじめに

初めまして、クラウド導入・運用サービスにて構築担当をしているサマタと申します。このようなコラムを記載するのは初めてで至らない点もあるかと思いますが、どうぞよろしくお願いいたします。

今回のコラムでは、AWSの運用サービスでも主要なAmazon CloudWatch(以下、CloudWatch)機能のひとつである、Amazon CloudWatch Logs(以下、CloudWatch Logs)についてご紹介したいと思います。

オンプレミス環境と同様に、AWS環境にインスタンスを構築した際も、サーバやアプリケーションのログ収集を行いたいという要望は多いのではないでしょうか。自分の経験でもログ収集に留まらず、ログ分析、監視などが組み込まれた要件を効率的に実行する手段に苦労したことがあります。

そんな中、AWSにはCloudWatch Logsというマネージドサービスがログ収集を行う機能として備わっており、収集はインスタンスのみならず、AWS内の主要なサービスはもちろん、エージェントツールのインストール、及び諸設定を行うことでAWSと接続環境にあるオンプレミスサーバのログも収集することができます。

収集したログはCloudWatchと連携してアラーム機能を発揮したり、別サービスを利用して、分析などを行うことに活用できます。ログ収集は単純なものであれば短時間にセットアップすることが可能であり、ログの保管量によって料金は発生するものの、AWSの運用管理を行ううえで利用しない手はないサービスといえるでしょう。

そこで、今回は最も基本的なインスタンスからのログ取得方法について、具体例からお試しいただけるような内容でご案内していきたいと思います。

2.CloudWatch Logsとは?

一言でいってしまえば、AWSが提供しているログ監視サービスです。主な機能を記載してみます。

  • インスタンスやサービスログの蓄積
  • ログのモニタリング
  • ログのフィルタリング
  • ログデータのアーカイブ
  • ログデータの分析 (CloudWatch Logs Insights)
  • ログのアラート化

このようにログ監視サービスとしての基本的な機能を兼ね備えています。加えてAWSサービスの一環のため、他のAWSサービスとの連携がとても簡単に行うことができるのが大きな特徴です。例えば、CloudTrailなどのマネージドサービスログも数ステップでログ取得対応をすることができ、逆に蓄積したログをKinesisへ投入してストリーミングするなどといったことも可能です。今回はインスタンスへの導入紹介となりますが、いずれ応用の機能紹介ができればと思っています。

3.インスタンス(EC2)のログ収集

冒頭に述べた通り、最も基本的なインスタンスからのログ取得方法をご紹介します。ここではAWS内にすでにインスタンスが設置されていると仮定して話を進めていきます。インスタンスの基本情報は以下のとおりです。

  • インスタンスタイプ:任意
  • OS:Amazon Linux 2
  • 導入ミドルウェア:Apacheをインストール済
  • 取得希望ログ:Apacheのアクセスログ、エラーログを収集したい

今回はWebサーバとしてPublicIPアドレスを持ち、インターネット接続可能な状態であると仮定します。CloudWatchのようなAWSの抽象化サービスはVPC(仮想ネットワーク)の外側にあるAWS共通空間に存在しているため、インターネット接続環境を持たない閉域接続のサーバログ取得にはAWS PrivateLink(以下PrivateLink)が必要となります。PrivateLinkはVPCにインターフェイスVPC エンドポイントを作成することで利用できます。PrivateLink のトラフィックはインターネットを経由しないため、CloudWatchを初めとする抽象化サービスをセキュアでスケーラブルな方法で接続できます。PrivateLinkを利用した接続方法などは次回以降でご紹介できればと思います。

4.IAMロールの作成

対象となるインスタンスがCloudWatch Logsにアクセス可能とするために、EC2に割り当てるIAMロールを作成します。

AWSマネジメントコンソールにて「IAM」より「ロールの作成」画面に映ります。ユースケースの選択から「EC2」を選択し、「次のステップ:アクセス権限」をクリックします。

Attachアクセス権限ポリシーにて「CloudWatchLogsFullAccess」のポリシーを選択し、「次のステップ:タグ」をクリックします。タグの設定画面では任意のタグを入力し、「次のステップ:確認」をクリックし、確認画面でロール名などを設定します。問題なければ「ロールの作成」をクリックしロールを作成します。

作成後は対象のインスタンスを選択し、「アクション」→「インスタンスの設定」→「IAMロールの割り当て/置換」に進み、作成したIAMロールをEC2にアタッチしてください。

5.CloudWatch Logsエージェントのインストール

対象とするインスタンスにはCloudWatch Logsと連携するためのエージェントをインストールする必要があります。OSがAmazon Linux、Amazon Linux2の場合、以下のコマンドでパッケージインストールが可能です。

yum install -y awslogs

インストールが完了すると、/etc/awslogs の新規ディレクトリが作成されます。中には設定ファイルが格納されていますので確認してみましょう。

6.CloudWatch Logsエージェントの設定

CloudWatch Logsへログを排出可能となるように、CloudWatch Logsエージェントの設定を行いましょう。/etc/awslogs 内のawscli.confファイルがエージェントのコンフィグファイルとなりますので、下記を参考に編集します。基本的に編集箇所はリージョンのみで結構です。デフォルトではバージニアリージョン(us-east-1)となっているため東京リージョンを利用している場合はap-northeast-1に変更しましょう。

[plugins]
cwlogs = cwlogs
[default]
region = ap-northeast-1

続いて、ログの出力設定を行います。/etc/awslogs内のawslogs.conf ファイルを開きます。初期設定によっては下記のような /var/log/messagesのシスログ設定がデフォルトで入力されているので、こちらを参考に各設定値を解説します。

[/var/log/messages]
datetime_format = %b %d %H:%M:%S
file = /var/log/messages 
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/messages
[/var/log/messages]

こちらはログ転送情報を定義する任意のセクション名です。設定ファイル内で一意となるように設定してください。

datetime_format

ログからタイムスタンプを入手する日付フォーマットを指定できます。特に指定がなければデフォルトで結構です。

file

対象とするログファイルのパスをこちらに記述します。末尾にワイルドカードを使うこともできます。

buffer_duration

ログイベントのバッチ期間を指定します。最小値は 5000ms で、デフォルト値は 5000ms です。特に指定がなければこのままで結構です。

log_stream_name

CloudWatch Logsの送信先でのログストリーム名になります。指定した名前が存在しなければ作成されます。指定する場合は判別できるよう一意の名称にしましょう。定義済み変数として、{instance_id}、{hostname}、{ip_address}を使うことができます。

initial_position

ログファイルの読み込み開始位置を指定することができます。start_of_file(最初から全て)、またはend_of_file(新規のみ)を指定します。

log_group_name

CloudWatch Logs上にロググループとして表示される名前になります。わかりやすい名称をつけるとよいでしょう。先にCloudWatch Logsにて作成し指定することもできます。

デフォルトのシスログを取得したい場合はこちらの設定を編集したうえで残していただければよいのですが、不要であれば削除、または必要なログ情報に書き換えしてください。今回はApacheのアクセスログとエラーログを記録するため、以下のように設定しました。

[Apache_AccessLog]
log_group_name = Samata-TestSV_Apache
log_stream_name = {instance_id}_accesslog
file = /etc/httpd/logs/access_log
datetime_format = %a %b %d %H:%M:%S %Y
initial_position = start_of_file
buffer_duration = 5000

[Apache_ErrorLog]
log_group_name = Samata-TestSV_Apache
log_stream_name = {instance_id}_errorlog
file = /etc/httpd/logs/error_log
datetime_format = %a %b %d %H:%M:%S %Y
initial_position = start_of_file
buffer_duration = 5000

今回はSamata-TestSV内のApacheというアプリケーションを一つのロググループとし、その中にApacheログを集約する形式としていますが、環境によって管理しやすい方法を選んでみてください。

7.CloudWatch Logsエージェントの開始

設定ファイルを保存したら、最後にCloudWatch Logsエージェントのプロセスを開始します。OSにより起動コマンドが異なります。

Amazon Linux、CentOSの場合は下記のコマンドとなります。再起動する場合はstartをrestartとしてください。

service awslogs start

Amazon Linux2、RED Hat Enterprise Linuxの場合は下記のコマンドとなります。再起動する場合はstartをrestartとしてください。

systemctl start awslogsd

なお、awslogsエージェントの設定ファイルを変更した際には、変更を適用するためにエージェントのrestartが必要となりますので、ご注意ください。

8.CloudWatch Logsへの出力を確認

プロセスを開始したら、実際にCloudWatch Logsへログが出力されているか確認してみましょう。注意しておきたいのは、当然ながら実際のログが出力されていないと確認することができません。今回はApache(webアプリケーション)のログのため、以下を試行しておきましょう。

  • アクセスログ…対象となるwebページにアクセスしておく
  • エラーログ…存在しないディレクトリへアクセスしエラー出力しておく など

試行後、CloudWatch Logsへアクセスしてみましょう。設定したロググループが作成されていることが確認できます。

次にロググループの中身です。設定したログストリーム名でアクセスログ、エラーログのログストームが作成されています。

更にログストリームの中身を見てみましょう。こちらはエラーログとなりますが、対象サーバのログが抽出されて表示されているのを確認できます。アクセスログも同様となります。

9.おわりに

いかがでしたでしょうか。今回は対象インスタンスのCloudWatch Logsへの出力過程までをお伝えしました。CloudWatch Logs自体の設定や、PrivateLinkの設定、出力されたログの二次活用方法については次回以降でお伝えできればと思っています。

ご覧いただいたとおり、手順自体は非常にシンプルに、慣れれば5分10分程度でログ出力まで完了できます。グルーピングによる集約や管理も手軽に行えるため、AWSの運用管理ツールの一つとしてとても重宝する機能になっています。気になった方は是非一度お試しください。

以上、このコラムが皆さまの参考になりましたら幸いです。

Amazon Web Services(AWS)は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
本コラムに掲載のサービスや操作画面等は2020年6月時点の情報です。

移行準備段階で知っておくべきAmazon Web Servicesの
サービスを学び、具体的にクラウド検討を考える!

ネットワークからクラウドまでトータルサポート!!
NTT東日本のクラウド導入・運用サービスを確認してください!!

Amazon Web Services(AWS)、Microsoft Azureの
導入支援サービスのご相談、お問い合わせをお待ちしております。

ページ上部へ戻る