エラーのログレベルを適切に設定しよう！
こんにちは！ツクリンク株式会社でRailsエンジニアをしています田口です！
本記事はツクリンク プロダクト部 Advent Calendar 2023 15日目の記事になります！
ツクリンクではエンジニアのLT会をほぼ毎週開催しています！
特に発表のノルマがあるわけではなく、発表したいことがある人が気軽に発表できる場になっています！
社内だけではなく社外のエンジニアさんに参加していただくこともあります！
そんなLT会で私が以前、エラーとログレベルについての発表したことがあったのでその内容をここで記事として書かせていただきます。
※ fukabori.fmでtwadaさんが話していたことが勉強になったのでその内容を元にしています。
例外処理は複雑になりがち
例外やエラーのハンドリングは、最も複雑性の高いもののひとつと言われています。例外処理は多くのパターンが存在し、エラーを適切に処理しないとコードが複雑になるからです。また、例外やエラーもコードの一部であり、呼び出し側のコードでハンドリングする必要があります。
（プロダクトによってはエラーハンドリングにかかるコード量がプロダクションレベルの全体の半分くらいになり場合もあるようです…）
エラーを適切に処理する
エラーハンドリングはエラーの種類や回復可能性に応じて設計する必要があります。一概にエラーと言っても様々な種類が存在するからです。
例えば、外部要因による通信系のエラーだと何度かリトライすれば回復する可能性がありますし、プログラミングミスによるエラーだとリトライしても回復する可能性が低いのでエラーハンドリングの方法を変える必要があります。
エラーのログレベルを適切に設定する
また、エラーのログレベルを適切に設定し、問題の重要度に合わせてログを出力することが重要です。
ログレベルの種類
Debug → 開発時やデバッグ時に使用され、開発者だけが参照する情報（JavaScriptでいうconsole.logと同様の役割）。
Info → 正常なプロセスの進行状況を示すログ。特に問題がなくタスクが成功した場合に記録される。バッチ処理のステップごとにInfoログを出力することがある。
Warn → 準正常な状況を示すログで、処理は正常に終了したが、何か異常があったことを警告するために使用される。例えば、ファイルが存在しないが、この問題を握りつぶして処理を続行した場合などに記録される。
Error → エラーや例外が発生したときに出力されるログ。エラーハンドリングの一部として、エラーをキャッチしたときにこのレベルのログが生成される。
Critical / Fatal → 人間の介入が必要で、即座に対処が必要な状況を示すログ。致命的なエラーやシステムの停止など、緊急の問題を示すために使用される。
ツクリンクで実際におこなった対応
ツクリンクでは、エラーハンドリングを効果的に行うためにSlackに専用のチャンネルを設置し、重要な通知をするようにしています。本来であれば、このチャンネルはWarn、Error、Critical/Fatalレベルの通知に限定されるべきですが、Infoレベルと見られる通知も混在していたため、エラーの早期発見の妨げになることもありました。この問題に対応するために、通知内容を見直し、通知先を分ける専用のメソッドを導入しました。これにより、Infoレベルの通知は別のチャンネルへ送信されるようになりエラー通知の精度を向上させ、早期の対応を可能にしました。
最後に
正確な通知の分類と適切なチャンネルへの配信により、エラーに効果的に対応することができるようになりました！
このような改善への取り組みの積み重ねで、組織全体のパフォーマンスを向上できれば良いなと思っています！
明日からもツクリンクのアドベントカレンダーが公開されます！よかったらみてください！
一緒に働いていただける仲間も絶賛募集中です！
この記事が気に入ったらサポートをしてみませんか？