Les requêtes vers /srv/status comptent-elles comme des robots d'exploration ?

Communauté Données et rapports
1

J’ai un site qui exécute 3 pods Kubernetes (c’est ce qu’ils voulaient !). Les statistiques du crawler affichent > 120 000 pages vues/jour. Il y a … très peu … d’utilisateurs et moins de 1000 publications, donc il n’y a pas grand-chose à crawler. En observant le fichier production.log de l’un des pods pendant quelques minutes, on ne voit que du trafic vers /srv/status que k8s utilise comme moniteur de santé. Cela devrait-il être compté comme un crawler ? Y a-t-il autre chose que je pourrais manquer ?

2

Non, cela ne devrait pas être compté.

3

120K correspond exactement à un rythme constant de 5k/heure, donc je dirais qu’ils sont comptés, même s’ils ne devraient pas l’être.

Peut-être y a-t-il un problème dans la détection ?

4

Je peux confirmer qu’ils sont bien comptabilisés (et qu’ils sont enregistrés depuis 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 : par ailleurs, je ne suis pas très fort avec les chiffres, apparemment, et c’est environ 12 K/jour.

image
image927×655 43.4 KB

image
image1192×302 24.8 KB

Et c’est aussi déroutant car si je fais grep -c /srv/status dans les 3 pods, chacun d’eux contient environ 15 K de lignes correspondant à /srv/status sur les 20 heures où ils ont été actifs. Cela représenterait donc près de 50 K/jour.

5

Ils sont comptabilisés et, si vous ne souhaitez pas qu’ils le soient, vous disposez d’une option claire que vous pouvez utiliser :

Définissez l’en-tête HTTP Discourse-Track-View à 0 sur la requête d’origine.

6

J’apprécie que vous surestimiez ce qui est clair pour moi. :wink:

C’est presque clair.

OK, donc je dois vraiment définir HTTP_DISCOURSE_TRACK_VIEW=false dans l’ENV passé au conteneur au moment de son démarrage ? Et/ou dois-je faire en sorte que l’élément qui interroge /srv/status inclue un en-tête Discourse-Track-View: 0 ? (ou peut-être est-ce un =, mais je suppose que je peux m’en charger).

EDIT : Je pense que cela a fonctionné (merci, @Falco !), mais je reviendrai vers vous demain pour confirmer que cela a bien fonctionné.

EDIT2 : Et GKE dispose non seulement de vérifications de santé depuis k8s, mais aussi de vérifications de santé depuis le load balancer, il faut donc configurer les deux avec l’en-tête Discourse-Track-View: 0.

7

Le deuxième. En supposant que l’objet dispose de la fonctionnalité permettant d’utiliser des en-têtes personnalisés :sweat_smile:

8

Oui, en-têtes personnalisés :

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:
        # envoyé via https://github.com/discourse/discourse/pull/9136
        path: /srv/status?shutdown_ok=1
        port: 80
        httpHeaders:
        - name: Discourse-Track-View
          value: "0"  # notez les guillemets, pour éviter que YAML ne le transforme en entier
      initialDelaySeconds: 3
      periodSeconds: 3
9

Merci, Kane ! Je t’en suis vraiment reconnaissant. C’est ce que j’essaie, et il semble que ça fonctionne, mais j’attendais jusqu’à demain pour voir si cela fonctionne vraiment. :wink:

10

Je pense que par défaut, @sam, cette route ne devrait pas être comptée. Je ne vois aucun intérêt à compter les « pageviews » pour cette route… toi ?

11

Bien sûr, nous pouvons ajouter une solution de contournement ici. C’est juste un peu délicat à tester et nous n’avons pas de modèle clair pour contourner.

13

Les réponses devraient déjà être exclues du suivi des vues car elles sont de type text/plain et non text/html.

Quel est le chemin exact que GoogleHC a sollicité ? S’il a sollicité /, c’est là que réside le problème ; le comptage des vues était alors correct.

14

Hmm. Je pense avoir ajouté les en-têtes décrits ci-dessus à la fois à K8s et à l’équilibreur de charge, et qu’ils accèdent tous deux à /srv/status, j’en suis presque certain. Pourtant, je reçois toujours exactement 12 960 requêtes par jour, la plupart des jours. Je vais y jeter un autre coup d’œil sous peu.

Merci pour votre aide !

15

C’était bien le problème. Je pensais avoir configuré à la fois l’équilibreur de charge et le contrôle de santé k8s pour toucher /srv/status, mais l’un d’eux touchait /. Donc, quand j’ai enfin compris comment corriger cela, le problème a disparu.

La bonne nouvelle, c’est que l’ajout de Discourse-Track-View n’est pas nécessaire !

Maintenant, il faut que tous mes contrôles de santé d’uptime robot utilisent /srv/status.