¿Cuentan los hits a /srv/status como rastreadores?

Comunidad Datos e informes
1

Tengo un sitio ejecutando 3 pods de Kubernetes (¡eso es lo que querían!). Las estadísticas del rastreador muestran más de 120.000 visitas por día. Hay… muy pocos… usuarios y menos de 1000 publicaciones, por lo que no hay mucho rastreo que realizar. Observar el production.log de uno de los pods durante unos minutos solo muestra tráfico hacia /srv/status, que k8s utiliza como monitor de estado. ¿Debería eso contarse como un rastreador? ¿Hay algo más que pueda estar pasando por alto?

2

No, eso no debería contar.

3

120K es justo lo correcto para una tasa constante de 5k/h, así que diría que los están contando, aunque no deberían.

¿Quizás algo está fallando en la detección?

4

Puedo confirmar que se están contando (y se registran desde 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: además, al parecer no se me dan bien los números, y son aproximadamente 12 mil por día.

image
image927×655 43.4 KB

image
image1192×302 24.8 KB

Y esto también es confuso porque si ejecuto grep -c /srv/status en los 3 pods, cada uno tiene aproximadamente 15 mil líneas que coinciden con /srv/status en las 20 horas que llevan activos. Eso daría cerca de 50 mil por día.

5

Se cuentan y, si no deseas que se cuenten, tienes una opción clara que puedes usar:

Establece el encabezado HTTP Discourse-Track-View en 0 en la solicitud de origen.

6

Agradezco que sobreestimes lo que es claro para mí. :wink:

Eso es casi claro.

Vale, ¿así que sí necesito establecer HTTP_DISCOURSE_TRACK_VIEW=false en las variables de entorno (ENV) que se pasan al contenedor al iniciarse? ¿Y/O logro que lo que hace peticiones a /srv/status incluya un encabezado Discourse-Track-View: 0? (o quizás sea un =, pero supongo que podré averiguarlo).

EDIT: Creo que eso funcionó (gracias, @Falco!), pero volveré a informar mañana cuando pueda confirmar con seguridad que funcionó.

EDIT2: Y GKE no solo tiene comprobaciones de estado desde k8s, sino también desde el equilibrador de carga, por lo que ambos deben configurarse con el encabezado Discourse-Track-View: 0.

7

Lo segundo. Asumiendo que el sistema tenga la función para permitirte usar encabezados personalizados :sweat_smile:

8

Sí, encabezados 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 https://github.com/discourse/discourse/pull/9136
        path: /srv/status?shutdown_ok=1
        port: 80
        httpHeaders:
        - name: Discourse-Track-View
          value: "0"  # nota las comillas, para evitar que yaml lo convierta en un entero
      initialDelaySeconds: 3
      periodSeconds: 3
9

¡Gracias, Kane! Lo aprecio mucho. Eso es lo que estoy intentando y parece que está funcionando, pero estaba esperando hasta mañana para ver si realmente funciona. :wink:

10

Creo que, por defecto, @sam, esta ruta no debería contarse. No veo ningún valor en contar nunca las “vistas de página” de esta ruta… ¿tú sí?

11

Claro, podemos agregar una omisión aquí; solo es un poco complicado probarla y no tenemos un patrón limpio para omitirla.

13

Las respuestas ya deberían estar excluidas del seguimiento de vistas porque son de tipo text/plain y no text/html.

¿Cuál era la ruta exacta que GoogleHC estaba accediendo? Si estaba accediendo a /, ese es tu problema; y el recuento de vistas era correcto.

14

Hmm. Creo que añadí los encabezados descritos anteriormente tanto a K8s como al equilibrador de carga, y estoy bastante seguro de que ambos están accediendo a /srv/status. Sin embargo, sigo recibiendo exactamente 12.960 visitas al día la mayoría de los días. Le echaré otro vistazo en breve.

¡Gracias por tu ayuda!

15

Ese era el problema. Pensé que había configurado tanto el balanceador de carga como la comprobación de estado de k8s para que golpearan /srv/status, pero uno de ellos estaba golpeando /. Así que cuando finalmente descubrí cómo arreglar eso, el problema desapareció.

¡La gran noticia es que no es necesario agregar Discourse-Track-View!

Ahora, para que todas mis comprobaciones de estado de uptime robot usen /srv/status.