第6章 ログとメトリクスの集約（CloudWatch）
複数のEC2インスタンスを運用するようになると、1台ずつSSHでログやリソース状況を確認するのは非効率になります。Amazon CloudWatchを使って、ログとメトリクスを集約する考え方を扱います。
CloudWatchの2つの役割：メトリクスとログ
CloudWatchメトリクスは、CPU使用率のような数値データを時系列で記録する仕組みです。EC2では追加設定なしの基本監視（5分間隔）と、追加料金がかかる詳細監視（1分間隔）が選べます。ただし、メモリ使用率やディスク使用率は、ハイパーバイザー側からは見えない情報のため、EC2の標準メトリクスには含まれていない、という点に注意が必要です。CloudWatch Logsは、アプリケーションやOSが出力するログファイルを集約して保存・検索できるサービスです。
CloudWatchエージェントの導入
メモリ使用率やアプリケーションログなど、標準メトリクスに含まれない情報をCloudWatchに送るには、amazon-cloudwatch-agentというエージェントをインストールする必要があります。設定ファイル（既定で/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json）で、どのログファイル・どのメトリクスを送信するかを定義し、インスタンスのIAMロールにはCloudWatchAgentServerPolicyなどの権限が必要です。
$ sudo yum install amazon-cloudwatch-agent # Amazon Linuxの例
$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
-a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.jsontailやgrepによるログ調査は1台ずつの作業になりがちですが、CloudWatch Logs Insightsというクエリ機能を使うと、複数インスタンス分のログをまとめて横断検索できるようになります。
CloudWatch Logs Insightsでは、独自のクエリ構文でログを絞り込み・集計できます。たとえば、複数台のWebサーバーのログをまたいで、直近1時間のエラーログを新しい順に並べたい場合は、次のようなクエリを書きます。
/* CloudWatch Logs Insightsのクエリ例 */
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20このfilter・sort・limitといった構文は、これまで学んできたgrep・sort・headをパイプでつないだ処理と発想が近く、複数のログファイルを串刺しで検索できる点が大きな違いです。
アラームによる自動的な通知
メトリクスを集約するだけでは、異常が起きたときに気づくのが遅れてしまいます。CloudWatchアラームは、あらかじめ決めたしきい値をメトリクスが超えたときに、自動的に通知やアクションを発生させる仕組みです。たとえば「CPU使用率が5分間90%を超え続けたら、SNS（Simple Notification Service）経由でメールを送る」といった設定ができます。これまでのオンプレミス環境で、監視ツールがしきい値超過を検知してアラートを飛ばす仕組みを構築していた場合、考え方はそのまま流用できます。
# CPU使用率が80%を超えたらアラームを発報する例（概念的なコマンド）
$ aws cloudwatch put-metric-alarm --alarm-name high-cpu-usage \
--metric-name CPUUtilization --namespace AWS/EC2 \
--statistic Average --period 300 --threshold 80 \
--comparison-operator GreaterThanThreshold --evaluation-periods 1ログの保持期間の設定
CloudWatch Logsに送られたログは、既定では無期限に保存され続けます。ログの量が増えるとストレージコストもかさむため、ロググループごとに保持期間（7日・30日・1年など）を設定し、不要になった古いログを自動的に削除する運用が一般的です。これは、Linuxのlogrotateで古いログを世代管理・削除する発想と共通しています。
ダッシュボードによる可視化
複数のメトリクスを1画面にまとめて確認したい場合は、CloudWatchダッシュボードを使います。CPU使用率・ディスク使用率・エラーログの件数といった複数のグラフを1つの画面に並べておけば、障害発生時にサーバーへ個別にログインしなくても、まずダッシュボードを見るだけで全体の状況を素早く把握できます。Linuxで複数のコマンドを1画面にまとめて表示するwatchコマンドや、tmuxで複数のペインを並べて監視する運用の、AWS上での発展形と捉えると理解しやすくなります。
この章のまとめ
CloudWatchにはメトリクス（数値データ）とログ（テキストデータ）という2つの役割があること、メモリ使用率などは標準では取得できずエージェントの導入が必要なこと、しきい値超過を検知するアラームの仕組み、そしてログの保持期間を適切に設定する重要性を押さえました。次章では、EBS・インスタンスストア・S3というストレージの使い分けを扱います。