困った
ルートデバイスボリュームのディスク容量の検知があり、なぜか/var/log/awslogs.log が圧迫していました。
運用としてルートデバイスとは別にEBSを追加し、アプリケーションのログも含めそちらに/var/log/以下にシンボリックリンクを張っていたのですが、CloudWatch Logs エージェントのログは/var/log/以下に直接出るのでそうした対応を出来ておらず、圧迫されつつありました。
(ちなみにcodedeploy-agentとかは/var/log/aws/以下にあり、1クッション挟んでくれていたりします。)
原因:圧迫する一例
ログを見てみると、アプリケーションのログに改行が発生しており datetime_formatのWARNINGで埋められておりました。だめなログの量に引っ張られて、awslogs.logも圧迫してしまっていたという状況のようです。
(略) - cwlogs.push.reader - WARNING -(中略) reason: timestamp could not be parsed from message.
参考:【小ネタ】AWS Lambdaで複数行のログを送るときの挙動を調べてみた
対応方針
そもそも論なので参考リンクに記載の通りログをちゃんとするのが良いのですが、圧迫は目の前に迫っているからアラートな訳でして、アプリケーションの変更を加えず一旦何とか対応をしたい場合があります。
ログの出力箇所変更
暫定対応、かつ自己責任のもとログの出力箇所を変更しました。
こちらについて、現状では以下のファイルを修正する他に方法は無いようです。
(略)
exec /usr/bin/env -i HTTPS_PROXY=$HTTPS_PROXY HTTP_PROXY=$HTTP_PROXY NO_PROXY=$NO_PROXY AWS_CONFIG_FILE=/etc/awslogs/awscli.conf HOME=/root /bin/nice -n 4 /usr/bin/aws logs push --config-file /etc/awslogs/awslogs.conf --additional-configs-dir /etc/awslogs/config >> /var/log/awslogs.log 2>&1
(略)
ここに直接指定されているので、書き換えます。
awslogsを再起動することで反映されます。
これで暫定対応ができました。
logrotateの変更
と思ったら、logrotateの設定にも直接ログのパスが記載されてしまっているので、こちらも書き換える必要がありました。
(略)
/var/log/awslogs.log {
(略)
今度こそ、無事に暫定対応ができました。
もちろん最初からちゃんとするのが良いのですが、運用って そういうときもあるよね という気持ちが大事かなと思います。