- ベストアンサー
ログ出力の効果的な内容とログレベルの選定
- 業務ロジックにおいて、ログ出力する内容について効果的な方法を考えます。
- ログ出力はデバッグ時に便利ですが、本番時は使用しない方が良いです。
- ログレベルの選定には警告やエラーのような重要度で判断することが一つの方針です。
- みんなの回答 （4）
- 専門家の回答
質問者が選んだベストアンサー
>業務ロジックにおいて、ログ出力する内容って >どのようなものが効果的なのでしょうか？ 単一の正解は存在しません。 業務要件、性能要件(レスポンス及び容量)、運用要件などの バランスを考慮した上で規定するのが一般的です。 セキュリティ(完全性)を求めるシステムでは、 業務トランザクションのログトレースが行えることが要件となったりもします。 ・アクセスログで追跡可能なように考慮しておく ・TPモニタ導入等、ミドルウェアで解決する手法をとる などもありますが、 ・業務ロジックのログ出力で管理する 方法もよく利用されます。 システム利用状況の管理手段として、 アクセスログからの解析が難しい情報を出力させることも多いです # 事前の運用設計が甘い場合に、追加要件となりがち。 # 事前に考慮していれば簡単なことも、 # 事後対応では対処が難しい、でよくある話の筆頭かも。 ・ログインセッション数の把握 ・想定エラーによるトラン破棄発生数の把握 （→詳細設計レベルの不備が原因で、頻発する場合があります） など
その他の回答 (3)
- onosuke
- ベストアンサー率67% (310/456)
>どういう経路で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
- ベストアンサー率48% (56/115)
#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件 ＃このログを監視していれば、夜間バッチ処理が終わったか判るので、 ＃異常があればその処理のログを見に行く、という考えですね。 ＃諸般の事情で没になりましたが。 ＃１さんのほうに書かれた疑問については、申し訳ないですが 詳しいことは判りかねます。 実行環境なり、別のところなり、に、コンソールに出力された内容がログに出力されるような機能がある、というのは考えられます。
お礼
返事が遅れました。ごめんなさい。 確かにどこまで実行されたか分かると問題箇所の特定に繋がると、 最近試験をしていて感じました（他のグループが作った箇所 なので、どう動いているのかさっぱり分からなくてどこまで 正常に動いてるの～と）。 あと例外が発生する件については、昔のことなので確認できないのですが、 springのインターセプターで例外を取得したときの処理で ログを出していた・・・という可能性も最近思いました。 最近、そういうことができると知ったので・・・。
- osu_neko09
- ベストアンサー率48% (56/115)
エラーをログ出力するのは基本だと思いますが、正常動作しています、ということがわかるようにログを吐く場合もありますね。 処理開始～終了～処理件数を出力しておくとか。
お礼
なるほど。そういうログもあるのですね。 かなりな量になるかと思いますが、本番でも出力するようなレベルでしょうか。 それとも開発時のみのデバッグ的なログでしょうか。本番時だとすると、 ファイルを専用に持つような形と思ってよいでしょうか。 またもしよろしければ、onosukeさんの方に書かせて頂いた疑問について も頂けると幸いです。
お礼
アドバイス有難うございます。 処理には直接製係はないのですが、運用等で効果的なログがあるかないかでだいぶ違いますね。 単純なようで奥深く感じます。 アドバイス頂いた内容をきちんと理解できるようによく考えて見ます。 申し訳ありません。最初の質問に例外はログに出力されると自分で書いておきながら、 よく考えてみたらロガーで自分で出していないのに何でだろうと分からなくなりました。 eclipseではコンソールに例外情報が出ますが、結合試験環境でははサーバのログファイル に出力されていました。 よく考えずにいましたが、例外をthrowした時は標準出力に出力されるが、サーバの ログファイルに出力されているということはサーバの標準出力の設定先がファイル指定 されているという認識で合っていますでしょうか。 どういう経路でthrowされた例外がサーバのログに出ていたのだろうかと・・・。 もしよろしければご回答頂けると幸いです。
補足
それともスタックトレースも、私が知らない場所でアプリケーションの開発者が どこかで行っていて、自動的に出力するようなものはないのでしょうか。 今までlog.error("エラーメッセージ")などでログ出力を済ませていました。 何かあるとログAに上記が出力されるので、解析をはじめる感じでした。 詳細は解析時にスタックトレースが吐かれているログファイルをみて確認していたので、 スタックトレースは自動的に出るものと思っていました（ほんとうはもっと 考えてないといけなかったと思います）。