/srv/status へのヒットはクローラーとみなされますか？

コミュニティ データとレポート
1

3 つの Kubernetes ポッドでサイトを稼働させています（彼らが望んだものです！）。クローラーの統計では、1 日あたり 12 万ページビューを超えています。しかし、ユーザーは非常に少なく、投稿数は 1000 件未満なので、クローリングすべき内容はほとんどありません。ポッドの 1 つの production.log を数分間見てみると、k8s が健全性チェックに使用している /srv/status へのトラフィックしか表示されません。これはクローラーとしてカウントされるべきでしょうか？見落としていることはありますか？

2

いいえ、それはカウントされるべきではありません。

3

12万は時速5kmの一定速度を基準にすれば妥当な数値です。つまり、本来カウントされるべきではないものがカウントされていると言わざるを得ません。

検出に何か問題が起きているのでしょうか？

4

カウントされていることを確認しました（127.0.0.1 からログが記録されています）

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

image
image889×350 21.9 KB

追記：数え方が下手なようで、実際には約 12K/日です。

image
image927×655 43.4 KB

image
image1192×302 24.8 KB

これも混乱を招きます。3 つのポッドで grep -c /srv/status を実行すると、それぞれが起動してから 20 時間の間に /srv/status に一致する行が約 15K あります。つまり、1 日あたり約 50K になるはずです。

5

これらはカウントされます。カウントしたくない場合は、以下の明確なオプションを使用できます。

発信リクエストで Discourse-Track-View HTTP ヘッダーを 0 に設定してください。

6

私が理解していることを過大評価してくれてありがとうございます。:wink:

それはほぼ明確です。

つまり、コンテナが起動する際に渡す ENV で HTTP_DISCOURSE_TRACK_VIEW=false を設定する必要があるのでしょうか？あるいは、/srv/status にアクセスするものが Discourse-Track-View: 0 ヘッダーを含めるように仕組むのでしょうか？（もしかしたら = かもしれませんが、それは後でわかります）。\n
編集：これでうまくいったと思います（@Falco さん、ありがとう！）。しかし、本当に成功したかどうかは明日になってから報告します。

編集2：GKE では、k8s からのヘルスチェックだけでなく、ロードバランサーからのヘルスチェックも行われるため、両方の設定で Discourse-Track-View: 0 ヘッダーを設定する必要があります。

7

後者です。その機能にカスタムヘッダーを使用できるという特徴があることを前提としていますが:sweat_smile:

8

はい、カスタムヘッダーです：

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
9

ありがとう、ケイン！本当に感謝しています。それが私の試みで、うまくいっているようですが、本当に機能するか確認するために明日まで待っていました。:wink:

10

デフォルトでは、@sam、このルートはカウントされないべきだと考えます。このルートへの「ページビュー」をカウントすることには、いかなる価値も見出せません。あなたはどう思いますか？

11

もちろん、ここでバイパスを追加することはできますが、テストが少し複雑で、バイパスのための明確なパターンがまだ確立されていません。

13

レスポンスは text/plain であり text/html ではないため、すでにビュー追跡から除外されているはずです。

GoogleHC が実際にアクセスしていた正確なパスは何ですか？もし / だった場合、それが問題です。ビューのカウントは正しいものです。

14

うーん。上記のヘッダーを K8s とロードバランサーの両方に追加し、どちらも /srv/status にヒットしているのは確かだと思います。それでも、ほとんどの日で正確に 12,960 回のヒットが記録されています。もう少し詳しく確認してみます。

ご協力ありがとうございます！

15

それが問題でした。ロードバランサーと k8s のヘルスチェックの両方を /srv/status に設定したつもりでしたが、そのどちらかが / にヒットしていました。そのため、その問題を修正する方法をようやく見つけた時点で、問題は解消しました。

素晴らしいことに、Discourse-Track-View を追加する必要はありませんでした！

これで、すべての Uptime Robot のヘルスチェックを /srv/status に設定します。