こんにちは マネックスラボのMです。
こういう構成でとあるログを取得しているのですが
ある日急にBigQueryに新しいログが登録されなくなってしまいました。
以前にも何度か止まってしまう事がありましたが、
その時はCloudWatchLogsのプロセスを再起動すると解消していましたので、
この時もまずはそれをやってみました。
/etc/init.d/td-agent restart
ですが解消しません。
次に考えたのがCloudWatchLogsの設定しているaws_key_idかaws_sec_keyがおかしくなってるんじゃないか説です。
cat /etc/td-agent/conf.d/xxx.conf <source> @type cloudwatch_logs tag タグ名 log_group_name ロググループ名 log_stream_name ログストリームプレフィックス use_log_stream_name_prefix true state_file トークン管理ファイル aws_key_id AWSキーID aws_sec_key AWSシークレットキー region リージョン </source>こんな設定ファイルがあるはずですが、ここに記載してAWSキーとかがおかしくなってるんじゃないか
ということで、作り直して設定を変えて、再度CloudWatchLogsのプロセス再起動をしてみました。
ですが解消しません。
ここらへんで一度ハマりまして
awsのCLIがinstallされてないからじゃないか、installしてみよう、とか
CloudWatch側のログストリームが大きくなりすぎて取得がタイムアウトになってるんじゃないか、とか
/etc/td-agent/td-agent.confでログレベルをtraceにして有効なログが出ないか、とか
終いにはCloudWatchのrubyを書き換えてどこまで進んでいるか細かくログ出すようにしてみたり、とか
やってみましたが、どれも解決につながるような有力な情報は得られませんでした。
ただ、rubyを書き換えて出したログで分かったことは
エラーとかが発生しているわけではなく、CloudWatchにログを取得しにいってはいるけど取得できていない。
ということです。
そしてログを取得する仕様を調べていると、先程の設定ファイルの
「state_file トークン管理ファイル」でログの取得箇所をトークンとして管理しており、
1MB単位で処理される、またそのトークンは24時間で無効になる。」
との情報も。（真偽不明）
24時間もログが出ないことはないけど、トークンがおかしくなってる可能性があるなら
トークンを直してみれば良いんじゃないか。というのが次に考えたことです。
とはいえ正しいトークンを取得して直すなんてことはどうやら出来ないようなので、
トークンファイルを削除したら自動的に復旧する仕組みである。
という近くのエンジニアの言葉を信じて消してみました。
rm 「state_file トークン管理ファイル」全て
ここでついに解消しました。
ただし、ログが止まってから解消するまでの間のログは復旧しませんでした。
実際、ここにたどり着くまでに5日ほど掛かったので、その間のログが失われた形です。
他に良い解決方法があったのか不明ですが
「CloudWatchLogsのプロセスを再起動してもダメだったら、state_fileで指定しているトークン管理ファイルを削除せよ」
というノウハウとなりました。
同様の事象にお困りの方はお試し下さい。
