У меня запущен сайт с 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 для исходного запроса.
Ценю, что вы переоцениваете мою понятливость. ![]()
Это почти понятно.
Хорошо, значит, мне действительно нужно установить HTTP_DISCOURSE_TRACK_VIEW=false в переменных окружения (ENV), передаваемых контейнеру при его запуске? Или же мне нужно добиться того, чтобы запрос к /srv/status включал заголовок Discourse-Track-View: 0? (возможно, там используется =, но я, наверное, сам разберусь).
РЕДАКТ: Кажется, это сработало (спасибо, @Falco!), но я отпишусь завтра, когда смогу точно сказать, что всё работает.
РЕДАКТ2: В GKE есть не только проверки работоспособности от k8s, но и от балансировщика нагрузки, поэтому оба этих механизма нужно настроить с заголовком Discourse-Track-View: 0.
Последний. Предполагая, что у этого инструмента есть возможность использовать пользовательские заголовки ![]()
Да, пользовательские заголовки:
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
Спасибо, Кейн! Я очень ценю это. Я именно это и пытаюсь сделать, и похоже, что это работает, но я ждал до завтра, чтобы убедиться, что это действительно работает. ![]()
Я считаю, что по умолчанию этот маршрут @sam не должен учитываться. Я не вижу смысла когда-либо подсчитывать «просмотры страниц» для этого маршрута… А вы?
Конечно, мы можем добавить обход здесь, но его немного сложно тестировать, и у нас пока нет чёткого шаблона для обхода.
Ответы уже должны быть исключены из отслеживания просмотров, так как они имеют тип text/plain, а не text/html.
Какой именно путь запрашивал GoogleHC? Если это был /, то проблема именно в этом; подсчет просмотров был выполнен верно.
Хм. Кажется, я добавил описанные выше заголовки и в K8s, и в балансировщик нагрузки, и они оба обращаются к /srv/status. Я почти уверен. И всё равно почти каждый день получаю ровно 12 960 запросов. Сейчас ещё раз всё проверю.
Спасибо за помощь!
Это и было проблемой. Я думал, что настроил и балансировщик нагрузки, и проверку работоспособности в k8s на /srv/status, но один из них обращался к /. Поэтому, когда я наконец понял, как это исправить, проблема исчезла.
Отличная новость: добавлять Discourse-Track-View не нужно!
Теперь нужно настроить все проверки работоспособности моего uptime robot на /srv/status.


