3개의 Kubernetes 포드(클라이언트가 그렇게 원했기 때문!)로 실행 중인 사이트가 있습니다. 크롤러 통계에 따르면 하루 120,000회 이상의 페이지뷰가 발생하고 있습니다. 그런데 사용자는 … 매우 적고 … 게시글도 1,000개 미만이라 크롤링할 양이 많지 않습니다. 포드 중 하나에서 production.log를 몇 분간 살펴보면, k8s가 헬스 모니터로 사용하는 /srv/status로의 트래픽만 보입니다. 이 트래픽도 크롤러로 집계되어야 하나요? 제가 놓치고 있는 다른 부분이 있을까요?
아니요, 그것은 계산에 포함되지 않아야 합니다.
120K는 시간당 5k의 일정한 수치와 정확히 일치하므로, 원래는 집계되지 않아야 하는데도 실제로는 집계되고 있는 것으로 보입니다.
혹시 감지 과정에서 문제가 있는 건 아닌지 궁금합니다.
그들이 카운트되고 있다는 것을 확인했습니다 (그리고 127.0.0.1에서 로깅되고 있습니다)
SELECT * from web_crawler_requests
where date = '2020-03-05'
order by count desc
수정: 또한, 숫자 계산에 서툼을 드러냈는데, 실제로는 하루 약 12K 건입니다.
이것도 혼란스러운 부분인데, 3개의 팟에서 grep -c /srv/status를 실행하면 각각 20시간 동안 가동된 동안 /srv/status와 일치하는 약 15K줄의 로그가 있습니다. 그렇다면 하루 기준 약 50K 건에 가까워집니다.
이들은 카운트되며, 카운트되지 않기를 원하시면 사용할 수 있는 명확한 옵션이 있습니다.
출처 요청에서 Discourse-Track-View HTTP 헤더를 0으로 설정하세요.
제가 명확하게 파악할 수 있는 범위를 과대평가해 주셔서 감사합니다. 
거의 명확합니다.
자, 그러면 컨테이너가 시작될 때 전달되는 ENV에 HTTP_DISCOURSE_TRACK_VIEW=false를 설정해야 한다는 말씀이신가요? 그리고/또는 /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" # 정수로 변환되지 않도록 따옴표에 주의
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로 사용하도록 설정해야 합니다.