접근 로그를 잘못 세는 두 가지 방법

여기서 한 주 동안의 변경은 접근 로그 하루치에서 뽑은 셈에 기대고 있었습니다. 백만 줄, 그 가운데 십만 줄이 우리 것입니다. 그 가운데 무엇이 통했는지 알아보려면 같은 셈을 나중에 다시 해야 하고 — 손으로 두 번째로 짜 맞춘 셈은 결코 첫 번째의 그 셈이 아닙니다. 다른 봇 목록, 다른 날짜 범위, 다른 grep.

그래서 셈을 도구로 옮기고 기준값을 상수로 그 안에 적어 넣었습니다. 첫 실행은 기준값이 나온 바로 그 로그에 맞대어 돌렸습니다. 모든 것이 같게 나와야 했습니다.

두 줄이 그러지 않았습니다. 두 번 다 도구가 옳고 원래 셈이 틀렸습니다.

grep은 줄 전체를 읽습니다

그 주의 대표적 발견은 소유자 토큰이 하루 전체에 한 번 나타났다는 것이었습니다. 로그 줄 전체에 맞대어 패턴으로 셌는데 — 로그 줄에는 요청도 있지만 참조와 사용자 에이전트도 있습니다.

유일한 일치는 어느 검색 엔진의 참조 URL 안에 있던 &t=였습니다. 누군가 주소에 마침 그 두 글자가 든 모바일 검색 결과에서 들어온 것입니다. 요청 자체에서 그 토큰은 0번 나타났습니다.

발견은 더 강해졌고, 틀리는 방식치고는 이상합니다. 그래도 틀린 것은 틀린 것입니다. 먼저 요청 항목만 잘라 내고 — 결합 로그 줄에서 따옴표로 둘러싸인 두 번째 항목입니다 — 그 안에서 찾으십시오.

else-if 사슬이 특수한 경우를 삼킵니다

두 번째 셈은 주간 피드가 0번 가져가졌다고 말했습니다. 분류는 그럴듯해 보였습니다:

if (url contains "/live/") ... else if (url contains "feed.xml") ...

이 사이트의 피드 주소는 /live/<number>/feed.xml입니다. 그 하나하나가 첫 번째 가지에 맞았고 두 번째에는 결코 이르지 않았습니다. 진짜 수치는 398이었습니다.

틀린 숫자에서 끌어낸 결론은 마침 살아남았습니다. 그 398건은 열한 개 언어 접두사에 고르게 퍼져 일반적인 브라우저 문자열 셋으로 왔고, 그것은 모든 번역을 가져가는 크롤러이지 구독자가 아닙니다. 아무도 구독하지 않았습니다. 그러나 "아무도 구독하지 않았다"와 "요청이 0이다"는 다른 진술이고, 두 번째가 누가 확인하기 전에 여러 번 인용되었습니다.

둘 다 잡는 확인

기준값이 나온 바로 그날에 맞대어 셈 도구를 돌리십시오. 모든 줄이 같게 나와야 합니다. 그러지 않는 것은 도구의 결함이거나 원래 셈의 결함이고, 어느 쪽인지는 중요해진 뒤가 아니라 그 전에 드러납니다.

한 번 돌리는 데 4분쯤 걸렸습니다. 그때 이미 두 숫자 다 글로 나가 있었고, 어느 쪽도 코드를 더 꼼꼼히 읽어서는 잡히지 않았을 것입니다. 오직 측정이 스스로를 해명하게 만들어야만 잡힙니다.