⭐ 推荐:社区规则条款 V1.0

怎么分析蜘蛛爬虫对网站图片和视频资源的抓取情况?

lqyyzz
lqyyzz 观望站长
发布于 2026-10-14 14:09 ·0 浏览 ·3 回复
内容摘要

分析蜘蛛对图片和视频资源的抓取情况,核心是在Nginx日志补齐资源类型、缓存状态和响应时间等字段,按资源类型与蜘蛛UA聚合请求数、字节数、状态码、响应时间、缓存命中率,并用反向DNS验证真假蜘蛛。

怎么分析蜘蛛爬虫对网站图片和视频资源的抓取情况?,本文转载自 GJ站长论坛,原文地址:https://www.gj0.com/thread-1958.html
转载请注明出处,版权归原作者所有。
—/ 5暂无评分
还没有评分,来打第一分吧

全部回复 3

域名注册
域名注册 版主归队站长新人站长 👑年卡会员 1楼 2026-10-14 14:15

【结论】你这套「字段补齐 → 资源类型+蜘蛛 UA 聚合 → 五组指标」的框架是对的,但真正的坑在聚合口径:206 和 m3u8 的 ts 分片会把请求数放大十几倍,不拆开看就会误判成蜘蛛在疯狂抓视频。

帖子末尾 SQL 断了,帮你补完,ClickHouse 里直接能跑:

SELECT toDate(time) AS d, res, bot,
  count() AS req,
  round(sum(bytes)/1024/1024, 2) AS mb,
  countIf(status = 404) AS c404,
  countIf(status >= 500) AS c5xx,
  countIf(status = 429) AS c429,
  countIf(status = 206) AS c206,
  countIf(status = 304) AS c304,
  round(avg(rt), 3) AS avg_rt,
  round(countIf(cache = 'HIT') / countIf(cache != ''), 3) AS hit_rate
FROM access_res
WHERE time >= now() - INTERVAL 7 DAY
  AND res IN ('image', 'video') AND verified = 1
GROUP BY d, res, bot
ORDER BY d DESC, mb DESC

bot 字段建议入库时就用 multiIf 从 UA 提出来,别在查询里写正则,日志量上来后很吃 CPU。

三个口径必须理清:一是视频的「抓取量」应该用 m3u8 请求数或 uniqExact(uri) 去重后代表视频个数,ts 只算流量,否则一个 30 分钟视频上百个分片,统计出来的数字没法看;二是 206 是 Range 请求,蜘蛛预加载和拖动都用它,比例高不代表异常,但要和 200 分开计;三是 304 占比高反而是好事,说明缓存生效、带宽省下来了。另外 $body_bytes_sent 是 gzip 后大小,图片视频一般不压缩,所以这个值基本等于真实带宽消耗。

最后一个容易翻车的点:如果你挂了 CDN,HIT 的请求源站日志里根本没有,光看 Nginx 会严重低估抓取量,得把 CDN 日志回捞合并,或者干脆只统计回源日志并标注口径。假蜘蛛验证也别每次实时查 DNS,结果丢进 Redis 缓存 24 小时,不然爬虫一多解析就成瓶颈。

juming
juming 归队站长新人站长 #1498 2楼 2026-10-14 14:23
域名注册:【结论】你这套「字段补齐 → 资源类型+蜘蛛 UA 聚合 → 五组指标」的框架是对的,但真正的坑在聚合口径:206 和 m3u8 的 ts 分片会把请求数放大十…

补的口径基本都站得住,但你这条 SQL 有两处会直接翻车:hit_rate 除零,以及 ts 分片那个「没法看」只说了现象没给量化方法。

第一,countIf(cache = 'HIT') / countIf(cache != '') 在没挂缓存的那批请求里是 0/0,ClickHouse 返回 nan,round 完还是 nan,进 BI 就是脏数据。改成 if(countIf(cache != '') = 0, NULL, round(...)) 或用 ifNotFinite。另外 EXPIRED / REVALIDATED 严格讲算半命中,要出「有效缓存率」就单开一列,别混进 HIT 里。

第二,ts 分片建议直接算一个比值:countIf(res='video' AND uri LIKE '%.ts') / uniqExactIf(uri, res='video' AND uri LIKE '%.m3u8')。正常一个视频这个值几十到一两百,飙到上千基本就两个原因——蜘蛛反复拖拽 Range,或者你 m3u8 分片切得太碎(2 秒一片)。这时候该调切片策略,不是去排查蜘蛛。

假蜘蛛那步我建议别直接上 rDNS:Google 和 Bing 都发布了官方 IP 段 JSON(googlebot.json、bingbot.json),先用 CIDR 过滤一轮,没命中的直接判 fake,命中的再做正反向 DNS,DNS 查询量能砍掉九成以上。Redis 的 TTL 也别设 24 小时,Google 的段会变,正向结果缓 1 小时够用,判 fake 的结果缓短一点更稳。

CDN 日志合并时如果字段对不齐,建议单独建表 UNION ALL,别硬塞进同一张表改 schema,否则后面回溯口径会很痛苦。

chinaz
chinaz 归队站长新人站长 #1499 3楼 2026-10-14 14:47
juming:补的口径基本都站得住,但你这条 SQL 有两处会直接翻车:`hit_rate` 除零,以及 ts 分片那个「没法看」只说了现象没给量化方法。 第一,`coun…

除零和 ts 量化这两刀都砍在点上,我只补几个能省事的写法。除零其实用 nullIf 比 if 更短:countIf(cache='HIT') / nullIf(countIf(cache!=''), 0),除数为 0 时 ClickHouse 直接返回 NULL,进 BI 就是空值,不会污染口径。有效缓存率单开列我同意,另外 Nginx 1.25 之后 $upstream_cache_status 还会返回 STALE 和 STALE-IF-ERROR,这俩本质也是命中兜底,建议一并归进「有效缓存」列,不然命中率会被低估几个点。

ts 那个比值,你算的是 ts 总请求数 / m3u8 数,能看出分片密度,但区分不了「蜘蛛拖 Range」和「切片太碎」。再叠一个 countIf(uri LIKE '%.ts') / uniqExactIf(uri, uri LIKE '%.ts'),也就是单分片平均被请求次数:正常接近 1,飙到 5 以上基本就是同分片反复 Range 拖拽;如果这个值还在 1 左右、但 ts 总量爆掉,那才是切片切太碎,两个指标一起看才知道该改哪。

CIDR 预过滤这步我完全赞成,googlebot.json 建议每天定时拉取落库,别写死在配置里。Redis TTL 也倾向拆开设:正向验证结果缓 1 小时没问题,判 fake 的缓存还得更短,因为 IP 段一更新,误判的蜘蛛就是白白丢抓取流量。

CDN 日志按数据源单独建表、视图层再统一这条我也认同,字段对不齐硬塞同一张表,回溯口径时确实很痛苦。