Amazon CloudWatch エージェントでログを再収集する方法
目次
序章
CloudWatchエージェントは、AWSから提供されているカスタムメトリクスやログを収集するソフトウェアです。
ログはCloudWatch Logsに保存されますが途中で設定変更した場合、既存のログは引き継がれずに変更後に出力されたログのみ収集します。
ログ冒頭から再収集したいことがあり検証した結果をご紹介したいと思います。
現時点で公式ドキュメントに情報がなく、非推奨の可能性がありますので試す場合は自己責任にてお願い致します。
前提
今回は下記のようなCloudWatchエージェント設定ファイルにてログを収集しています。
{
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/etc/httpd/logs/access_log",
"log_group_name": "/aws/ec2/BLOG/OLD/access_log",
"log_stream_name": "{instance_id}"
}
]
}
}
}
}
CloudWatchエージェントでの具体的なログ収集方法は割愛します。
事象の確認
まず前提の設定でログファイルがCloudWatch Logsに出力されることを確認します。
※分かりやすいように [連番].html でリクエストしています。
サーバ(EC2)側でも同じログが出力されていることを確認します。
# cat /etc/httpd/logs/access_log
[14/Nov/2025:11:29:59 +0000] "GET /1.html HTTP/1.1" 200 3
[14/Nov/2025:11:29:59 +0000] "GET /2.html HTTP/1.1" 200 3
[14/Nov/2025:11:29:59 +0000] "GET /3.html HTTP/1.1" 200 3
[14/Nov/2025:11:29:59 +0000] "GET /4.html HTTP/1.1" 200 3
[14/Nov/2025:11:30:00 +0000] "GET /5.html HTTP/1.1" 200 3
その後、CloudWatchエージェント設定ファイルを下記のように修正します。
※log_group_nameのOLDをNEWに変更しています。
{
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/etc/httpd/logs/access_log",
"log_group_name": "/aws/ec2/BLOG/NEW/access_log",
"log_stream_name": "{instance_id}"
}
]
}
}
}
}
CloudWatchエージェント設定ファイルを適用するため、CloudWatchエージェントを再起動します。
# systemctl restart amazon-cloudwatch-agent
このままではCloudWatch Logsにログが保存されないので、HTTPアクセスしてログ出力させ、CloudWatch Logsの新しいロググループを確認してみます。
6~10.htmlは存在しますが、旧ロググループに存在していた1~5.htmlは存在しません。
# cat /etc/httpd/logs/access_log
[14/Nov/2025:11:29:59 +0000] "GET /1.html HTTP/1.1" 200 3
[14/Nov/2025:11:29:59 +0000] "GET /2.html HTTP/1.1" 200 3
[14/Nov/2025:11:29:59 +0000] "GET /3.html HTTP/1.1" 200 3
[14/Nov/2025:11:29:59 +0000] "GET /4.html HTTP/1.1" 200 3
[14/Nov/2025:11:30:00 +0000] "GET /5.html HTTP/1.1" 200 3
[14/Nov/2025:11:42:19 +0000] "GET /6.html HTTP/1.1" 200 3
[14/Nov/2025:11:42:19 +0000] "GET /7.html HTTP/1.1" 200 3
[14/Nov/2025:11:42:19 +0000] "GET /8.html HTTP/1.1" 200 3
[14/Nov/2025:11:42:20 +0000] "GET /9.html HTTP/1.1" 200 3
[14/Nov/2025:11:42:20 +0000] "GET /10.html HTTP/1.1" 200 3
サーバ側のログは1~10.htmlまで1ファイルで揃っているので、新しいロググループには既存ログが保存されていないことが分かります。
ログ再収集方法
CloudWatchエージェントではどのログファイルがどれぐらいCloudWatch Logsへ送信したか記録したファイルがあり、まずはそのファイルを特定します。
# ls -l /opt/aws/amazon-cloudwatch-agent/logs/state/
total 4
-rw-r--r--. 1 root root 36 Nov 14 11:42 _etc_httpd_logs_access_log
Linuxの場合「/opt/aws/amazon-cloudwatch-agent/logs/state/」配下のファイルを確認します。
※Windowsの場合は「C:\ProgramData\Amazon\AmazonCloudWatchAgent\Logs\state\」配下
今回は1ファイルのみですが、複数ある場合を考慮して見つかったファイルの中身を確認します。
# cat _etc_httpd_logs_access_log
581
/etc/httpd/logs/access_log
0-581
2行目に対象ファイルのパスが記載されているファイルが目的のファイルです。
特定できたらまずはCloudWatchエージェントを停止します。
# systemctl stop amazon-cloudwatch-agent
次に新しいロググループまたはログストリームを削除します。
最後に特定したファイルの削除とCloudWatchエージェントを起動します。
# rm -f /opt/aws/amazon-cloudwatch-agent/logs/state/_etc_httpd_logs_access_log
# systemctl start amazon-cloudwatch-agent
そうすることでログをすべて新しいロググループに送信させることができます。
該当ファイルに関する推測
先ほどファイルを特定するためにファイルの中身を確認しました。
# cat _etc_httpd_logs_access_log
581
/etc/httpd/logs/access_log
0-581
581という数値は最初ログファイルの行番号かと思いましたが、今回は10行しかないため行数では合いません。
# ls -l /etc/httpd/logs/access_log
-rw-r--r--. 1 root root 581 Nov 14 12:12 /etc/httpd/logs/access_log
ログファイルのサイズと合致するため、1,3行目で送信する行数を制御していると思われます。
CloudWatchエージェント ログ再収集（まとめ）
ロググループが分かれてしまうとインサイトによる分析がしにくくなったり、ログの出力頻度が極端に低いログですと再設定以降ロググループの確認が難しくなるので、最終手段として個人的に使いたいと考えています。
今回ご紹介した CloudWatchエージェントの設定をはじめ、ターン・アンド・フロンティアでは AWS をご利用されているお客様に技術的なご支援が可能ですので、ご興味のある方はお問い合わせフォームよりお気軽にご相談ください。
元記事発行日： 2026年01月28日、最終更新日： 2026年01月20日
