Считаются ли запросы к /srv/status как краулеры?

У меня запущен сайт с 3 подами Kubernetes (так они и хотели!). Статистика краулера показывает > 120 тыс. просмотров страниц в день. При этом пользователей очень мало, а постов меньше 1000, поэтому краулинга практически не должно быть. Если несколько минут следить за production.log одного из подов, видно только трафик к /srv/status, который k8s использует как монитор работоспособности. Должен ли этот трафик учитываться как краулер? Может, я что-то упускаю?

Нет, это не должно учитываться.

120 тысяч — это как раз то, что нужно при постоянной скорости 5 тысяч в час, так что, похоже, их учитывают, хотя не должны.

Возможно, что-то пошло не так в детекции?

Я могу подтвердить, что они учитываются (и логируются с 127.0.0.1)

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

РЕДАКТИРОВАНИЕ: также, как выяснилось, я плохо считаю, и это ~12 тыс. в день.

И это тоже сбивает с толку, потому что если выполнить grep -c /srv/status в трёх подах, то в каждом из них за 20 часов работы будет найдено около 15 тыс. строк, содержащих /srv/status. Таким образом, это должно составлять около 50 тыс. в день.

Они учитываются, и если вы не хотите, чтобы они учитывались, у вас есть четкая возможность, которой вы можете воспользоваться: discourse/lib/middleware/request_tracker.rb at main · discourse/discourse · GitHub

Установите HTTP-заголовок Discourse-Track-View в значение 0 для исходного запроса.

Ценю, что вы переоцениваете мою понятливость. :wink:

Это почти понятно.

Хорошо, значит, мне действительно нужно установить HTTP_DISCOURSE_TRACK_VIEW=false в переменных окружения (ENV), передаваемых контейнеру при его запуске? Или же мне нужно добиться того, чтобы запрос к /srv/status включал заголовок Discourse-Track-View: 0? (возможно, там используется =, но я, наверное, сам разберусь).

РЕДАКТ: Кажется, это сработало (спасибо, @Falco!), но я отпишусь завтра, когда смогу точно сказать, что всё работает.

РЕДАКТ2: В GKE есть не только проверки работоспособности от k8s, но и от балансировщика нагрузки, поэтому оба этих механизма нужно настроить с заголовком Discourse-Track-View: 0.

Последний. Предполагая, что у этого инструмента есть возможность использовать пользовательские заголовки :sweat_smile:

Да, пользовательские заголовки:

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:
        # отправлено https://github.com/discourse/discourse/pull/9136
        path: /srv/status?shutdown_ok=1
        port: 80
        httpHeaders:
        - name: Discourse-Track-View
          value: "0"  # обратите внимание на кавычки, чтобы yaml не интерпретировал значение как целое число
      initialDelaySeconds: 3
      periodSeconds: 3

Спасибо, Кейн! Я очень ценю это. Я именно это и пытаюсь сделать, и похоже, что это работает, но я ждал до завтра, чтобы убедиться, что это действительно работает. :wink:

Я считаю, что по умолчанию этот маршрут @sam не должен учитываться. Я не вижу смысла когда-либо подсчитывать «просмотры страниц» для этого маршрута… А вы?

Конечно, мы можем добавить обход здесь, но его немного сложно тестировать, и у нас пока нет чёткого шаблона для обхода.

Ответы уже должны быть исключены из отслеживания просмотров, так как они имеют тип text/plain, а не text/html.

Какой именно путь запрашивал GoogleHC? Если это был /, то проблема именно в этом; подсчет просмотров был выполнен верно.

Хм. Кажется, я добавил описанные выше заголовки и в K8s, и в балансировщик нагрузки, и они оба обращаются к /srv/status. Я почти уверен. И всё равно почти каждый день получаю ровно 12 960 запросов. Сейчас ещё раз всё проверю.

Спасибо за помощь!

Это и было проблемой. Я думал, что настроил и балансировщик нагрузки, и проверку работоспособности в k8s на /srv/status, но один из них обращался к /. Поэтому, когда я наконец понял, как это исправить, проблема исчезла.

Отличная новость: добавлять Discourse-Track-View не нужно!

Теперь нужно настроить все проверки работоспособности моего uptime robot на /srv/status.