[HTTP] 로깅과 사용 추적

 

거의 모든 서버와 프락시는 처리했던 HTTP 트랜잭션을 요약해서 기록해 놓는다. 

---

#1. 로그란 무엇인가?

 

대게 로깅을 하는 이유는 두 가지다. 서버나 프락시의 문제를 찾거나, 웹 사이트 접근 통계를 내려고 로깅을 한다. 

보통 트랜잭션의 기본적인 항목들만 로깅한다.

• HTTP 메서드
• 클라이언트와 서버의 HTTP 버전
• 요청받은 리소스의 URL
• 응답의 HTTP 상태 코드
• 요청과 응답 메시지의 크기(모든 엔터티 본문을 포함)
• 트랜잭션이 일어난 시간
• Referer와 User-Agent 헤더 값

---

#2. 로그 포맷

상용 혹은 오픈 소스 HTTP 애플리케이션은 대부분 표준 로그 포맷을 한 개 이상 지원한다. 그리고 그 애플리케이션 대부분이 로그 포맷을 설정하고 자체 맞춤 포맷을 만들 수 있는 설정 기능을 제공한다.

---

일반 로그 포맷(Common Log Format)

많은 서버가 이 로그 포맷을 기본으로 사용한다. 대부분의 상용 혹은 오픈 소스 서버는 이 포맷을 사용하게 설정할 수 있다.

필드	설명
remotehost	요청한 컴퓨터의 호스트 명 혹은 IP 주소
username	ident 검색을 수행, 인증된 요청자의 사용자 이름이 있다.
auth-username	인증을 수행했다면, 인증된 요청자의 이름이 있다.
timestamp	요청 날짜와 시간
request-line	HTTP 요청의 행을 그대로 기술한다.
response-code	응답으로 보내는 HTTP 상태코드
response-size	응답 엔터티의 Content-Length

---

혼합 로그 포맷(Combined Log Format)

이 포맷은 아파치 같은 서버들이 지원한다. 혼합 로그 포맷은 일반 로그 포맷과 매우 유사하다. 추가된 필드 두 개를 제외하면 똑같다.

필드	설명
Referer	Referer HTTP 헤더의 값
User-Agent	User-Agent Referer HTTP 헤더의 값

---

넷스케이프 확장 로그 포맷

넷스케이프의 포맷은 NCSA 일반 로그 포맷에서 시작했지만 프락시나 웹 캐시 같은 HTTP 애플리케이션과 연관이 있는 여러 환경을 지원하려고 포맷을 확장했다.

필드	설명
proxy-response-code	트랜잭션이 프락시를 거칠 경우 서버에서 프락시로의 HTTP 응답코드
proxy-response-size	트랜잭션이 프락시를 거칠 경우 서버가 프락시에 전달하는 응 답 엔터티의 Content-Length
client-request-size	클라이언트가 프락시로 보내는 요청의 본문이나 엔터티의 Content-Length
proxy-request-size	트랜잭션이 프락시를 거칠 경우 프락시가 서버로 보내는 요청의 본문이나 엔터티의 Content-Length
client-request-hdr-size	클라이언트 요청 헤더의 바이트 길이
proxy-response-hdr-size	트랜잭션이 프락시를 거칠 경우 프락시가 요청자에게 보내는 응답 헤더의 바이트 길이
proxy-request-hdr-size	트랜잭션이 프락시를 거칠 경우, 프락시가 서버로 전송하는 요청 헤더의 바이트 길이
server-response-hdr-size	서버 응답 헤더의 바이트 길이
proxy-timestamp	트랜잭션이 프락시를 거칠 경우 요청과 응답이 프락시를 통해 오가는 총 시간(초 단위)

---

넷스케이프 확장 2 로그 포맷

확장 로그 포맷에서 HTTP 프락시와 웹 캐시 애플리케이션과 관련한 더 많은 정보를 포함한다.

필드	설명
route	프락시가 클라이언트에 요청을 만드는 데 사용하는 경로
client-finish-status-code	클라이언트의 종료 상태 코드로 프락시로 보낸 요청이 성공적으로 완료되었는지 혹은 인터럽트에 걸렸는지 기술한다.
proxy-finish-status-code	프락시의 종료 상태 코드로 프락시가 서버로 보낸 요청이 성공적으로 완료되었는지 혹은 인터럽트에 걸렸는지 기술한다.
cache-result-code	캐시 결과 코드로 캐시가 요청에 어떻게 응답했는지 기술한다.

---

스퀴드(Squid) 프락시 로그 포맷

스퀴드 프락시 캐시는 웹 분야에서 권위 있는 프로젝트다. 스퀴드는 수년간 오픈 소스 커뮤니티를 통해 확장 및 개선되어 온 프로젝트다. 그리고 스퀴드 애플리케이션을 관리하는 데 도움이 되는 수많은 도구들이 개발되었다. 많은 차세대 프락시 캐시들이 이러한 도구를 활용하려고 자체 로그 포맷으로 스퀴드 포맷을 적용했다.

필드	설명
timestamp	요청이 도착한 시간을 GMT 1970년 1월 1일을 기준으로 지난 시간을 초 단위로 기술
time-elapsed	요청과 응답이 프락시를 통해 오고간 총 시간을 밀리초로 기술
host-ip	클라이언트의 호스트 장비 IP 주소
result-code/status	result 필드에는 이 요청에 프락시가 어떤 일을 했는지 스퀴드 방식으로 기술, code 필드는 프락시가 클라이언트에 보낸 HTTP 응답 코드
size	프락시가 클라이언트에게 보낸 HTTP 응답 헤더와 본문을 포함한 응답의 길이가 바이트 단위로 기술
method	클라이언트 요청의 HTTP 메서드
url	클라이언트 요청의 URL
rfc931-ident	클라이언트에 인증된 사용자 이름
hierarchy/from	hierarchy 필드는 프락시가 클라이언트로 요청을 보내면서 거친 경로, from 필드는 프락시가 요청을 만들게 한 서버의 이름을 기술
content-type	프락시 응답 엔터티의 Content-Type

---

#3. 적중 계량하기(Hit Metering)

• 캐시는 수많은 HTTP 요청을 처리하므로 요청이 원 서버까지 오지 않더라도 정상적으로 처리될 수 있어서 클라이언트가 콘텐츠에 접근했다는 기록을 남기지 않아 결국엔 로그 파일에 누락을 발생시킨다.
• 로그 데이터가 유실되기 때문에 콘텐츠 제공자는 어쩔 수 없이 중요한 페이지의  캐시를 파기할 수도 있다.
• 캐시를 파기시켜 로깅을 문제없이 할 수 있지만 요청에 대한 응답 속도는 느려지고 원 서버와 네트워크의 부하가 가중된다.

적중 계량(Hit Metering) 규약은 HTTP의 확장으로 문제의 해결책으로 제시되었다. 적중 계량 규약에서는 캐시가 정기적으로 캐시 접근 통계를 원 서버에 보고하도록 한다. (RFC 2227)

적중 계량의 예

---

 

참고 자료

• HTTP완벽가이드 , 인사이트