Fly.ioでOSのログを収集する

初めに

Fly.ioはHerokuやGoogle Cloud Run のようなコンテナランナーで、安くて早くて簡単で、私のようなインフラ系の素養がない人間に個人開発プロジェクトや社内ツールの作成などで便利なのですが、
ログの収集 に関してはこの限りでなく、やや面倒です。

アプリケーションレベルのログであれば(比較的)簡単に収集できるのですが、OSやミドルウェアのログになるとやや工夫が必要だったのでまとめました。

Fly.ioのログ収集の実際

Fly.ioには　flyctl というCLIツールがあり、そこで flyctl logs と入力するとコンテナ内の標準出力もしくは標準エラー出力に吐き出されたLOGが閲覧できます。ただし、保存期間があり、3ヶ月分のログしか見えません。
また、コンテナに永続化ボリュームアタッチすることができ、そこにファイルでログを保存していけばいいように思いますが、実際はそのファイルをサルベージする方法がありません。
したがって、ログデータの収集は、AWS Cloudwatch Logsなど外部サービスへ転送することが前提となります。
幸い、有志によって Fly Io Logshipper というログ転送ツールが公開されています。こちらをFly.io上にデプロイするとほぼ自動でログが外部サービスへ転送できます。
詳しくは https://fly.io/blog/shipping-logs/
を参照してください。

OSログを収集するには

アプリケーションレベルのログであれば上記の通り、Fly.io Logshipper を使えばいいのですが、OSレベルのログを収集するにはいくつか手順を踏む必要があります。具体的には下記の通りです

• supervisord等によるコンテナのマルチプロセス化
• rsyslogをコンテナへインストールし常駐させる
• rsyslogから吐き出したログを標準出力に流すプロセス tail -f /var/log/hoge >> /dev/consoleを常駐させる

このようにすれば
rsyslog -> tail -f -> 標準出力 -> Fly.io Log Shipper -> 外部のログ収集サービス　という流れが完成しOSレベルのログを収集できるようになります。
（個別の設定方法についてはドキュメントを参照してください）

なお　課題として

• ログのエラーレベルが検知できず、外部の収集サービス上ですべてINFO扱いになる
• ログチャンネルの出し分けができない（私が知らないだけかもしれない）

という点があります、ただ全く収集できないよりはマシだとは思います。
また、マルチプロセス化とログ収集はsupervisordとrsyslogではなくsystemdだけでも実現できると思います。
その場合journalctl -f を/dev/consoleに流せばいいのでシンプルになりますね。（未検証）
補足になりますが、rsyslogから /dev/consoleに直接書き込む方法はrootユーザでないと権限の問題でできませんでした。

障害が発生した時に、調査しても原因がわからないということほど悲惨なことはありませんから、ログは取っておくに越したことはありませんね！