访问 /srv/status 的命中是否算作爬虫？

[pfaffman (Jay Pfaffman)]

我运行了一个包含 3 个 Kubernetes Pod 的网站（这是他们要求的！）。爬虫统计数据显示每日页面浏览量超过 120,000。然而……用户非常少，帖子也不到 1000 条，因此实际上没什么可爬取的内容。盯着其中一个 Pod 的 production.log 几分钟，只看到访问 /srv/status 的流量，这是 k8s 用作健康检查的。这应该被计入爬虫吗？我是否遗漏了什么其他内容？

[codinghorror (Jeff Atwood)]

不，那不应该被计入。

[riking (Kane York)]

120K 正好符合每小时 5K 的恒定速度，所以我认为它们被计入了，尽管本不该如此。

也许是检测出了什么问题？

[pfaffman (Jay Pfaffman)]

我可以确认它们确实被统计了（并且它们是从 127.0.0.1 记录的）

SELECT * from web_crawler_requests
where date = '2020-03-05'
order by count desc

编辑：另外，看来我不太擅长数字，实际上每天大约是 1.2 万次。

这也令人困惑，因为如果我在三个 Pod 中执行 grep -c /srv/status，每个 Pod 在它们运行的 20 小时内都有大约 1.5 万行匹配 /srv/status。这样算下来，每天接近 5 万次。

[sam (Sam Saffron)]

它们会被统计。如果您不希望被统计，可以使用一个明确的选项：

lib/middleware/request_tracker.rb

在发起请求时，将 Discourse-Track-View HTTP 头设置为 0。

[pfaffman (Jay Pfaffman)]

@sam

你有一个明确的选项

感谢你高估了我对“明确”的理解。

@sam

将 Discourse-Track-View 头设置为 0

这几乎算明确了。

好的，所以我确实需要在容器启动时，在传递给容器的 ENV 中设置 HTTP_DISCOURSE_TRACK_VIEW=false？还是说，我需要设法让访问 /srv/status 的请求包含 Discourse-Track-View: 0 头？（或者也许是 =，不过我想我能搞清楚）。

编辑：我觉得这已经起作用了（谢谢，@Falco！），但我明天再回来确认是否真的奏效。

编辑2：GKE 不仅有来自 k8s 的健康检查，还有来自负载均衡器的健康检查，因此这两者都需要配置为包含 Discourse-Track-View: 0 头。

[Falco]

后者。假设该功能支持自定义请求头：

[riking (Kane York)]

是的，自定义头部：

pods/probe/http-liveness.yaml 

apiVersion: v1
kind: Pod
metadata:
  labels: {...}
  name: liveness-http
spec:
  containers:
  - name: ...
    image: ...
    readinessProbe:
      httpGet:
        path: /srv/status
        port: 80
        httpHeaders:
        - name: Discourse-Track-View
          value: "0"
      periodSeconds: 3
    livenessProbe:
      httpGet:
        # 发送自 https://github.com/discourse/discourse/pull/9136
        path: /srv/status?shutdown_ok=1
        port: 80
        httpHeaders:
        - name: Discourse-Track-View
          value: "0"  # 注意引号，避免 YAML 将其解析为整数
      initialDelaySeconds: 3
      periodSeconds: 3

[pfaffman (Jay Pfaffman)]

谢谢，Kane！我非常感激。我正在尝试这样做，看起来它确实有效，但我打算等到明天再确认一下是否真的奏效。

[codinghorror (Jeff Atwood)]

@sam

它们会被计入，如果你不想让它们被计入，有一个明确的选项可以使用。

我认为默认情况下，@sam 这个路由_不_应该被计入，我认为将“页面浏览量”计入这个路由没有任何价值……你觉得呢？

[sam (Sam Saffron)]

当然，我们可以在这里添加一个绕过机制，只是测试起来有点棘手，而且我们还没有一个清晰的绕过模式。

[riking (Kane York)]

响应本应已被排除在视图跟踪之外，因为响应类型是 text/plain 而非 text/html。

GoogleHC 实际访问的确切路径是什么？如果它访问的是 /，那就是问题所在；此时视图计数是正确的。

[pfaffman (Jay Pfaffman)]

嗯。我想我已经将上述头部信息添加到了 K8s 和负载均衡器上，而且它们应该都在访问 /srv/status。我几乎可以肯定这一点。但我仍然每天收到大约 12,960 次访问。我稍后会再检查一下。

感谢您的帮助！

[pfaffman (Jay Pfaffman)]

@riking

如果它访问的是 /，那就是问题所在；而且页面浏览量统计是正确的。

这确实是问题所在。我以为我已经将负载均衡器和 k8s 健康检查都配置为访问 /srv/status，但其中一个却在访问 /。所以，当我最终找到解决方法后，问题就消失了。

好消息是，添加 Discourse-Track-View 并非必要！

现在，我要让所有的 Uptime Robot 健康检查都使用 /srv/status。