〜 図書館の本の整理係とメモ係の連携を理解しよう 〜
copytruncate 方式を使う！
CloudWatch Logsエージェントと最も相性が良い
create 方式はファイルが変わるため、エージェントの追跡が切れる可能性あり
create方式を使う場合はfile_fingerprint_lines設定で対応可能
logrotate.conf と CloudWatch エージェント設定の両方をチェック！
あなたは図書館の館長です。図書館では毎日の出来事を日誌に記録しています。
この日誌の管理方法と、それを常に読んでメモを取る秘書さんの連携を考えてみましょう。
図書館の日誌は毎日どんどん増えていきます。
整理係は定期的に古い日誌を片付けて、
新しい日誌を用意する仕事をしています。
秘書さんは日誌を常に監視して、
新しい内容が書かれるたびに
すぐにクラウド上の本部にメモを送信します。
整理係は日誌の内容をコピーして別の場所に保管した後、
元の日誌の中身を空にするけど、同じ日誌帳を使い続ける。
秘書さんは同じ日誌を見続ければOK！
整理係は古い日誌を別の棚に移動して、
新しい日誌帳を用意する。
秘書さんは「あれ？どの日誌を見ればいいの？」と迷う！
| 確認項目 | copytruncate | create（デフォルト） |
|---|---|---|
| 📁 ファイルのinode保持 | ✅ 保持される | ❌ 変更される |
| 👀 エージェントの追跡継続 | ✅ 自動継続 | ⚠️ 設定が必要 |
| 📊 ログの欠損リスク | ⚠️ コピー中の書込みは欠損 | ✅ 欠損なし |
| ⚙️ 追加設定の必要性 | ✅ 不要 | ⚠️ fingerprint設定推奨 |
| 🔄 ローテーション後の動作 | ✅ シームレスに継続 | ⚠️ 再検出が必要 |
| 💡 推奨シナリオ | CloudWatch連携時に推奨 | 高精度ログが必要な時 |
/var/log/myapp/*.log { daily # 毎日ローテーション rotate 7 # 7世代保持 compress # 古いログを圧縮 delaycompress # 1世代前から圧縮 missingok # ファイルがなくてもエラーにしない notifempty # 空のファイルはローテーションしない copytruncate # ⭐ CloudWatch連携に重要！ }
copytruncate を指定することで、CloudWatch Logsエージェントが 同じファイルを追跡し続けられます。アプリケーションの再起動も不要です。
# CloudWatch Logs Agent 設定 [/var/log/myapp/application.log] datetime_format = %Y-%m-%d %H:%M:%S file = /var/log/myapp/application.log buffer_duration = 5000 log_stream_name = {instance_id} initial_position = start_of_file log_group_name = /myapp/application # ⭐ create方式を使う場合は以下を追加 file_fingerprint_lines = 1-3 # ファイルの先頭1-3行で識別
ファイルの先頭数行をフィンガープリント（指紋）として使用し、 ローテーション後も正しいファイルを追跡できるようにします。 create方式を使う場合は必ず設定しましょう。
{
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/var/log/myapp/application.log",
"log_group_name": "/myapp/application",
"log_stream_name": "{instance_id}",
"timestamp_format": "%Y-%m-%d %H:%M:%S",
// ⭐ create方式対策
"auto_removal": true,
"retention_in_days": 14
}
]
}
},
"force_flush_interval": 5
}
}
統合CloudWatch Agentはファイルパスベースの追跡を行うため、 create方式でも比較的安定して動作します。ただし、 copytruncate方式を使う方がより確実です。
create方式でinodeが変わり、エージェントが古いファイルを追跡している
1. logrotateをcopytruncate方式に変更する
2. または、file_fingerprint_lines設定を追加
3. エージェントを再起動：
sudo systemctl restart amazon-cloudwatch-agent
エージェントの状態ファイルが破損、または複数のエージェントが同じファイルを監視
1. 状態ファイルを削除して再起動：
sudo rm /var/lib/awslogs/agent-state
2. 設定を見直して重複監視を排除
3. initial_positionをend_of_fileに変更
コピー中にログが書き込まれると、その分が失われる可能性がある
1. ログ出力が少ない時間帯にローテーションを実行
2. 高精度が必要な場合はcreate方式 + fingerprint設定
3. buffer_durationを短くしてリアルタイム性を向上
エージェントがログファイルにアクセスする権限がない
1. ログファイルの権限を確認：
ls -la /var/log/myapp/
2. エージェントユーザーを適切なグループに追加
3. logrotateでcreate設定に権限を指定
特別な理由がなければcopytruncate方式を選択。CloudWatch Logsとの連携が最もスムーズ。
logrotate -d でドライランを実行し、設定の動作を事前確認。
CloudWatch メトリクスで IncomingLogEvents を監視し、ログ停止を早期検知。
logrotateとCloudWatch Agent両方の設定をドキュメント化し、チームで共有。
月1回はログ収集が正常に動作しているか確認。特にローテーション前後。
OS側とCloudWatch側の両方で適切なログ保持期間を設定し、コスト最適化。
日誌の整理係
古いログを片付けて
ディスク容量を管理
メモ係の秘書
ログを監視して
クラウドに送信
ファイルの識別方法
inode vs ファイルパス
copytruncateが安心
🎯 最重要ポイント：
OSのログローテーション設定を変更する前に、
必ずCloudWatch Logsエージェントとの互換性を確認しよう！
迷ったら copytruncate方式 を選択すれば、
エージェントが同じファイルを追跡し続けられるので安心です 🎉
Created by SSuzuki1063
AWS SAP Learning Resources