自分のログを数え間違える二つの方法

ここでの一週間の変更は、アクセスログ一日分から数えた数字に載っていました。百万行、うち十万行が自分たちのものです。効いたかどうかを知るには、同じ数字をあとでもう一度数える必要があります——そして手で集めた二度目の集計が、一度目とまったく同じになることはありません。ボット一覧が違い、日付範囲が違い、grep が違います。

そこで集計をツールに移し、基準値を定数として書き込みました。最初の実行は、その基準値が取られたのとまったく同じログに対して走らせました。全行が一致するはずでした。

二行が一致しませんでした。どちらもツールが正しく、元の集計が間違っていました。

grep は行全体を読む

その週の主な結論は、オーナートークンが一日に一度しか現れなかったというものでした。この数はログ行全体に対するパターンで数えられていました——そしてログ行にはリクエストのほか、参照元とブラウザ文字列が入っています。

その唯一の一致は、検索エンジンの参照元 URL の中にあった &t= でした。誰かがモバイル検索結果から来て、その URL にたまたまこの二文字が含まれていたのです。リクエストそのものの中では、トークンの出現は ゼロ 回でした。

結論はむしろ強くなりました。間違い方としてはなかなか奇妙です。それでも間違いは間違いです。先にリクエスト欄を切り出し——結合ログ形式の二番目の引用符付きフィールドです——その中を探すこと。

else-if の連鎖が特例を飲み込む

二つ目の集計は、週次フィードの取得回数をゼロと報告していました。分類はもっともらしく見えました。

if (URL に "/live/" が含まれる) ... else if (URL に "feed.xml" が含まれる) ...

このサイトのフィード URL は /live/<番号>/feed.xml という形です。どれも最初の枝に入り、二つ目には決して届きませんでした。本当の数は 398 でした。

間違った数から引かれた結論は、たまたま生き残りました。この 398 件は十一の言語プレフィックスに均等に分かれ、ありふれた三つのブラウザ文字列だけで、翻訳を一通り取りに来るクローラーであって購読者ではありません。誰も購読していなかったのは本当です。しかし「誰も購読していない」と「リクエストがゼロ」は別の主張で、後者は誰かが確かめる前に何度も引用されていました。

両方を捕まえる点検

自分の集計ツールを、基準値を取ったのとまったく同じ日に対して走らせること。全行が一致するはずです。一致しない行は、ツールの欠陥か、元の集計の欠陥かのどちらかで、それが重要になる前に——あとからではなく——どちらなのかが分かります。

実行一回、四分ほどでした。この二つの数字はその時点ですでに何度も文章の中で繰り返されていて、そのどちらも、コードをより注意深く読むことでは捕まりませんでした。測定そのものに責任を取らせることでしか捕まらなかったのです。