COLUMN
【AWS】Amazon CloudWatch Logs でログ収集をやってみた
クラウドに関する情報満載のNTT東日本メールマガジンはこちらからご登録ください。
1.はじめに
初めまして、クラウド導入・運用サービスにて構築担当をしているサマタと申します。このようなコラムを記載するのは初めてで至らない点もあるかと思いますが、どうぞよろしくお願いいたします。
今回のコラムでは、AWSの運用サービスでも主要なAmazon CloudWatch(以下、CloudWatch)機能のひとつである、Amazon CloudWatch Logs(以下、CloudWatch Logs)についてご紹介したいと思います。
オンプレミス環境と同様に、AWS環境にインスタンスを構築した際も、サーバやアプリケーションのログ収集を行いたいという要望は多いのではないでしょうか。自分の経験でもログ収集に留まらず、ログ分析、監視などが組み込まれた要件を効率的に実行する手段に苦労したことがあります。
そんな中、AWSにはCloudWatch Logsというマネージドサービスがログ収集を行う機能として備わっており、収集はインスタンスのみならず、AWS内の主要なサービスはもちろん、エージェントツールのインストール、及び諸設定を行うことでAWSと接続環境にあるオンプレミスサーバのログも収集することができます。
収集したログはCloudWatchと連携してアラーム機能を発揮したり、別サービスを利用して、分析などを行うことに活用できます。ログ収集は単純なものであれば短時間にセットアップすることが可能であり、ログの保管量によって料金は発生するものの、AWSの運用管理を行ううえで利用しない手はないサービスといえるでしょう。
そこで、今回は最も基本的なインスタンスからのログ取得方法について、具体例からお試しいただけるような内容でご案内していきたいと思います。
またNTT東日本ではクラウド導入支援も行っております。まとめた資料はこちらよりダウンロードできます。
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の運用管理ツールの一つとしてとても重宝する機能になっています。気になった方は是非一度お試しください。
以上、このコラムが皆さまの参考になりましたら幸いです。
24時間365日対応可能なクラウド監視・運用代行で、あなたをシステム運用から解放します!
移行準備段階で知っておくべきAmazon Web Servicesの
サービスを学び、具体的にクラウド検討を考える!
ネットワークからクラウドまでトータルサポート!!
NTT東日本のクラウド導入・運用サービスを確認してください!!
RECOMMEND
その他のコラム
無料ダウンロード
自社のクラウド導入に必要な知識、ポイントを
この1冊に総まとめ!
あなたはクラウド化の
何の情報を知りたいですか?
- そもそも自社は本当にクラウド化すべき?オンプレとクラウドの違いは?
- 【AWS・Azure・Google Cloud】
どれが自社に最もマッチするの? - 情シス担当者の負荷を減らしてコストを軽減するクラウド化のポイントは?
- 自社のクラウド導入を実現するまでの具体的な流れ・検討する順番は?
初めての自社クラウド導入、
わからないことが多く困ってしまいますよね。
NTT東日本では
そんなあなたにクラウド導入に必要な情報を
1冊の冊子にまとめました!
クラウド化のポイントを知らずに導入を進めると、以下のような事になってしまうことも・・・
- システムインフラの維持にかかるトータルコストがあまり変わらない。。
- 情シス担当者の負担が減らない。。
- セキュリティ性・速度など、クラウド期待する効果を十分に享受できない。。
理想的なクラウド環境を実現するためにも、
最低限の4つのポイントを
抑えておきたいところです。
-
そもそも”クラウド化”とは?
その本質的なメリット・デメリット - 自社にとって
最適なクラウド環境構築のポイント - コストを抑えるための
具体的なコツ - 既存環境からスムーズにクラウド化を
実現するためのロードマップ
など、この1冊だけで自社のクラウド化のポイントが簡単に理解できます。
またNTT東日本でクラウド化を実現し
問題を解決した事例や、
導入サポートサービスも掲載しているので、
ぜひダウンロードして読んでみてください。
面倒でお困りのあなたへ
クラウドのご相談できます!
無料オンライン相談窓口
NTT東日本なら貴社のクラウド導入設計から
ネットワーク環境構築・セキュリティ・運用まで
”ワンストップ支援”が可能です!
NTT東日本が選ばれる5つの理由
- クラウド導入を
0からワンストップでサポート可能! - 全体最適におけるコスト効率・業務効率の改善を
中立的にご提案 - クラウド環境に問題がないか、
第3者目線でチェック
してもらいたい - 安心の24時間・365日の対応・保守
- NTT東日本が保有する豊富なサービスの組み合わせで
”課題解決”と”コスト軽減”を両立
特に以下に当てはまる方はお気軽に
ご相談ください。
- さまざまな種類やクラウド提供事業者があってどれが自社に適切かわからない
- オンプレミスのままがよいのか、クラウド移行すべきなのか、迷っている
- オンプレミスとクラウド移行した際のコスト比較を行いたい
- AWSとAzure、どちらのクラウドが自社に適切かわからない
- クラウド環境に問題がないか、第3者目線でチェックしてもらいたい
- クラウド利用中、ネットワークの速度が遅くて業務に支障がでている
クラウドを熟知するプロが、クラウド導入におけるお客さまのLAN 環境や接続ネットワーク、
クラウドサービスまでトータルにお客さまのお悩みや課題の解決をサポートします。
相談無料!プロが中立的にアドバイスいたします
クラウド・AWS・Azureでお困りの方はお気軽にご相談ください。