はじめに
前回の記事 では、CloudWatch Agentを使ってEC2のメモリやディスク使用率を可視化する方法を紹介しました。
今回は「ログの収集」について解説します。特にASG環境で運用している場合、ログ管理には以下のような特有の課題があります。
- EC2スケールインによるログの紛失: EC2インスタンスが自動的に終了すると、そのインスタンス内に保存されていたログファイルも一緒に消滅してしまいます。
- 調査の煩雑さ: 複数台のサーバーが稼働している環境でエラーが発生した場合、「どのサーバーで起きたのか」を特定するのは困難です。1台ずつSSH接続してgrepするのは現実的ではありません。
これらの課題は、CloudWatch Agentの設定にlogsセクションを追加し、ログファイルをCloudWatch Logsへリアルタイムに転送・集約することで解決できます。
今回はPHPアプリケーションのログ収集を例に、具体的な設定手順を紹介します。
設定ファイル (config.json)
前回のmetrics設定に加え、logsセクションを追加します。
| |
collect_listの構成を見てみましょう。
file_path
収集したいログファイルの絶対パスを指定します。「*」を使用して、ローテーションされるログなどをまとめて指定することも可能です。
「apache-action-[0-9]…log」のような正規表現も使用できますので、日付ローテーションされるログファイルを正確にターゲットし、無関係なファイルの誤送信が防げます。
log_group_name
送信先ロググループ
log_stream_name
ログイベントを識別するためのストリーム名 {instance_id} というプレースホルダーを使うことで、自動的に「i-1234567890abcdef0」のようなインスタンスIDに置き換わります。これにより、ASG環境でもログの混在を防げます。
timezone
ログが出力されているタイムゾーン(Local または UTC)が指定できます。システムログとアプリログのタイムゾーンを合わせるための設定です。
timestamp_format
ログ内の時刻フォーマットを指定することで、CloudWatch Agentがログ内の時刻を解析し、CloudWatch Log上の時系列表示になります。 指定しない場合は、EC2から転送された時刻が使用され、CloudWatch上の時刻は実際のログ時刻とのズレが生じてしまいます。
実装手順
手順はメトリクス収集時とほぼ同じです。設定ファイルの内容が変わるだけです。(すでに配置した場合は、ステップ3からで大丈夫です。)
IAMロールの作成
EC2インスタンスにアタッチされているIAMロールに、「CloudWatchAgentServerPolicy」と「AmazonSSMManagedInstanceCore」ポリシーが含まれる必要があります。
Agentのインストール
| |
SSMパラメータの更新
設定ファイルをSSMパラメータストアに登録すると、保守性が向上します。AWS CLIを使用する場合、以下のコマンドでアップロードできます
| |
設定の再読み込み
| |
パラメータの詳細説明は前回記事 を参照してください。
動作確認
ステータスが running になっていることを確認します。
| |
設定適用後、AWSマネジメントコンソールの CloudWatch > ロググループ で確認します。
設定した
{log_group_name}が表示されていることを確認します。ロググループに入ると、各EC2インスタンスIDごとのログストリームが作成されています。
ストリームをクリックすると、サーバー内のログが転送されていることが確認できます。
まとめ
CloudWatch Agentでログ転送を行うことで、サーバーが終了してもログがCloudWatch上に永続化されるようになり、障害調査や監査対応が非常に楽になります。
また、CloudWatch Logsに集約しておけば、CloudWatch Logs Insights という機能を使い、 「特定のキーワードを含むエラーログを、全サーバー横断で検索・集計する」といった高度な分析も可能になります。