ログ出力する内容について

Question

ログ出力する内容について

業務ロジックにおいて、ログ出力する内容ってどのようなものが効果的なのでしょうか？

処理続行できないようなマスタ不正や、DBデータ不正のようなエラー発生時は例外などでメッセージを出してしまうのが多いので、わざわざログ出力しなくても・・・とおもってしまいます。

デバッグは開発時には便利なのでこれはわかるのですが、本番時は使用しません。
アクセスログとかは必要ですが、業務ロジックとは別なので、業務ロジックにおいて、こんなログを出すと便利とかありましたら教えて頂けないでしょうか。

またログレベルの選定の1方針なども合わせて教えて頂けるとうれしいです。
昔みたのは画面のオペレーションで警告がある場合、warnで出力してエラーの場合はerrorで出力してたような気がします。

例えば一覧表示の中の項目の詳細をみようとして、すでに削除されていた場合（排他など）は警告メッセージを画面に出してwarnでログを出力する。
null参照など本来想定しないエラーの場合、エラーメッセージを画面に出してerrorでログを出力する。

ただ想定されるエラー（排他で削除されたデータを参照）をいちいちログ出力する意味はないと感じますし、null参照などのケースは例外のメッセージで十分な気がします。

それとも使い方が違うとかなのでしょうか？
例えば本来起こりえないエラーやユーザのオペレーションでは直らない（マスタ不正など）場合に、システム管理者が検知するためにログを出すなどでしょうか？

エラーがでたということを検知するためにログ出力を行って、例外時のメッセージは解析のために使うとかなんでしょうか？

onosuke · Accepted Answer

>業務ロジックにおいて、ログ出力する内容って
>どのようなものが効果的なのでしょうか？
単一の正解は存在しません。
業務要件、性能要件(レスポンス及び容量)、運用要件などの
バランスを考慮した上で規定するのが一般的です。

セキュリティ(完全性)を求めるシステムでは、
業務トランザクションのログトレースが行えることが要件となったりもします。
・アクセスログで追跡可能なように考慮しておく
・TPモニタ導入等、ミドルウェアで解決する手法をとる
などもありますが、
・業務ロジックのログ出力で管理する
方法もよく利用されます。

システム利用状況の管理手段として、
アクセスログからの解析が難しい情報を出力させることも多いです
# 事前の運用設計が甘い場合に、追加要件となりがち。
# 事前に考慮していれば簡単なことも、
# 事後対応では対処が難しい、でよくある話の筆頭かも。
・ログインセッション数の把握
・想定エラーによるトラン破棄発生数の把握
　（→詳細設計レベルの不備が原因で、頻発する場合があります）
など

onosuke · Answer

>どういう経路でthrowされた例外が
＞よく考えずにいましたが、例外をthrowした時は標準出力に
＞出力されるが、
Javaアプリケーションサーバの場合、
例外throwの出力先は、標準エラー出力です。
Javaの仕様に準じています。

＞サーバのログファイルに出力されているということは
＞サーバの標準出力の設定先がファイル指定されている
＞という認識で合っていますでしょうか。
標準エラー出力であること以外は、合っています。


＞どういう経路でthrowされた例外がサーバの
＞ログに出ていたのだろうかと・・・。
Javaアプリケーションサーバ(Tomcat)といえども、
起動は javaコマンド で
　 org.apache.catalina.startup.Bootstrapクラス
を呼び出しています。(クラス名はtomcat5.5の場合)
普通のJavaアプリと同じです。

従って、ログファイル指定の実態は、起動時に
 java .... >stdout.log 2>stderr.log
とリダイレクトしているだけですね。

# なお、WebLogicやWebSphere等のベンダー謹製APサーバの場合、
# このあたりを直接変更するのは禁止だったりします。

osu_neko09 · Answer

#2です。
Directory Proxy Server のログレベルの話を参考URLに示します。
選定の1方針として役立たないでしょうか。

ログファイルは用途別に分けておかないと、あとで見るのも大変ですから、最低でもデバッグ用と本番用のログは別ファイルにするとか、ログレベルで切り分けて本番実行時には出力しないのが当然だと思っています。
ですので、おっしゃるとおり、「想定されるエラー（排他で削除されたデータを参照）をいちいちログ出力する意味はない」と感じます。（少なくとも本番用のログには。）

＞「null参照などのケースは例外のメッセージで十分な気がします。」
出力する中身は例外のメッセージで十分かも知れませんが、これは本来起こりえないエラーですから、本番用のログに出力されるべき、ではないでしょうか。


私が以前関わったことのある某企業のシステムでは、当時、夜間にバッチ処理がかなりの数、実行されるということになっていました。
なので、それぞれのバッチ処理のログとは別に、監視用のログを一つ作って、こんな感じで出力しようという案がありました。
Windowsパソコンで言えば、こんな感じですね。
99/99　99:99 デフラグ　開始
99/99　99:99 デフラグ　正常終了
99/99　99:99 ウイルスチェック　開始
99/99　99:99 ウイルスチェック　正常終了　処理対象ファイル1,234,567件

＃このログを監視していれば、夜間バッチ処理が終わったか判るので、
＃異常があればその処理のログを見に行く、という考えですね。
＃諸般の事情で没になりましたが。


＃１さんのほうに書かれた疑問については、申し訳ないですが　詳しいことは判りかねます。
実行環境なり、別のところなり、に、コンソールに出力された内容がログに出力されるような機能がある、というのは考えられます。

参考URL：http://docs.sun.com/source/819-2016/ICLogs.html

osu_neko09 · Answer

エラーをログ出力するのは基本だと思いますが、正常動作しています、ということがわかるようにログを吐く場合もありますね。
処理開始～終了～処理件数を出力しておくとか。

ログ出力する内容について

>業務ロジックにおいて、ログ出力する内容って

この回答への補足

>どういう経路でthrowされた例外が

#2です。

エラーをログ出力するのは基本だと思いますが、正常動作しています、ということがわかるようにログを吐く場合もありますね。

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング