# 21. 로깅과 사용 추적

## 21.1 로그란 무엇인가?

#### 로깅을 하는 이유

1. 서버나 프락시의 문제를 찾기 위해
2. 웹 사이트 접근 통개를 내기 위해

#### 일반적으로 로깅하는 필드의 예시

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

## 21.2 로그 포맷

상용/오픈소스 HTTP 어플리케이션은 대부분 표준 로그 포맷을 한 개 이상 지원한다.

1. 일반 로그 포맷(Common Log Format)
2. 혼합 로그 포맷(Combined Log Format)
3. 넷스케이프 확장 로그 포맷
4. 넷스케이프 확장 2 로그 포맷
5. 스퀴드(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 적중 계량하기

클라이언트와 서버 사이에 캐시가 있으면 많은 요청이 서버까지 오지 않고 캐시되어 있는 리소스로 처리되고 끝난다. 따라서 원 서버의 로그 파일에 누락이 발생된다.

#### 누락을 해결하는 방법

1. 원 서버가 의도적으로 페이지의 캐시를 파기한다. 콘텐츠에 대한 요청이 모두 원 서버로 가게 해서 모든 접근을 로깅한다.
2. 프락시 캐시의 로그에 접근한다.

### 적중 계량(Hit Metering)

캐시가 정기적으로 캐시 접근 통계를 원 서버에 보고하도록 하는 HTTP 확장이다. 널리 구현되어 있거나 사용되는 규약은 아니다. (2020년 현재 전혀 사용되지 않는다.) 캐시와 서버가 `meter` 헤더에 사용량, 사용 제한, 응답 횟수, timeout 등을 설정하여 사용량 정보를 주고받는다. 캐시는 리소스를 재검사할 때 서버에 적중 횟수를 보고한다.

### 개인 정보 보호

개발자와 관리자는 사용자의 HTTP 트랜잭션을 추적하고 있다는 것을 유념해야 한다. 웹 서버와 프락시는 최종 사용자의 개인 정보를 보호하는데 신경써야 한다. 트랜잭션을 감시하는 경우 관리자는 이 사실을 공지해야 한다. 로깅은 유용한 도구이지만, 로깅을 당하는 사용자들의 인지나 허가가 없으면 로깅은 사생활 침해가 된다.