Zählen Hits auf /srv/status als Crawler?

Gemeinschaft Daten & Berichterstattung
1

Ich habe eine Website mit drei Kubernetes-Pods laufen (so wollten sie es!). Die Crawler-Statistiken zeigen mehr als 120.000 Seitenaufrufe pro Tag. Es gibt … sehr wenige … Benutzer und weniger als 1000 Beiträge, sodass nicht viel zu crawlen ist. Wenn ich ein paar Minuten lang die production.log eines der Pods beobachte, sehe ich nur den Verkehr zu /srv/status, den k8s als Gesundheitsmonitor verwendet. Sollte das als Crawler gezählt werden? Gibt es etwas anderes, das ich übersehen habe?

2

Nein, das sollte nicht gezählt werden.

3

120.000 passt genau zu einer konstanten Rate von 5.000 pro Stunde, also würde ich sagen, dass sie gezählt werden, obwohl sie es nicht sollten.

Vielleicht liegt ein Fehler bei der Erkennung vor?

4

Ich kann bestätigen, dass sie gezählt werden (und sie werden von 127.0.0.1 protokolliert)

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

image
image889×350 21.9 KB

EDIT: Außerdem bin ich anscheinend schlecht im Rechnen, und es sind ~12 K/Tag.

image
image927×655 43.4 KB

image
image1192×302 24.8 KB

Das ist auch verwirrend, denn wenn ich grep -c /srv/status in den 3 Pods ausführe, hat jeder von ihnen ~15 K Zeilen, die /srv/status in den 20 Stunden, in denen sie hochgefahren waren, entsprechen. Das wären also fast 50 K/Tag.

5

Sie werden gezählt. Wenn Sie nicht möchten, dass sie gezählt werden, haben Sie eine klare Option:

Setzen Sie den HTTP-Header Discourse-Track-View auf 0 in der ursprünglichen Anfrage.

6

Ich schätze, dass du das, was für mich klar ist, überschätzt. :wink:

Das ist fast klar.

OK, also muss ich wirklich HTTP_DISCOURSE_TRACK_VIEW=false in die ENV-Umgebungsvariablen setzen, die dem Container übergeben werden, wenn er startet? Und/oder muss ich dafür sorgen, dass der Dienst, der /srv/status anfragt, einen Header Discourse-Track-View: 0 enthält? (oder vielleicht ist es ein =, aber das werde ich vermutlich herausfinden).

EDIT: Ich denke, das hat den Trick gerettet (danke, @Falco!), aber ich melde mich morgen zurück, sobald ich sicher sagen kann, dass es funktioniert hat.

EDIT2: Und GKE hat nicht nur Health-Checks von k8s, sondern auch Health-Checks vom Load Balancer, sodass beide mit dem Header Discourse-Track-View: 0 konfiguriert werden müssen.

7

Letzteres. Unter der Annahme, dass die Sache die Funktion hat, benutzerdefinierte Header zu verwenden :sweat_smile:

8

Ja, benutzerdefinierte Header:

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:
        # gesendet https://github.com/discourse/discourse/pull/9136
        path: /srv/status?shutdown_ok=1
        port: 80
        httpHeaders:
        - name: Discourse-Track-View
          value: "0"  # beachten Sie die Anführungszeichen, damit YAML daraus keine Ganzzahl macht
      initialDelaySeconds: 3
      periodSeconds: 3
9

Danke, Kane! Das bedeutet mir wirklich viel. Das ist genau das, was ich versuche, und es scheint zu funktionieren. Ich warte aber noch bis morgen, um sicherzugehen, dass es wirklich klappt. :wink:

10

Ich denke, standardmäßig sollte @sam diese Route nicht gezählt werden. Ich sehe keinen Mehrwert darin, jemals “Seitenaufrufe” für diese Route zu zählen… oder siehst du das anders?

11

Klar, wir können hier einen Bypass einfügen. Das Testen ist jedoch etwas knifflig, und wir haben noch kein sauberes Muster für Bypasses.

13

Die Antworten sollten bereits vom View-Tracking ausgeschlossen sein, da sie als text/plain und nicht als text/html bereitgestellt werden.

Welcher exakte Pfad wurde von GoogleHC aufgerufen? Wenn es / war, liegt hier das Problem; die Zählung der Aufrufe war dann korrekt.

14

Hmm. Ich bin mir ziemlich sicher, dass ich die oben beschriebenen Header sowohl für K8s als auch für den Load Balancer hinzugefügt habe und dass beide /srv/status abfragen. Trotzdem erhalte ich an den meisten Tagen genau 12.960 Aufrufe pro Tag. Ich werde das gleich noch einmal überprüfen.

Vielen Dank für deine Hilfe!

15

Das war das Problem. Ich dachte, ich hätte sowohl den Load Balancer als auch den k8s-Health-Check so konfiguriert, dass sie /srv/status anfordern, aber einer von ihnen traf auf /. Als ich schließlich herausfand, wie ich das beheben kann, verschwand das Problem.

Die großartige Nachricht ist: Das Hinzufügen von Discourse-Track-View ist nicht erforderlich!

Jetzt muss ich nur noch sicherstellen, dass alle meine Uptime-Robot-Health-Checks /srv/status verwenden.