Hits para /srv/status contam como crawlers?

Comunidade Dados e relatórios
1

Tenho um site rodando com 3 pods do Kubernetes (foi o que eles quiseram!). As estatísticas do rastreador mostram mais de 120 mil visualizações de página por dia. Há… muito poucos… usuários e menos de 1000 posts, então não há muita atividade de rastreamento para ser feita. Observar o production.log de um dos pods por alguns minutos mostra apenas tráfego para /srv/status, que o Kubernetes está usando como monitor de saúde. Isso deveria ser contado como rastreamento? Estou deixando passar algo?

2

Não, isso não deve ser contado.

3

120K está bem no ponto para uma taxa constante de 5k/h, então eu diria que eles estão sendo contados, mesmo não devendo.

Talvez algo esteja dando errado na detecção?

4

Posso confirmar que eles estão sendo contados (e estão sendo registrados a partir de 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: Além disso, pareço ser ruim com números, aparentemente, e são ~12K/dia.

image
image927×655 43.4 KB

image
image1192×302 24.8 KB

E isso também é confuso, porque se eu fizer grep -c /srv/status nos 3 pods, cada um tem ~15K de linhas correspondentes a /srv/status nas 20 horas em que estiveram ativos. Isso daria perto de 50K/dia.

5

Eles são contados e, se você não quiser que sejam contados, há uma opção clara que você pode usar:

Defina o cabeçalho HTTP Discourse-Track-View como 0 na solicitação de origem.

6

Agradeço que você superestime o que está claro para mim. :wink:

Isso está quase claro.

Certo, então eu realmente preciso definir HTTP_DISCOURSE_TRACK_VIEW=false nas variáveis de ambiente passadas para o contêiner quando ele é iniciado? Ou devo arranjar uma maneira de fazer com que o serviço que acessa /srv/status inclua um cabeçalho Discourse-Track-View: 0? (ou talvez seja =, mas presumo que consiga descobrir isso).

EDIT: Acredito que isso tenha resolvido (obrigado, @Falco!), mas voltarei a relatar amanhã quando puder confirmar com certeza que funcionou.

EDIT2: E o GKE não possui apenas verificações de saúde do k8s, mas também verificações de saúde do balanceador de carga, então ambos precisam ser configurados com o cabeçalho Discourse-Track-View: 0.

7

A segunda. Supondo que o recurso permita o uso de cabeçalhos personalizados :sweat_smile:

8

Sim, cabeçalhos personalizados:

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:
        # enviado em https://github.com/discourse/discourse/pull/9136
        path: /srv/status?shutdown_ok=1
        port: 80
        httpHeaders:
        - name: Discourse-Track-View
          value: "0"  # observe as aspas, para evitar que o YAML interprete como um inteiro
      initialDelaySeconds: 3
      periodSeconds: 3
9

Obrigado, Kane! Agradeço muito isso. É isso que estou tentando, e parece que está funcionando, mas estou esperando até amanhã para ver se realmente está dando certo. :wink:

10

Acho que, por padrão, @sam, essa rota não deve ser contada. Não vejo valor em contar “visualizações de página” para essa rota… você vê?

11

Claro, podemos adicionar uma bypass aqui. É apenas um pouco complicado de testar e não temos um padrão claro para bypass.

13

As respostas já devem estar excluídas do rastreamento de visualizações, pois são do tipo text/plain e não text/html.

Qual é o caminho exato que o GoogleHC estava acessando? Se ele estava acessando /, esse é o seu problema; e a contagem de visualizações estava correta.

14

Hmm. Acredito que adicionei os cabeçalhos descritos acima tanto ao K8s quanto ao balanceador de carga, e que ambos estão acessando /srv/status, tenho quase certeza. Ainda estou recebendo exatamente 12.960 acessos por dia na maioria dos dias. Vou dar uma olhada mais detalhada em breve.

Obrigado pela sua ajuda!

15

Esse era o problema. Achei que tivesse configurado tanto o balanceador de carga quanto a verificação de saúde do k8s para acessar /srv/status, mas um deles estava acessando /. Então, quando finalmente descobri como corrigir isso, o problema desapareceu.

A grande notícia é que adicionar o Discourse-Track-View não é necessário!

Agora, preciso fazer com que todos os meus verificadores de saúde do uptime robot usem /srv/status.