CloudWatch Logs Agent の挙動について調べたことのまとめ #AWS

公式ドキュメントに記述されているFAQの翻訳みたいになってしまいましたが、
CloudWatch Logsを実際使うに当たって、CloudWatch Logs Agent の挙動について調べたことのまとめです。

設定ファイルについてはこっちにまとめました。

設定ファイルを変更したので、設定を反映させたい

設定ファイル/var/awslogs/etc/awslogs.confに以下の記述がありました。

NOTE: A running agent must be stopped and restarted for configuration changes to take effect.

configを再読み込みさせる場合は、Agentのrestartが必要そうです。
condrestartとかは無いみたいですね。

ファイルのローテーションについては、以下の条件であればサポートされます

3はちょっとわかりずらいのですが、ログローテートのルールとして日付でインクリメントしていくようなパターンを想定しているようです。
/var/log/message-20140808 の後に、/var/log/message-20140809が作られるような場合が該当しますね。

ドキュメントに、

Creating a new file with a common pattern as the old one.

って書いてあるけど、common patternってどこまで許容されるの？って思い、ソースを見てみました。

ログ送信の対象となるファイルを選定する実装は、以下に記述されています。
/var/awslogs/lib64/python2.6/site-packages/cwlogs/push.py

ざっくり言うと、パスにマッチしたファイル一覧の中から、変更日付の一番新しいファイルに対して処理を行うようです。

ちょっとだけ具体的にすると、こんな感じでした。

こんな感じで、ローテートしても同じストリームにログが流れるようになっているみたいです。

ログイベントはある程度まとめてバッチされるのですが、
1回のバッチで、容量(32k)、件数(1000件)、時間(24h)の制限があるようで、
以下の条件にハマるとバッチされるようです。

cwlogs/push.pyのEventBatch classを確認するのが手っ取り早いです。

PutLogEvents API には制約があり、以下のような場合にスキップされるようです。

適当にログファイルにログを突っ込んで挙動を確かめてたら上記の3に該当し、
ログ送信されなくて若干ハマりました。

ちなみにemitされない場合は、/var/log/awslogs.logに
きちんとログが出力されるので安心（？）です。

state_file が利用可能で、最後にAgentを起動してからログローテートされてなければ、停止した所から再度pushし始めるとのこと。

逆に言うと、ローテートされていた場合は、ローテートされる前のファイルに対して何かしらリカバリーしないとですね。
重要なログは、ちょっと注意が必要そう。

Configuring multiple log sources to send data to a single log stream is not supported.

Log Streamの運用を考えている時に思いついたのですが、サポートされてませんでした。

IAMポリシーで、DescribeLogStreams, PutLogEventsのみを許可するようにすればいいみたいです。