Javaのログの使い方について

Question

実際の開発において、ログはどのように使われるのでしょうか。
ロガーの取得からログレベルに関連付けられたメソッドの呼び出しにより、ログファイルに情報を出力することまではわかりますが、具体的にどのように使うのかイメージがイマイチつかめません。
ケースバイケースだとは思うのですが、どのような使い方が一般的なので少雨か。
ロガーの取得のためのクラスを作成しておくのでしょうか。

また、あるクラス内において、情報を伝えるべきところでメソッドを呼び出して、ログファイルに書き込むのでしょうか。

回答お願いします。

Answer 1

業務アプリケーションの例でいうと、ログ出力するものは次の用途が多いでしょう。

• アプリケーション操作ログ(どの画面を表示したか)
• ログイン/ログアウト/セッション情報
• データ参照・登録・変更・削除の内容（全部ではなく一部）
• エラー発生時のスタックトレースやエラーメッセージ
• Javaのメモリ使用状況

他にも監視したい内容にあわせてログに出力するものを追加していきます。
ログ出力は システムからの返事の1つ ですので、ただログを出すだけではなく、

• 収集しやすいようにメッセージのルールを決める
• ログ出力を行うLog4Jなどのフレームワークではログレベルが設定できるので、出力するログの重大度にあわせてレベルを設定する
• メッセージのIDを振っておいて、集計しやすくする
• 処理にあわせてログファイルを分割する

などなど、いくつか工夫があります。
末永く使うアプリケーションやシステムであれば、ログの設計は運用フェーズも考えて構築します。

Answer 2

例えば、サーバー上で運用中のアプリケーションの動作を人間が直接確認することは難しいので、ログにエラーの情報などを出力しておくことで、後から問題の特定などを行うのに使用されます。
ファイルに記録を残しておけば、後から何があったかを調べることもできます。

コマンドラインやIDEを使って動作させている場合はスタックトレースが見られるので問題ないと思われるかもしれませんが、サーバーやGUIアプリの場合はそうはいきませんので、ログファイルで確認するしかありません。

エラーでなくても、特定のメソッドを通過した時に必要な情報を記録することもあります。

本番運用で必要の無い、開発時のデバッグだけで必要なログは、デバッグレベルで出力するようにしておき、本番では出力させないということもできます。

あと、念のため書いておきますが、上記のログの使い方はJavaに限ったことではありません。

ロガーの取得のためのクラスを作成しておくのでしょうか。

ケースバイケースです。
直接クラスでloggerフィールドを持たせる場合もありますし、
Webアプリのフレームワークなら、コントローラーやアクションで共通のロガーインスタンスを持っているものもあります。

また、あるクラス内において、情報を伝えるべきところでメソッドを呼び出して、ログファイルに書き込むのでしょうか。

ロギングライブラリーを使っているのであれば、ファイルに書き込むかどうかはあまり意識しません。

どういう情報を書き出すかはアプリの開発ポリシーに拠りますが、
少なくともcatchの中には書いたほうが良いですね。

Answer 3

技術的にログをどうやって出力するのか？どうやってロガーを取得するのか？とか、
そういう質問ではなく、出力したログを何に使うのか？って質問ですよね？
これはJavaがどうとかはなく、プログラミング言語は関係のない共通の話になります。

どういう基準で何のためにログを出しているか？というのを分かっていない技術者は非常に多いです。
ログの重要性を知るには、システム保守で一度地獄を見るのが手っ取り早いです。

ログはリリース後に、そのシステム担当者が困らないようにするためのものです。
出力するログの場所や内容を技術者依存にしているプロジェクトがとっても多いですが、
基本設計で決めておくべきものぐらいに僕は思っています。
非常にセンスがいるものです。

運用中のシステムで不具合があった場合などに、ローカル環境とは違ってデバッグとかできませんし、
気軽にDBの中身を見にいったりとかもできなかったりします。
本番システムの調査の頼みの綱はログなんです。

例えば、StackTraceは当然出すのですが、それだけ出していてもチンプンカンプンな時も多いのです。
なぜなら、どういうエラーが起きたかという事実が分かっても
なぜ起きたか？どういうシチュエーションで起きたか？などが分からなければ、
あんまり意味ないからです。
作った人が見れば、StackTraceだけで分かることもあるかもしれませんが、
保守担当者は時代とともに変わっていくものです。

何とかクラスの123行目で、NumberFormatException!! とかだけ言われても困るでしょう？

なので、ユーザーの操作を追えるようにしておくことが重要になってきます。
どのユーザーがどの画面のどのボタンを押したかなどを出力していくのです。

しかし、ユーザーIDと画面やボタンの情報だけでは、
複数のブラウザで並行して使われたりしていた場合、チンプンカンプンになりますので、
セッションIDも出力しておくなども重要です。

SQLでINSERTやUPDATEする場合には、値の内容をログに出力しておくなども役に立ちます。
「何だか分からないけど、とにかくこのSQLの実行でエラーが起きている！」
みたいな状況は地獄です。

あとログが重要になってくるのがバッチ処理です。
処理がどこまで進んだのか？何件のレコードまでは完了しているのか？
失敗したレコードはどれなのか？なぜ失敗したのか？

このような事が分かっていれば、とりあえず失敗したレコードだけ手動で処理しておいて、
原因調査を急げー！のようなこともできるわけです。
システムの使用を止めないというのはすごく重要です。
業務アプリであれば業務を止めない。ゲームなどであれば、課金できない時間を作らないなど。
止めるのは修正したものをリリースする時だけが望ましいです。

バッチでエラーが起きた場合などは、担当者にメールを送信して知らせたりなどもしますが、
こういうのもログの考え方と同じです。
リリース後の運用で困らないようにするためのものです。

じゃぁとりあえず何でもかんでもログに吐いておけばいいのか？というと
そういうわけにもいかなかったりします。
ファイルのI/Oというのはコストのかかる処理なので、
過度なログ出力はパフォーマンスに影響が出てきます。
それに加えてディスクサイズの圧迫も心配です。

あと、個人情報やパスワード、カード番号などはログに出したらダメです。
末端の派遣プログラマーにログを任せておくと、こういう心配もあります。

この辺は今回の話とは少しそれますので触れませんが、ログは超重要です！！ってことですｗ

Answer 4

エラーが発生した時に発生した場所とエラー内容をログに出力することはよくありますが、まず、何の目的の為にどの情報をログを取得するべきか考えましょう。