21. 로깅과 사용 추적
21.1 로그란 무엇인가?
로깅을 하는 이유
서버나 프락시의 문제를 찾기 위해
웹 사이트 접근 통개를 내기 위해
일반적으로 로깅하는 필드의 예시
HTTP 메서드
클라이언트와 서버의 HTTP 버전
요청받은 리소스의 URL
응답의 HTTP 상태 코드
요청과 응답 메시지의 크기(모든 엔터티 본문을 포함)
트랜잭션이 일어난 시간
Referer와 User-Agent 헤더 값
21.2 로그 포맷
상용/오픈소스 HTTP 어플리케이션은 대부분 표준 로그 포맷을 한 개 이상 지원한다.
일반 로그 포맷(Common Log Format)
혼합 로그 포맷(Combined Log Format)
넷스케이프 확장 로그 포맷
넷스케이프 확장 2 로그 포맷
스퀴드(Squid) 프락시 로그 포맷
일반 로그 포맷
필드
필드 | 설명 |
remotehost | 호스트명 또는 IP 주소 |
username | (ident 검색 수행시) 인증된 요청자의 이름 |
auth-username | (인증시) 인증된 요청자의 이름 |
timestamp | 요청 날짜와 시간 |
request-line | HTTP request 행 |
response-code | 응답으로 보내는 HTTP 상태 코드 |
response-size | 응답 엔터티의 Content-Length |
혼합 로그 포맷
일반 로그 포맷에 두 가지 필드가 추가된 것. 아파치 등에서 지원.
필드
필드 | 설명 |
Referer | Referer HTTP 헤더 값 |
User-Agent | User-Agent Referer HTTP 헤더 값 |
스퀴드 프락시 로그 포맷
필드 | 설명 |
timestamp | 요청이 도착한 시간 |
time-elapsed | 요청과 응답이 프락시를 통해 오고간 총 시간 |
host-ip | 클라이언트의 호스트 IP |
result-code/status | 요청에 대해 프락시가 어떤 일을 했는지 스퀴드 방식으로 기술(result) 및 프락시가 클라이언트에 보낸 HTTP 응답 코드 (code) |
size | 프락시가 클라이언트에게 보낸 HTTP 응답 헤더와 본문을 포함한 응답의 길이 |
method | 클라이언트 요청의 HTTP 메서드 |
url | 클라이언트 요청의 URL |
rfc931-ident | 클라이언트에 인증된 사용자 이름 |
hierarchy/from | 프락시가 클라이언트로 요청을 보내면서 거친 경로(hierarchy) 및 요청을 만들게 한 서버(from) |
content-type | 프락시 응답 엔터티의 Content-Type |
21.3 적중 계량하기
클라이언트와 서버 사이에 캐시가 있으면 많은 요청이 서버까지 오지 않고 캐시되어 있는 리소스로 처리되고 끝난다. 따라서 원 서버의 로그 파일에 누락이 발생된다.
누락을 해결하는 방법
원 서버가 의도적으로 페이지의 캐시를 파기한다. 콘텐츠에 대한 요청이 모두 원 서버로 가게 해서 모든 접근을 로깅한다.
프락시 캐시의 로그에 접근한다.
적중 계량(Hit Metering)
캐시가 정기적으로 캐시 접근 통계를 원 서버에 보고하도록 하는 HTTP 확장이다. 널리 구현되어 있거나 사용되는 규약은 아니다. (2020년 현재 전혀 사용되지 않는다.) 캐시와 서버가 meter 헤더에 사용량, 사용 제한, 응답 횟수, timeout 등을 설정하여 사용량 정보를 주고받는다. 캐시는 리소스를 재검사할 때 서버에 적중 횟수를 보고한다.
개인 정보 보호
개발자와 관리자는 사용자의 HTTP 트랜잭션을 추적하고 있다는 것을 유념해야 한다. 웹 서버와 프락시는 최종 사용자의 개인 정보를 보호하는데 신경써야 한다. 트랜잭션을 감시하는 경우 관리자는 이 사실을 공지해야 한다. 로깅은 유용한 도구이지만, 로깅을 당하는 사용자들의 인지나 허가가 없으면 로깅은 사생활 침해가 된다.
Last updated