问一个爬虫团队进展如何,通常会得到一个数字:成功率。这是显而易见的指标,也确实有用,但单独来看,它对运营一条数据管道几乎没有帮助,因为它掩盖了团队负责人真正需要回答的两个问题。我们采集的数据是否正确,以及我们为采集它所付出的成本是否合理。
一条管道可能报告百分之九十八的成功率,同时却在悄悄地把仓库填满验证挑战页面,而且这个月和上个月报告的数字可能一样,成本却翻了一倍。下面是能同时捕捉这两个问题的指标集合,按用途分类整理。
从大家都容易搞错的指标开始
验证后的成功率(Validated success rate)。 不是返回 200 的请求占比,而是返回了你真正需要的数据的请求占比。
这个区分是大多数团队能对监控做出的价值最高的一项改动。验证挑战页面、空结果集、被截断的列表、同意弹窗、或一个通用的地区跳转,都可能以 200 状态码到达。一个只信任状态码的计数器会在数据集持续退化的同时报告一切健康,而你会从业务用户询问“为什么这张图看起来不对”那里才发现问题,而不是从自己的仪表盘上。为每个目标定义一个有效性检查,比如一个预期元素、一个合理的内容长度、JSON 中的一个必需字段,并且只统计通过该检查的响应,具体方法见检测被封锁或伪造的内容。
按目标和地区分别追踪,而不要用一个全局数字。全局的 95% 可能是每个目标都是 95%,也可能是十九个目标都是 100%,还有一个是零,而这两种情况需要完全不同的应对方式。
数据质量指标
除了有效性之外,还有三个数字能告诉你输出是否可信。
覆盖率(Coverage)。 在一次运行中你预期获得的记录里,实际拿到了多少?一个任务可能每次请求都成功,但由于分页出错或某个发现步骤返回的结果比昨天少,而发出的请求数量比昨天更少,这种情况在成功率上看起来完美,但实际上数据明显不完整。覆盖率能捕捉到这一点。
新鲜度(Freshness)。 每个数据源中最新数据的时间是多久以前?对于价格或库存这类快速变化的工作来说,即使一切在技术上都成功了,数据陈旧本身也是一个缺陷,因此应追踪每个目标最近一次成功采集的时间,并在超出该场景可容忍的范围时发出告警。
字段级完整度(Field-level completeness)。 在采集到的记录中,有多少比例包含你需要的每一个字段?一次布局变更移除了某个属性时,很少会导致请求失败;它只是悄悄地把某一列置为空,只有字段级追踪才能及早发现这一点。
这些指标共同回答了“数据是否正确”这个问题,而单纯的成功率无法回答。
效率与成本指标
这些指标回答的是“我们付出的成本是否合理”,而它们通常是被监控得最不充分的一类。
每条记录的字节数(Bytes per record)。 整套指标中最有用的成本指标。用消耗的带宽除以提取到的有效记录数,按目标计算。它能在不同规模的任务之间实现归一化,使各个目标可以互相比较,而这个数字的突然上升几乎总是因为有人在渲染完整页面,而实际上一个数据接口就足够了。由于住宅代理是按传输的数据量计费的,这个数字几乎就等于你的单位成本,相关的调节手段见削减代理带宽成本和判断何时需要无头浏览器。
每千条记录的成本(Cost per thousand records)。 每条记录的字节数乘以你的费率,按目标呈现。这是应该放在任何询问“某个数据源是否值得采集”的人面前的数字,因为它把基础设施转化成了业务本身已经使用的语言,也正是它让预估每月带宽中的预测变得具体可行。
重试比率(Retry ratio)。 重试请求占总请求数的比例,按目标计算。这是一个领先指标:它会在成功率下降之前先上升,因为一条通过重试才勉强得到“看起来正常”的结果的管道,其实是在掩盖问题而不是解决问题。它同时也是按带宽计费产品上纯粹的浪费,因此它既是健康信号,也是一条成本线,这也是它在重试与退避策略中处于核心位置的原因。
按目标划分的带宽(Bandwidth per target)。 钱真正流向的地方。团队常常惊讶地发现某一个目标消耗了计划中的大部分额度,而一旦这一点可见,修复起来通常并不昂贵。
性能指标
延迟百分位数,而不是平均值。 按目标追踪 p50、p95 和 p99。住宅连接本质上比直连慢,因此绝对数值本身不如其形态和趋势重要。平均值会完全掩盖尾部,而尾部恰恰决定了一个有时限的任务能否完成。
相对于计划的吞吐量(Throughput against plan)。 每小时的记录数,与日程要求相比较。这决定了你是需要更多并发、更好的节奏控制,还是不同的采集策略,也是你实际需要多少代理 IP中分布问题的实际输入。
封锁与验证挑战率(Block and challenge rate)。 与失败请求不同:它指的是那些具体表现为封锁、验证码或验证挑战的响应占比。当验证挑战率上升而成功率保持稳定时,意味着你正在为获得同样的产出而付出更多努力,这是目标防御机制发生变化的早期预警。
不该追踪的指标
有两个指标被过度关注,而实际应得到的重视应该更少。
代理池规模(Pool size)。 这是供应商提供的数字,不是性能指标,它无法预测你的结果。真正有意义的是你实际采集的国家中的代理密度,而了解这一点的唯一方法是你自己按地区统计的成功率。
原始请求数(Raw request count)。 没有有效性支撑的数量只是活动量,不是产出。一条把请求数翻倍却采集到相同数量可用记录的管道其实变差了,而一个只统计请求数的计数器会把这称为增长。
同样,要小心如何使用可用性 SLA。供应商的可用性是真实存在且值得关注的,但它与你的目标是否接受你的流量是完全不同的维度,混淆这两者会让你在合同上有保障,但在运营上却处于盲区,这正是代理 SLA 与可用性保证中讨论的边界问题。
把指标转化为告警
一个没人看的仪表盘只是装饰品。围绕上述指标设置少量的告警,才是真正能保护一条管道的东西。
在验证后成功率跌破每个目标各自的阈值时发出告警,因为一个数字无法适配所有网站。在覆盖率相对于上周同一任务下降时发出告警,这能捕捉到悄然发生的数据萎缩。在新鲜度超出该场景可容忍的范围时发出告警。在每条记录字节数急剧上升时发出告警,这通常意味着成本回归,而且往往是代码变更所致。在重试比率攀升时发出告警,因为它是所有信号中最早触发的。
两条实用的规则能让这些告警变得可维护。使用滚动基线而不是固定数字进行比较,因为每个目标有自己的节奏,静态阈值不是频繁误报就是永远不触发。以及要求持续偏离而不是单一的糟糕时段,因为一个糟糕的五分钟窗口只是噪音。具体的监控实现方式见监控网页爬虫管道。
一套最简起步方案
如果你是从零开始建立监控体系,每个目标关注六个指标基本就能获得大部分价值:验证后成功率、相对于预期的覆盖率、最新记录的新鲜度、每条记录的字节数、重试比率,以及 p95 延迟。在前两项上加入地区这个维度,因为地理位置正是多市场管道悄然失效的地方。其他一切都可以等到这六项指标中的某一项引出一个你无法回答的问题时再处理。
结论
成功率回答的是请求是否完成,这是团队负责人所关心的三个问题中最不重要的一个。在把返回结果计入成功之前先验证它,然后通过覆盖率、新鲜度和字段完整度来了解数据是否正确,并通过每条记录字节数、每千条记录成本和重试比率来了解价格是否合理。按目标和地区分别追踪,而不要用全局数字,基于滚动基线的持续偏离发出告警,并且不要根据代理池规模或原始请求量来评判基础设施的好坏。真正重要的指标,是那些能改变决策的指标,而以上这些正是这样的指标。
针对网络本身进行的测量是一项独立的工作,详见测试速度、成功率与位置准确性。背后所使用的住宅代理是按每 GB计费的,这正是为什么每条记录的字节数是值得关注的成本指标:它正是构成你账单的那个数字。