　そもそもログってなに？

システムにおいてログはとても重要です。
それをもとにシステムがどのように動いているかを確認し、
おかしな動きをしていないかを確認したり、誰が何をしているかを確認するわけです。

でもプログラマーのあなたに突然、「実装画面でログを出してくださいねー」、とだけ言われたとしましょう。

何を出力すればいいの？？

ってなりませんか？
デバッグ用に仕掛ける分には自分の好きなように埋め込めば良いですが、

製造工程が終わったとき・・・。どのログを残せばいいのやら？
「例外をcatchしたここは、、、エラーログで良いのかなぁ。。。」
「ここって業務的にプログラムの内部でしか見えない処理だけど、
ログ出しておいた方が良いよね？」

今回はそういう話なんですが、、ググってみたところ、僕の求めている内容の記事が少なく、
他の方々がどういった観点を持っているのかを知りたいとともに、
なにかしら皆さんの助けになればと思い、書いています。

突っ込みどころがあれば、コメントなどでレスをいただければと思います。

　ログ観点

・業務要件を満たしていること

つまりは、お客さんの要望を全て満たしているということですね。
ここの画面はこういうこと出して欲しい。ここのアクセスはユーザーＩＤとか使用しているブラウザとか
IPアドレスとか全部出力して欲しい。とか。
ホントにお客さんによって要望はバラバラだとは思いますが、
その部分をヒアリングで吸出し、内容をまとめ、実装で盛り込めているか。。。といったところですかね。

・運用保守の際の障害の早期発見につながること

システム障害がすぐに発見出来るようなエラーログを出力するように心がける必要があります。
例えば、どの画面のどのプロパティなのか、どのビジネスロジックのどの処理なのか、など。
どこで、何をして、どうなったかがすぐに理解出来るようなログ出力が望ましいはずです。

・実装補助になること
AOP（横断的な処理）、つまりどのクラスでも定型的にログを出すであろう部分は共通化して
ログ出力してあげる事で実装の助けになります。
例えば、メソッドのスタートとエンド、インプットとアウトプットのパラメータなどです。

　出力形式

　　出力形式想定3パターン

　　　　①区切りなし
　　　　　　// 単純なメッセージとして出力します
　　　　②CSV
　　　　　　// 複数の出力カラムがある場合、かつ出力内にカンマが含まれていない場合など。
　　　　　　// CSVファイルとして抽出しやすいです
　　　　③TSV
　　　　　　// 複数の出力カラムがある場合、かつ出力内にカンマが含まれている場合など。
　　　　　　// Excelファイルなどで抽出しやすいです

　出力先

　　・コンソール（標準出力）
　　　　// これは開発中だけかもしれないですね。運用ではあまり確認しない部分です。
　　　　
　　・ファイル出力
　　　　// APサーバーログとして出力される。
　　　　// バッチに関しては別途DailyRollingFileAppenderなどでファイル出力を行う。

オンラインは障害発生時に画面でメッセージを確認し、APサーバーログでを原因を追跡、
バッチの場合はバッチのアプリログで障害を発見し、原因を追跡、といった感じでしょうか。

　　ログの種類

　アクセス

　　　　・アクセスログ
　　　　　　＞ユーザーID、IPアドレス、画面ID etc...
　　　　　　　　// フィルターやインターセプタで出力するのが理想的。共通クラスとして提供すべきです。INFOレベルが良いと思います。
　　　　　　＞遷移先画面（オンライン）
　　　　　　　　A画面からB画面に遷移しますというログ。共通Actionクラスで出力する。
　　　　　　　　これは実装時の補助なので、DEBUGレベルが良いと思われます。
　　　　　　＞フォーム名
　　　　　　　　共通クラスで出力するのが良いと思います（ActionServlertやRequestProcessorなどを継承する）。
　　　　　　　　実装補助なので、DEBUGレベル。
　　　　・メソッド等の開始-終了ログ
　　　　　　　　// インターセプタやフィルタなどで共通化するべきです。
　　　　　　　　// これに関しては運用時の追跡にも利用出来るので、
　　　　　　　　// INFOレベルでも良いかもしれません。要件次第ですね。　　　　
　　　　・セッション管理
　　　　　　＞オンラインのセッション管理
　　　　　　　　// 共通クラスが行う。セッションが切れた場合にメッセージを出力。
　　　　

　　入出力情報

　　　　・インプット/アウトプットログ
　　　　　　＞メソッドのインプット情報と取得結果など
　　　　　　　　// インターセプタで共通クラスから提供する。開発・テスト用なので、DEBUGレベル。
　　　　　　＞リクエストパラメータ
　　　　　　　　フィルターやインタセプタで出力する。
　　　　　　　　
　　　　・SQLログ
　　　　　　＞SQL文、バインド変数、取得情報（取得情報、取得件数、登録件数、更新件数、削除件数）
　　　　　　　　/* SQL文と、バインド変数はDAO部品から共通的に出力するのが望ましいです。
　　　　　　　　 * 取得件数、登録件数、更新件数、削除件数に関しても出してあげると親切。
　　　　　　　　 */

　　異常動作

　　　　・エラーログ
　　　　　　＞例外のthrow
　　　　　　　　// statcktraceがログとしては残ると思います。共通クラス部品に関しては
　　　　　　　　// エラーとなったプロパティやオブジェクトなど、メッセージに最大限表示すると、追跡に便利です。
　　　　　　　　
　　　　・内部エラーログ
　　　　　　＞例外の握り潰しなど
　　　　　　　　// 発生しても問題ないような例外の握りつぶしは、必ずログとして出力する。
　　　　　　　　// WARNレベルなどが良いと思います。
　　　　　　　　
　　　　・異常系ログ（非throw）
　　　　　　＞業務上失敗しているが、例外throwしないもの
　　　　　　　　// 各業務実装で、WARN出力する。基本的にこういったケースは無いとは思いますが。。。

　　性能観点

　　　　・性能（パフォーマンス）ログ
　　　　　　＞SQLのパフォーマンス
　　　　　　　　// DAOの処理速度（CRUDの開始から終了）をミリ秒で出力する。　　　　　　　　
　　　　　　＞バリデーションのパフォーマンス
　　　　　　　　// 入力チェックの処理速度をミリ秒で出力する。　　　　　　　　
　　　　　　＞ビジネスロジックのパフォーマンス
　　　　　　　　// 全体の処理速度をミリ秒で出力する。
　　　　　　　　
　　　　　　＞その他、パフォーマンスを確認したいモジュール
　　　　　　　 // 他に何かありますかねー。。。

といった感じです。皆様、いかがでしたでしょうか。

結局、出力レベルは「運用上利用が必要か、実装時のみか」というのが重要ですね。

「これが足りないだろ」とか「これはこういうログの方が良い」とか
色々なご意見がありましたら、コメントなりtwitterでリプなどしていただけるとうれしい限りです！！

プログラマのはしくれダイアリー

cssmenu

2013/12/20

あなたはログに何を求める？【Webサイトにおけるログ出力観点】(what do you need ' logging ' for web system?)