こんにちは。クルーズ株式会社CTOの鈴木です。
以前の投稿「脱レガシーシステム①（何からどう進めるか問題） 」のどうすすめるか？の部分でも少し触れたのですが、当社ではシステム品質向上のため週に4時間をリファクタリング作業に充てれる時間を設けています。
リファクタリング作業に対する支援として、PHPログ、アプリケーションログを一箇所で見れるようにしたというのが今回の話です。
いままでの運用
基本的に、必要な時に必要なサーバにSSHで接続してLinuxコマンドでごにょごにょしてみる。さすがにしんどいので一部のログについては、一か所のサーバに集約されてはいますが基本的には各サーバにSSH接続してみるというやり方でした。
上記とは別に特定のキーワード、例えば当社独自で定義しているエラーコードなどがログに記録された場合、監視ツールがアプリケーションログ監視としてアラートをSlackに発報する仕組みがあり、重大なアプリケーションエラーについては通知が受けれるという仕組みでした。
なので、まず大前提として本番環境については調査の依頼や不具合がない限り、開発者は能動的にログファイルを見ない（重要なものについてはアラート通知で気づけるようにしていて、それ以外は見ていない）。ログ件数の増減などについてもモニタリングができている状態になっていませんでした。
もう一つのログに関する問題
ログにまつわる問題としてはもう一つ大きな問題があって、PHPエラーログの設定でWarningを出さない設定がバッチなどの一部本番環境にされていたことです。
おそらくなのですが、リファクタリング作業を組織立って行う前のソースコード状態で1リクエスト中にWarning/Deprecated/Noticeを含めると多い場合300件ほどのログが出ていたので、これが全部本番のログとして蓄積されるとログファイルも肥大化するし見る側も雑音になるのでphp.iniの設定で出さなくしていたんじゃないかなと思います。
ただ、本来の考え方でいうとNoticeを含むエラーログについては0が望ましと考えていて、今回は雑音になるかもしれないけど出力してCloudWatchLogsに保管してみるときにフィルタリングするという形にしました。
Cloud Watch Logs 導入の効果
いちいちSSHで各サーバに接続せず、集約されたデータをCloudWatchLogsで見れることは言うまでもないですが、Deprecatedがどこで何件起こっているのかが把握できたことです。開発環境、検証環境は社内デバッグ用なのですべてのユーザ動線のログが取得できるわけではなく、次回のPHPバージョンアップまでにここを明確に解決しないとまずい！というのが分かるようになったことは大きかったです。
また「今、件数どのくらいあるの？」や「急にこのディレクトリでWarning増えてるんだけど、何かおかしいかもしれないからソースチェックしてみて」といった会話のように、エラーログ件数をモニタリングすることで、普段気づけないことを見つけ、ソースコードの品質向上につながるのではないかと期待をしています。
