大量のログやエラーに紛れるバグ

4回目まして。バグマニアのよっしーです。

若干投稿が遅れましたが、まあGWですし、勝手に気を取り直して続けていきたいと思います。

というわけで早速本題の「大量のログやエラーに紛れるバグ」に入ります。

ソフトウェア開発なりアプリなりで仕込んでいるログって、大量に出力されるものが多いですよね。実行ログやチェックログとか。消さないと領域いっぱいになって、そっちもまた別のエラー出るし、チェックするのは結構しんどい業務です。

二つ三つなら楽なんですけどね。たくさん出ててもう見たくないよってウンザリした経験は、エンジニアなら一度や二度ではないでしょう。

またログが大量にあれば、ログの中から影響が大きいエラーを抽出する簡単なプログラムを書いたり、エラーからまた優先順位付けた結果を見てみたりと、そんな日常を送っている方も多いのではないでしょうか。

「ログ出力されるエラーは、対応のレベルも細かく決めているし、抽出された箇所も一つ一つちゃんと見ているから、うちは大丈夫！」というあなたはもうこの投稿を読む必要はないかもしれません。

ですが、エンジニアなら業務に強弱（優先順位）は付けるでしょうし、例えば100件のエラーをすべてきちんと平均的に見るなんてことは、まずしないでしょう。

あなたも、「これはいつもエラーに出るけど、いったんスルーしておこう」なんて、無視するエラーを決めちゃったりしていませんか。エラー設定しておくけど、しばらくは見ないで少し後に対応しようとか。そちらの方が効率的な場合もあるでしょうし。

私もそうしていたのですが、いつも無視するエラーと見つけたい新たなエラーが紛れてしまい、新たな方を見つけられなかったことがあります。原因が複数ある場合は、狙ったエラーが出ていても、無視するのと同じエラーメッセージだったら見つけられませんからね。

異なる種類のエラーは別のIDやメッセージにしておくのが一番の対策ですが、そうもいかない場合もあります。その後は、正常の時と比べての件数比較（実際に場所によって増減あって合計増減なしもあるのでそこは注意）や、発生している場所がどこか見るなどの対応をするようにしました。

このように、大量のログやエラーから少ないものを選択して対応する際は、エンジニアが見落としやすくなります。二つ三つから一つを選ぶ時にはまず失敗しないでしょうが、大量なら「人がつい陥ってしまうワナ」となり、バグ発見の狙い目になります。

次回は、ログやエラーではない、大量なために陥ってしまうワナの例を紹介したいと思います。

それではまた。