このブログはエラー・ロギング Advent Calendar 2020 - Adventar18日目のブログです。
今回はプログラミングにおけるロギング処理について書いてみようと思います。
ロギングとは、プログラムの実行中にログを出力する処理。
1ファイルで完結する程度の簡単なプログラムならともかく、中規模のプログラムであれば、障害時の原因追跡のためにも、ログの出力は盛り込んでおきたい。
プログラムを組む段階では問題ないと思っていても、いざ開発を進めていくと、ログを出力していなかったせいで問題の原因がどこにあるか分からない なんてことは割とよくあることなのではないかと思います。
このためにも、プログラム作成に当たって、必要に応じてログを出力する というのは重要です。
ログ出力のタイミング
大抵のプログラム言語のロギング機能には、ログレベルというものがあり、ログの内容により以下の五つに分けられています
- DEBUG：デバッグ情報
- わたしの場合、メソッドの実行がはじまったときに使用しています。
- INFO：情報
- わたしの場合、繰り返し処理を実行する際の繰り返しカウンタや、大きな処理を実行する際の引数などの値を使用しています。
- WARNING：警告
- わたしの場合、連携している外部アプリの警告表示を出力しています。
- ERROR：エラー
- わたしの場合、メインのプログラム上で補足できなかった例外全般をこのログレベルで出力しています。
- 現状、エラー時に発生するプログラムのスタックトレースと、エラー文字列をそのまま出力しています。
- CRITICAL：致命的エラー
- いまのところわたしは使用したことがないです。
特に自分以外の誰かに使用してもらうアプリである場合、とくにログの出力は重要です。他者の関係では、自分でも全く想定していない問題が起こる可能性がありますので、問題の特定につながる様な情報はちゃんと出力しておきましょう。
ただし、過度な情報の露出には気をつける
ただし、最近のプログラムであれば、障害発生時に開発者環境にログを送信するなど、外部にログを送信する場合があります。
そのため、ログに個人の特定につながる情報を含めないようにすることは、常に気をつけておかなくてはいけません。
たとえばアプリのインストールされているディレクトリパスやレジストリの情報を取得した場合はその情報そのもの、設定画面での入力値などがそれにあたります。
そのような情報を含めないとバグの追跡が困難になる という場合もあると思いますが、少なくともWARING以上のログにはそのような情報を含めない というのは、常に気を使っておくと良いでしょう*1。
利用者にログの提出を求める場合
とくにわたしはPCの知識があまりない方とお仕事をしている場合が多いため、ログの提出をお願いしても、実際に送ってもらえるという可能性はほぼないと思っています。
OSやフレームワークにログを開発者に送信する機能がない場合、なんらかの方法でログを開発者に送付する機能が必要になるでしょう。
追ってこのブログで紹介するLogReporterオブジェクトを利用するなど、なんらかの施策は必要になるのではないかと思います。
わたしは現状、アプリでメイン処理の実行が終わる度にログを送付するようにしていますが、その辺はアプリとその利用シーンによって変える必要があるかなと思います。
ログに出力するもの、しないものを明確にする
外部に送信するにせよ、しないにせよ、ログに何を出力するのか、しないのかは常に意識しておく必要があります。やってみて障害追跡にたどり着くための情報が載ってなかったでは意味がありません。
わたし自身もそこまでログをもとに障害追跡をした経験がないので、あまりはっきりしたことは言えませんが、基本的には個人情報を載せず、プログラムに関係する挙動は積極的に載せる という方針でいると、障害の追跡には役立つと思っています。
*1:DEBUG、INFOレベルには個人情報に関わるログも出力するが、そもそもリリース版にはその情報を含めない など
