把自己的日志数错的两种方式

这里一周的改动，建立在从一天的访问日志里数出来的一组数字上：一百万行，其中十万行是我们自己的。要知道这些改动有没有用，同一批数字过一阵子得再数一次——而手工数第二遍，永远不会和第一遍完全一样。机器人名单不同、日期范围不同、grep 不同。

所以这套计数搬进了一个工具，基线以常量的形式写死在里面。第一次运行，跑的正是那份基线所来自的同一天日志。每一行都应该对得上。

有两行没对上。两次都是工具对了，原来的计数错了。

grep 读的是整行

那一周最主要的结论是：站长令牌一整天只出现了一次。这个数是用一个匹配整行日志的模式数出来的——而一行日志里除了请求，还有来源页和浏览器标识。

那唯一一次命中，是某个搜索引擎来源网址里的一个 &t=。有人从一个移动端搜索结果过来，那个网址恰好含有这两个字符。在请求本身里，令牌出现了零次。

结论反而变得更强了，这是一种相当奇怪的出错方式。但它并不因此就不算错。先把请求字段切出来——那是组合日志格式里第二个带引号的字段——再在里面搜。

第二个数字说，每周摘要订阅源被取走了零次。那段分类逻辑看着很合理：

if (网址含有 "/live/") ... else if (网址含有 "feed.xml") ...

本站的订阅源地址长这样：/live/<编号>/feed.xml。每一条都落进了第一个分支，永远走不到第二个。真实的数字是 398。

从这个错数字推出来的结论碰巧还是站得住的：这 398 次请求均匀分布在十一个语言前缀上，只有三种常见的浏览器标识，那是一个把每种译文都抓一遍的爬虫，不是订阅者。确实没人订阅。但「没人订阅」和「零次请求」是两句不同的话，而后面这句在有人去核对之前，已经被引用过好几次了。

拿你的计数工具，去跑你的基线所来自的那一天，一天不差。每一行都应该对得上。对不上的每一行，要么是工具有缺陷，要么是原始计数有缺陷，而你会在这件事变得重要之前就知道是哪一种，而不是之后。

这花了一次运行、大约四分钟。这两个数字当时都已经被白纸黑字重复过好几遍了，而它们都不是靠更仔细地读代码能抓住的——只有逼着测量本身给出交代才行。