ロギングについて - tomo

ぜひ１記事書いてください
— 高見知英 (@TakamiChie) 2020年11月2日

というわけで書く。

1、本当にエラーメッセージやらロギングの粒度がダメでエラーの本質がわからないパターン。
— くさば (@tomo_kusaba) 2020年11月2日

これにならないためにはどうしたらよいかについて。

ぶっちゃけ、Azure Application Insightsを使えるのならそれを使うのが一番よい。

不足なくログ取得が行えるし何よりもログ取得のためのコードをロジックのそこかしこにちりばめる必要がない。

あとで、ここのログが必要だったのにログ取得のコードが入ってなかったみたいなことがないのでよい。

以上の言語で記述されたアプリケーションで

以上の環境にホストされたものであれば検討Application Insightsの使用を検討すべきだと思う。

さて、ここからが本題になると思うのだが、諸般の都合でApplication InsightsやらCloud Watchなどのクラウドによるロギングができない場合は伝統的なロギングツールに頼ることが必要になると思う。

すなわち、.NETでいえば、log4netのような、Javaでいえばlog4jのようなツールである。

具体的なツールの使い方についてはここでは触れないがいずれもプロジェクトにツールを組み込み出力項目を設定ファイルなどで設定して実際のプログラムのなかでログを吐き出したい場所でログ出力メソッドを実行するものである。

log4net,log4jともに標準では同期実行しかサポートされていないのであまりに大量のログを出力しようとするとアプリケーションのパフォーマンスに影響がかなり出ることに注意が必要である。

以上は最低限出力するようにしましょう。（Log4netのデフォルト＋α）他に、バッチでは、処理予定件数、処理実績件数なんかも出力して差異がないかログ出力させてもよいかもしれません。

ログインID、アクセス元IPアドレスはポリシーによりけりかなとも思います。

クラウドを使用できないWebアプリケーションというのは大抵イントラにある社内アプリなのでこういった情報をロギングするのには問題が少ないのではないかと思っています。

原則、メソッドの開始・終了時

開始時には引数を出力するとよい。

終了時には戻り値を出力するとよい。

但し、ループ内で呼ばれることが想定されるメソッドについては考慮が必要。→大量にログ出力されるとパフォーマンスに影響。

また、本当に意味があるログなのかを見極める。

ループ内で落ちたとき、例外メッセージやスタックトレースでエラー本質を見極めることができるかどうか検討など。

また、例外発生時には例外のメッセージ及びスタックトレースが出力されるようにしておくことが重要。

例外発生時のスタックトレース情報がないと何も問題がわからないのでこれは困ったことになります。例外が発生しうる箇所は必ず一旦Cacheしておくのがよいのかなと思います。

そこから、エラーハンドリングの都合によってはまた呼び出し元にスローしてみたりそこでちゃんとエラー処理したりってことを考えていけばよろしいのかなと。

おそらく、これだけのログが出力されていれば何か起きたときに何が起きたのか全くわからないということはないのでしょうか？？