Webサービスを開発する際にきちんとトレースログ(操作ログ)は取っていますでしょうか？

Windowsアプリケーションの開発などではトレースログを取るのは常識ですが、実際に今までWebシステムなどに関わってきて、トレースログをきちんと取っているサービスやシステムは正直少ないように思います。
(取る慣習があまりないようにも感じます。)

もちろん取っているところ、サーバ容量の問題などでわざと取っていないところもあるでしょう。

不特定多数のユーザーが利用するサービスの場合、不具合があって問い合わせがあったとしても、閲覧環境など状況を細かく質問するのは非常に困難です。

自社内で再現しないような不具合も操作ログを取っておけば解決の糸口になります。
バグが発生した時によくある「状況が分からないとなんとも解決のしようがない！」というエンジニアの悩みもトレースログがあれば解決が早いですね。

もう一度トレースログの大切さについて考えてみました。

社内バグチェックの際に便利

少人数で開発している会社などですと、バグチェックをするのがディレクターであったりすることが多く、バグの発生した状況やバグ内容をエンジニアにうまいこと伝えられないことがあったります。

そういった場合にトレースログでどのユーザーが何をして何のエラーを吐いたのか分かれば大体のことは察しが付くわけです。

テスト会社にお願いしたり、テストに慣れたテスターがいるような環境で開発を行っていれば別ですが、当社のような少人数で制作しているような制作会社ではトレースログによってバグさえ発見してもらえれば修正できるので重宝するわけです。

 

ユーザーに閲覧環境や操作を確認するのは困難なので

ユーザーから受けた不具合で特定の環境下や予測していない操作などで再現がなかなかに難しい不具合があります。

ユーザーにどういう環境で、とか操作を詳しくといったことをヒアリングするのは現実的ではありません。
これは社内バグチェックの際と同様ですが、リリースしたサービスこそ、こちらの予測のつかない操作によってバグが発覚することは多々あります。

報告されたバグに対して、テスト環境などで再現テストを何度も行うのであれば、操作内容とエラー内容をログに吐き出していれば解決は早いでしょう。

 

よく使われる機能など、次の改善にもつながる

トレースログはバグなどの不具合の原因解明だけではなく、サービスの改善にも役立ちます。

サーバのアクセスログを見ればどのページにアクセスが集中しているのか、ということは分かりますが、操作までは分かりません。
PVとか投稿されたデータ数や時間を総合的に見ていけば大体のことは察しが付きますが、トレースログをとっておいた方がより明確に分かりやすいです。

例えば最近ではいちいち画面遷移しないで処理されるようなサービスも多いのでユーザーがどのボタン、どの機能をよく使っているか、逆に使われていないか、など正確なデータを取るためにもトレースログを取った方が良いでしょう。

 

ログを取る際に気をつけたいこと。

吐き出す内容

ログを取る際にリリース前やテスト環境でのデバッグ時のログとリリース用のログは吐き出す内容を分けておいた方がよいでしょう。テスト段階では細かくログを取っていたとしても、リリース時には要所要所を取っておいた方が、不必要にサーバの容量を取られません。

保存サイクル

これもサーバ容量の問題ですが、保存するサイクル、たとえば一週間分など決めておく必要があります。
この設定を忘れて無限に取るとログのせいで容量が圧迫されてしまい本末転倒です。

保存の仕方

これもポイントなのですが、ひとつのファイルに複数ユーザーの動向をすべて吐き出すとログを解析する時間がとられます。例えば会員制のWebサービスなどですと会員毎にログファイルを保存するなど、後で解析するのに効率が良い方法で保存するほうが良いです。

========

これらのトレースログにプラスしてエラー発生時にメールアラートが飛ぶようにしておけば安心ですね。

早くリリースすることを目標にしているとなかなか忘れがちですが、運用に入ってから役に立ちますので、社内でもトレースログを徹底していこうと思います。