アプリケーションのログを読んだことはありますか？
多すぎるログは読まれなくなり、少なすぎるログは原因調査を難しくしてしまいます。
- ログが大量に出ていて重要な情報が埋もれてしまう
- ログが少なすぎ、障害の原因がわからない
こうした問題は、ログの量ではなく ログの設計 を意識することで改善できます。
ログレベルの基本
ログレベルは「重要度」を表していて、Spring Bootでは以下のようなレベルが使われます。
上から順に重要度が高くなります。
ERROR
処理が失敗した場合など、明確な異常が発生したときのログです。例外が発生した場合はこのレベルで出力します。
WARN
処理は継続できるものの、想定外の状態が発生している場合に出力します。
将来的に問題につながる可能性がある状況です。
INFO
アプリケーションの通常動作を示すログです。
起動処理や重要な業務処理の開始・終了など、運用時に確認したい情報を出力します。
DEBUG
開発時の調査用ログです。処理の流れや変数の値など、詳細な情報を確認したいときに使用します。
TRACE
DEBUGよりさらに詳細なログです。メソッドの呼び出し順序など、かなり細かい処理の追跡に使われます。
重要なのは、ログレベルを「情報の量」ではなく 重要度 で決めることです。
INFOやDEBUGを乱用すると、本当に重要なログが埋もれてしまいます。
Spring Bootのログ設定
Spring Bootでは、デフォルトでLogbackがログライブラリとして使用されます。
特別な設定をしなくても、コンソールにログが出力される状態になっています。
ログレベルは application.yml で変更できます。
logging:
level:
root: INFOこの設定では、アプリケーション全体のログレベルをINFOに設定しています。
特定のパッケージだけログレベルを変更することもできます。
logging:
level:
root: INFO
com.example.service: DEBUGこの場合、アプリ全体はINFOですが、com.example.service パッケージだけDEBUGログが出力されます。
この設定は、開発時の調査で特定のパッケージだけ詳細ログを見たいときに便利です。
ログレベルを必要な範囲だけ変更することで、不要なログを増やさずに調査を進めることができます。
実務で使えるログ設計
実務では、ログは「あとから原因を調べるための情報」として設計します。
そのため、ログは単なるメッセージではなく 状況を再現できる情報 を残すことが重要です。
まず基本になるのは、例外ログの出力です。
try {
service.process(order);
} catch (Exception e) {
log.error("注文処理に失敗しました。orderId={}", order.getId(), e);
}例外ログでは、次の2つを必ず残します。
処理内容。
調査に必要な識別情報（IDなど）。
メッセージだけでは、どのデータで失敗したのか分かりません。
IDなどの情報を含めることで、後からデータを追跡できます。
また、ログは文章よりも「状況」を意識して書くと調査しやすくなります。
たとえば次のログは、情報が少なく調査が難しくなります。
ログイン処理を実行しました一方で、次のようなログなら状況が分かります。
ユーザーログイン処理 userId=123ログは、あとから読む人が「何が起きたか」を理解できる形で書くことが大切です。
本番環境では、DEBUGログを常に出すことはあまりありません。
DEBUGログは情報量が多いため、本番で出し続けるとログが膨大になります。
一般的には通常運用はINFO、調査時のみ特定パッケージをDEBUGに変更するケースが多いです。
Spring Bootではログレベルを設定で変更できるため、必要なときだけ詳細ログを出す運用が可能です。
ログは多ければよいわけではなく、必要なときに必要な情報を取り出せること が重要です。
まとめ
ログは単なる出力ではなく、運用と調査のための重要な情報です。
そのため、ログレベルの意味を理解し、重要度に応じて適切に使い分けることが大切です。
Spring Bootでは application.yml でログレベルを簡単に変更できるため、
通常はINFOで運用し、必要なパッケージだけDEBUGを有効にする方法がよく使われます。
ログメッセージには処理内容だけでなく、IDなどの識別情報を含めることで、あとから原因を追いやすくなります。
ログ設計を意識しておくことで、障害発生時の調査や運用が大きく楽になります。
コメント