使いやすいログにするために気をつけること

Last updated at 2022-07-07Posted at 2022-07-07

概要

最近業務内でログを利用する機会が増え、このログ使いづらいなと思う点があったので記事として整理しました。

本記事では、問題・問い合わせがあった際の原因調査の用途でログを利用するものとして説明します。

※本記事で利用するログは、説明のために簡略化(タイムスタンプ、処理IDなどは省略)しています。

ログを問題・問い合わせの原因調査に利用する場合、当たり前ですが必要な情報が適切にログに出力されている必要があります。

ですが、以下のように情報が適切に出力されていない場合もあります。

例として、ECサイトにおいて商品区分単位で商品の売上を集計するバッチから出力されるログについて考えます。

INFO 商品区分売上集計 {"id":1}
INFO 商品区分売上集計 {"id":2}
INFO 商品区分売上集計 {"id":3}

このログ出力のまま実際にバッチがエラーを吐いて終了した場合、どのような事態になるでしょうか。

ログを確認しても商品の売上集計についてのログは残っておらず、エラーが発生した箇所がわからないのでおそらく原因調査は難航するでしょう。

このような事態を避けるには、「該当箇所で問題が発生した際に、自分がそのログを確認して十分な情報が得られるか」を基準にするといいと思います。

今回の場合は集計対象(商品区分・商品)ごとに以下の項目があれば十分でしょう。

上記の例の場合も、「エラー発生時にどの商品売上集計時にエラーが発生したのかわからないと困るな」と考えられれば役に立つログに改善できます。

前の例は必要な情報が不足しているという話でしたが、一方で必要ない情報までログに出力している場合もあります。

例えば、以下のようなログです。

INFO 商品売上集計 {"id":1, "name":"よくわかるログ出力", "price":2500, "category":"書籍" ...}

このログは商品の情報を全て出力する勢いですが、通常時のログを確認する際はidなどによって処理対象を識別ができれば十分であることが多いです。(少なくとも自分の経験上はそうです)

何より必要のない情報までログに出力すると、本来確認したい項目を見つけることが難しくなり作業時間や意欲を失うことにも繋がります。

そのため、今回の場合は通常時のログは以下の項目し、

エラー発生時のログは以下の項目を表示するなど、ログの役割に応じて必要な項目のみを出力すると役立つログになるでしょう。

以上、こんなログは使いづらいと思う点と、こうすると使いやすいのではという点を整理しました。

色々書きましたが、ログを改善するためには「どのようなログであれば利用者が使いやすいだろう」と意識してあげることが一番だと思います。
システム開発に限らない当たり前のことですが、忘れないように意識したいですね。