Thinking
Ideveloper's
ideveloper
Feb 23, 2020 - 6 min read
로깅과 사용 추적
이 글은 HTTP 완벽가이드 21장을 참고해 정리한 포스팅입니다.
시작하기에 앞서
모든 서버와 프락시는 처리한 HTTP 트랜잭션을 요약해서 기록해 놓습니다. 그 이유는 사용추적, 보안, 청구, 에러탐지 등 여러가지 입니다.
로그란 무엇인가?
로깅을 하는 대개 두가지 이유입니다.
- 서버나 프락시의 문제를 찾을 때
- 웹 사이트의 접근 통계를 낼 때
HTTP 트랜잭션의 모든 헤더를 로깅할 수는 있지만, 모든 데이터를 그대로 로깅하면 별 연관이 없고 볼일 없는 데이터만 로깅할수도 있습니다. 따라서, 보통은 트랜잭션의 기본적인 항목들만 로깅을 합니다. 일반적으로 로깅하는 필드는 아래와 같습니다.
- HTTP 메서드
- 클라이언트와 서버의 HTTP 버전
- 요청받은 리소스의 URL
- 응답의 HTTP 상태코드
- 요청과 응답 메시지의 크기(모든 엔터티 본문 포함)
- 트랜잭션이 일어난 시간
- Referer와 User-Agent 헤더 값
로그 포맷
로그 포맷에는 여러 표준이 있습니다. 상용 혹은 오픈 소스 HTTP 애플리케이션은 대부분 표준 로그 포맷을 한개 이상 지원합니다. 그리고 그 애플리케이션 대부분이 로그 포맷을 설정하고 자체 맞춤 포맷을 만들 수 있는 설정 기능을 제공합니다.
일반 로그 포맷
요즘 사용하는 가장 일반적인 포맷 중 하나는, 일반 로그 포맷(Common Log Format)입니다. 본래 NCSA가 정의했고, 많은 서버가 이 로그 포맷을 기본으로 사용합니다.
아래는 일반 로그 포맷(Common Log Format)의 필드를 순서대로 나열한 표입니다.
| 필드 | 설명 |
|---|---|
| remotehost | 요청한 컴퓨터의 호스트명 혹은 IP 주소 |
| username | ident 검색을 수행했다면, 인증된 요청자의 사용자 이름이 있음 |
| auth-username | 인증을 수행했다면, 인증된 요청자의 이름이 있음 |
| timestamp | 요청 날짜와 시간 |
| request-line | HTTP 요청의 행을 그대로 기술. 예를 들어 "GET /index.html HTTP/1.1 |
| response-code | 응답으로 보내는 HTTP 상태코드 |
| response-size | 응답엔터티의 Content-Length |
example
127.0.0.1 user-identifier frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326혼합 로그 포맷 (Combined Log Format)
많이 사용하는 또 다른 로그 포맷은 혼합 로그 포맷입니다. 이 포맷은 아파치 같은 서버들이 지원합니다. 혼합 로그 포맷은 필드 두개가 추가된것 이외에는 일반 로그 포맷과 매우 유사합니다.
그 추가된 필드 두개는 아래와 같습니다. Referer 필드는 이 URL을 요청자가 어디서 찾았는지에 대한 정보를 제공하며, User-Agent 필드는 요청을 만든 HTTP 클라이언트 애플리케이션이 무엇인지 알아볼때 유용합니다.
| 필드 | 설명 |
|---|---|
| Referer | Referer HTTP 헤더의 값 |
| User-Agent | User-Agent Referer HTTP 헤더의 값 |
example
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"넷스케이프 확장 로그 포맷
넷스케이프의 포맷은 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 | 트랜잭션이 프락시를 거칠 경우, 요청과 응답이 프락시를 통해 오가는 총 시간 (초단위) |
넷스케이프 확장 로그 관련 같이보면 좋을 아파치 doc 링크
넷스 케이프 확장 2 로그 포맷 관련 아파치 doc 링크
스퀴드 프락시 로그 포맷
- 많은 차세대 프락시 캐시들이
처리, 추적, 로그분석등의 도구들을 활용하려고, 자체 로그 포맷으로 스퀴드 포맷을 적용했습니다.
적중 계량하기 (Hit Metering)
- 클라이언트와 서버사이에 캐시가 있어서, 많은 요청이 서버까지 오지않고 캐시되어 있는 리소스로 처리되고 끝나는 경우가 있습니다. 따라서 요청이 원서버까지 오지 않더라도 정상적으로 처리될 수 있어서, 클라이언트가 콘텐츠에 접근했다는 기록을 남기지 않아 로그 파일에
누락을 발생시킵니다. - 이렇게 로그데이터가 유실되기 때문에, 콘텐츠 제공자는 어쩔 수 없이 중요한 페이지의 캐시를 파기하게 됩니다. (콘텐츠에 대한 요청을 원 서버로 보내기 위함.)
- 적중 계량 (Hit Metering) 규약은 HTTP의 확장으로, 문제의 해결책으로 제시되었습니다. 이는 캐시가 정기적으로 캐시 접근 통계를 원 서버에 보고하도록 하는 것입니다.
개요
- 적중 계량 규약은 캐시와 서버가 접근 정보를 공유하고, 사용할 수 있는 캐시 리소스의 양을 제어할 수 있는 몇 가지 기초적인 기능에 관한 HTTP 확장을 정의합니다.
- 적중 계량 규약은 캐시로 성능을 향상시키면서도 정확한 접근 통계를 제공할 수 있는 방법입니다.
Meter 헤더
- 적중 계량 확장은 Meter라는 새로운 헤더를 추가했습니다. Cache-Control 헤더에 다양한 캐시 지시자를 기술 할 수 있듯이, 캐시나 서버는 Meter헤더에 사용량이나 보고에 관한 지시자가 기술 할 수 있습니다.
적중 계량의 예 -[http 완벽 가이드 책 그림 참고]
- 일반적인 http 트랜잭션과 같지만, 프락시가 보내는 요청과 서버의 응답에 meter 헤더가 추가로 기술되어 있습니다. 여기서 프락시가 적중 계량을 할수 있다고 서버에게 알리고, 서버는 프락시에 적중 횟수를 요구합니다.
개인 정보 보호에 대해
- 실제 로깅은 서버와 프락시에서 수행하는 관리 기능이므로, 모든 것이 사용자의 트랜잭션에 적용됩니다. 사용자는 자신의 HTTP 트랜 잭션이 로깅되고 있다는 것을 모를 수 있습니다.
- 따라서, 로깅기능을 하는 웹 서버와 프락시는 최종 사용자의 개인 정보를 보호하는데 신경을 많이 써야 합니다.
