Le richieste a /srv/status contano come crawler?

Comunità Dati e reportistica
1

Ho un sito in esecuzione con 3 pod Kubernetes (è quello che volevano!). Le statistiche del crawler mostrano > 120K visualizzazioni di pagina/giorno. Ci sono… pochissimi… utenti e meno di 1000 post, quindi non c’è molto da crawlerizzare. Osservando il file production.log di uno dei pod per alcuni minuti, si vede solo traffico verso /srv/status che k8s utilizza come monitor di stato. Dovrebbe essere contato come un crawler? C’è qualcos’altro che potrei aver trascurato?

2

No, quello non dovrebbe essere contato.

3

120K è esattamente il risultato atteso per un flusso costante di 5k/ora, quindi direi che vengono contati anche se non dovrebbero.

Forse c’è qualcosa che non va nel rilevamento?

4

Posso confermare che vengono contati (e sono registrati da 127.0.0.1)

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

image
image889×350 21.9 KB

EDIT: inoltre, evidentemente non sono bravo con i numeri, e sono circa 12K al giorno.

image
image927×655 43.4 KB

image
image1192×302 24.8 KB

E questo è anche confuso perché se eseguo grep -c /srv/status nei 3 pod, ognuno di essi ha circa 15K righe che corrispondono a /srv/status nelle 20 ore in cui sono attivi. Quindi sarebbe vicino a 50K al giorno.

5

Vengono conteggiati e, se non desideri che vengano conteggiati, hai a disposizione un’opzione chiara che puoi utilizzare:

Imposta l’intestazione HTTP Discourse-Track-View su 0 nella richiesta originante.

6

Apprezzo che tu sopravvaluti ciò che è chiaro per me. :wink:

Quasi chiaro.

Ok, quindi devo impostare HTTP_DISCOURSE_TRACK_VIEW=false nell’ENV passato al container quando viene avviato? E/o devo fare in modo che ciò che chiama /srv/status includa un’intestazione Discourse-Track-View: 0? (o forse è un =, ma presumo che riuscirò a capirlo).

MODIFICA: Penso che abbia funzionato (grazie, @Falco!), ma farò rapporto domani quando potrò essere certo che abbia funzionato.

MODIFICA 2: E GKE ha non solo controlli di salute da k8s, ma anche controlli di salute dal bilanciatore di carico, quindi entrambi devono essere configurati con l’intestazione Discourse-Track-View: 0.

7

Quello successivo. Supponendo che l’oggetto abbia la funzione per consentirti di utilizzare intestazioni personalizzate :sweat_smile:

8

Sì, intestazioni personalizzate:

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:
        # inviato https://github.com/discourse/discourse/pull/9136
        path: /srv/status?shutdown_ok=1
        port: 80
        httpHeaders:
        - name: Discourse-Track-View
          value: "0"  # nota le virgolette, per evitare che YAML lo interpreti come un intero
      initialDelaySeconds: 3
      periodSeconds: 3
9

Grazie, Kane! Lo apprezzo molto. È quello che sto cercando di fare e sembra che funzioni, ma volevo aspettare fino a domani per vedere se funziona davvero. :wink:

10

Penso che di default @sam questa rotta non dovrebbe essere conteggiata. Non vedo alcun valore nel contare le “visualizzazioni di pagina” per questa rotta… tu sì?

11

Certo, possiamo aggiungere un bypass qui; è solo un po’ complicato da testare e non abbiamo un modello chiaro per il bypass.

13

Le risposte dovrebbero già essere escluse dal tracciamento delle visualizzazioni perché sono di tipo text/plain e non text/html.

Qual è il percorso esatto che GoogleHC stava raggiungendo? Se stava raggiungendo /, quello è il problema; e il conteggio delle visualizzazioni era corretto.

14

Hmm. Penso di aver aggiunto le intestazioni descritte sopra sia a K8s che al load balancer e sono quasi certo che entrambi stiano colpendo /srv/status. Sto ancora ricevendo esattamente 12.960 accessi al giorno, nella maggior parte dei giorni. Ci darò un’altra occhiata tra poco.

Grazie per il tuo aiuto!

15

Era proprio quello il problema. Pensavo di aver configurato sia il bilanciatore di carico che il controllo di salute di k8s per colpire /srv/status, ma uno dei due stava colpendo /. Quindi, quando ho finalmente capito come risolvere, il problema è sparito.

La grande notizia è che non è necessario aggiungere Discourse-Track-View!

Ora devo fare in modo che tutti i miei controlli di salute di uptime robot utilizzino /srv/status.