HTTP 완벽 가이드 (21)

로그란?

로깅을 하는 이유

1. 서버나 프록시의 문제 찾기
2. 웹 사이트 접근 통계 내기

로깅하는 필드

• HTTP 메서드
• 클라이언트와 서버의 HTTP 버전
• 요청받은 리소스의 URL
• 응답의 HTTP 상태 코드 → 요청이 성공적으로 이루어졌는지, 인증 시도가 실패했는지, 리소스를 찾았는지 등 어떤 일이 일어났었는지
• 요청과 응답 메시지의 크기(모든 엔티티 본문을 포함) → 얼마나 많은 바이트를 안팎으로 송수신 / 얼마나 많은 바이트가 애플리케이션을 통해 전송되는지
• 트랜잭션이 일어난 시간 → 문제가 발생 시, 그 시간에 받았던 요청을 찾는 데 사용함.
• Referer와 User-Agent 헤더 값

HTTP 메서드, URL → 어떤 요청이 어떤 일을 하려고 했는지 가리킴

• URL은 웹 사이트의 특정 페이지가 얼마나 인기 있는지 추적하는 데 사용할 수 있음.

버전 정보 - 클/서버에 문제가 생겼을 때 디버깅하는 데 도움이 될 클/서버에 관한 정보 제공

로그 포맷

대부분 표준 로그 포맷을 한 개 이상 지원함.

일반 로그 포맷(Common Log Format)

NCSA 정의, 많은 서버가 기본으로 사용하는 포맷.

209.1.32.44 - - [03/Oct/1999:14:16:00 -0400] "GET / HTTP/1.0" 200 1024
http-guide.com - dg [03/Oct/1999:14:16:32 -0400] "GET / HTTP/1.0" 200 477
http-guide.com - dg [03/Oct/1999:14:16:32 -0400] "GET /foo HTTP/1.0" 404 0

remote-host 필드에는 호스트 명이나 IP 주소가 명시될 수 있다.

user-name , auth-username 필드의 대시는 필드가 비어있음을 의미한다.

• ident 검색이나 인증을 수행하지 않았다는 뜻

혼합 로그 포맷 (Combined Log Format)

필드 설명

Referer	Referer HTTP 헤더의 값
User-Agent	User-Agent Referer HTTP 헤더의 값

이 포맷은 아파치 같은 서버들이 지원하고, CLF와 매우 유사하다.

209.1.32.44 - - [03/Oct/1999:14:16:00 -0400] "GET / HTTP/1.0" 200 1024 "http://www.joes-
hardware.com/"  "5.0: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)"

Referer → http://www.joes-hardware.com/

User-Agent → 5.0: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)

처음 7개의 필드는 일반 로그 포맷의 있는 것과 동일하다. 새로운 필드인 Referer, User-Agent 필드는 로그 엔트리의 끝에 온다.

Netscape Extended Log Format

NCSA의 일반 로그 포맷에 시작, 프록시 or 웹 캐시 같은 HTTP 애플리케이션과 연관이 있는 여러 환경을 지원하려고 포맷을 확장함.

첫 필드 일곱개는 일반 로그 포맷과 같다.

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

209.1.32.44 - - [03/Oct/1999:14:16:00-0400] "GET / HTTP/1.0" **200 1024 200 1024 0 0 215 260 
279 254 3**

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

http 프록시와 웹 캐시 애플리케이션과 관련한 더 많은 정보를 포함

추가된 필드들은 다음과 같다.

• route : 프록시가 클라이언트에 요청을 만드는 데 사용하는 경로
• client-finish-status-code : 클라이언트의 종료 상태 코드
  • 완료(FIN), 인터럽트(INTR)
• proxy-finish-status-code : 프록시의 종료 상태 코드
• cache-result-code : 캐시 결과 코드, 캐시가 요청에 어떻게 응답했는지

209.1.32.44 - - [03/Oct/1999:14:16:00-0400] "GET / HTTP/1.0" 200 1024 200 1024 0 0 215 260 
279 254 3 **DIRECT FIN FIN WRITTEN**

route = DIRECT, 클라이언트와 프록시의 종료 상태 코드는 FIN(완료), 캐시 결과 코드는 WRITTEN이다.

🗺️ route 코드

값 설명

DIRECT	리소스를 서버에서 바로 가져옴
PROXY(host:port)	리소스를 host라는 프록시를 통해 가져왔다.
SOCKS(socks:port)	리소스를 host라는 SOCKS 서버를 통해 가져왔다.

finish status code

값 설명

-	요청이 시작되지 않았음
FIN	요청이 성공적으로 완료됨
INTR	요청이 클라이언트 or 프락시/서버에 의해 종료됨
TIMEOUT	요청이 프록시/서버의 타임아웃에 걸림

cache code

값 설명

-	캐시할 수 없는 리소스
WRITTEN	리소스를 캐시에 저장함
REFRESHED	리소스를 캐시했고 갱신함
NO-CHECK	캐시된 리소스를 반환했고, 신선도 검사를 하지 않음
UP-TO-DATE	캐시된 리소르르 반환했고 신선도 검사를 완료함
HOST-NOT-AVAILABLE	캐시된 리소스를 반환했으며 원격 서버가 사용할 수 있는 상태가 아니었기 때문에 신선도 검사를 하지 않았음
CL-MISMATCH	리소르르 캐시에 저장하지 않았음. Content-Length가 리소스의 크기와 맞지 않았기 때문에 쓰기를 중단함
ERROR	어떤 에러 때문에 리소스를 캐시에 저장하지 못함. ex) 타임아웃이나 클라이언트가 트랜잭션을 중단했을 때

관리자가 수정 가능한 유연한 로그 포맷(Flexible Log Format) 포함 다양한 로그 포맷으로 가지고 있음.

• 트랜잭션의 특정 부분을 선택하여 로그 최적화 가능

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

스퀴드는 웹 프록시 캐시 프로젝트.

• 스퀴드 애플리케이션을 관리하는데 도움되는 도구를 활용하기 위해 자체 로그 포맷으로 스퀴드 포맷을 적용함.

99823414 3001 209.1.32.44 TCP_MISS/200 4087 GET <http://www.joes-hardware.com> - DIRECT/
proxy.com text/html

• timestamp : 요청이 도착한 시간을 GMT 1970년 1월 1일 기준으로 지난 시간을 초 단위로 기술.
• time-elapsed : 요청과 응답이 프록시를 통해 오고간 총 시간을 밀리초로 기술
• host-ip : 클라이언트의 호스트 장비 ip 주소
• result-code/status : 이 요청에 프록시가 어떤 일을 했는지 스퀴드 방식으로 기술. code 필드는 클라이언트에 프록시가 보낸 응답 코드 → TCP_MISS/200
• size
• method : 요청의 http 메서드
• url : 요청의 url
• rfc931-ident : 클라이언트에 인증된 사용자 이름
• hierarchy/from : 경로(route) 필드 길이. hierarchy 필드에는 프록시가 클라이언트로 요청을 보내면서 거친 경로를 기술함. from 필드는 프록시가 요청을 만들기 위해 사용한 서버의 이름을 기술함
• content-type

squid 상태 코드

TCP_HIT	리소스의 유효한 복제본이 캐시에서 전달되었다.
TCP_MISS	캐시 부적중
TCP_REFRESH_HIT	리소스가 캐시에 있지만, 신선도 검사가 필요함.
TCP_REF_FAIL_HIT	신선도 검사 → 재검사 실패, ‘신선하지 않은’ 리소스 반환
TCP_REFRESH_MISS	신선도 검사 → 유통기한이 지났다는 것을 프록시가 인식함. 새로운 버전을 받음.
TCP_CLIENT_REFRESH_MISS	The requestor sent a Pragma: no-cache or similar Cache-Control directive, so the proxy was forced to fetch the resource.
TCP_IMS_HIT	The requestor issued a conditional request, which was validated against the cached copy of the resource.
TCP_SWAPFAIL_MISS	The proxy thought the resource was in the cache but for some reason could not access it.
TCP_NEGATIVE_HIT	A cached response was returned, but the response was a negatively cached response. Squid supports the notion of caching errors for resources—for example, caching a 404 Not Found response—so if multiple requests go through the proxy-cache for an invalid resource, the error is served from the proxy cache.
TCP_MEM_HIT	A valid copy of the resource was served out of the cache, and the resource was in the proxy cache’s memory (as opposed to having to access the disk to retrieve the cached resource).
TCP_DENIED	The request for this resource was denied, probably because the requestor does not have permission to make requests for this resource.
TCP_OFFLINE_HIT	The requested resource was retrieved from the cache during its offline mode. Resources are not validated when Squid (or another proxy using this format) is in offline mode.
UDP_*	The UDP_ codes indicate that requests were received through the UDP interface to the proxy. HTTP normally uses the TCP transport protocol, so these requests are not using the HTTP protocol.[11]*
UDP_HIT	A valid copy of the resource was served out of the cache.
UDP_MISS	The resource was not in the cache.
UDP_DENIED	The request for this resource was denied, probably because the requestor does not have permission to make requests for this resource.
UDP_INVALID	The request that the proxy received was invalid.
UDP_MISS_NOFETCH	Used by Squid during specific operation modes or in the cache of frequent failures. A cache miss was returned and the resource was not fetched.
NONE	Logged sometimes with errors.
TCP_CLIENT_REFRESH	See TCP_CLIENT_REFRESH_MISS.
TCP_SWAPFAIL	See TCP_SWAPFAIL_MISS.
UDP_RELOADING	See UDP_MISS_NOFETCH.

 

적중 계량하기

클라이언트와 서버 사이에 캐시가 있음 → 요청이 서버까지 오지 않고, 캐시되어 있는 리소스로 처리되고 끝남.

• 로그 파일에 누락 발생
• 중요한 페이지의 캐시 파기 → 모든 요청을 원 서버로
  • 응답 속도 저하, 원 서버와 네트워크 부하 가중
• 프록시 캐시들(어떤 클라이언트들) → 자체 로그 유지
  • 서버가 그 로그에 접근 가능
  • 서버의 콘텐츠가 얼마나 자주 캐시에서 제공되는지 알 수 있는 방법
  → 캐시 파기를 피할 수 있음.

Hit Metering

HTTP의 확장으로 캐시가 정기적으로 캐시 접근 통계를 원 서버에 보고하도록 함.

개요

캐시와 서버가 접근 정보를 공유, 사용할 수 있는 캐시 리소스의 양을 제어할 수 있는 몇 가지 기초적인 기능에 관한 HTTP 확장을 정의함.

• 적어도 서버가 원하는 통계 정보를 받아볼 수 있는 방법을 제공함.

Meter 헤더

사용량이나 보고에 관한 지시자를 캐시와 서버 간에 주고받을 수 있음.

캐시 지시자

• will-report-and-limit : 캐시는 사용량을 보고하고 서버가 기술한 모든 사용 제한에 복종해야 함.
• wont-report : 사용 제한에 복종하지만, 사용량 보고는 하지 않음
• wont-limit : 사용량 보고를 하지만, 사용 제한은 없음
• count : 사용횟수/재사용 횟수 → ex) :count=2/4 같은 형태로 작성됨

서버 지시자

• max-uses : 서버가 캐시를 사용해서 응답할 수 있는 최대 횟수 → max-uses=100
• max-reuses : 재사용해서 응답할 수 있는 최대 횟수 → max-reuses=100
• do-report : 서버가 프록시에게 사용량 보고 요구
• dont-report : 사용량 보고를 원하지 않음
• timeout : 서버가 리소스 계량 시 시간 제한을 거는데 사용함. 기술된 타임아웃 시간 정각이나 1분 전후로 보고를 전송해야 함.
• wont-ask : 계량 정보를 원하지 않음

재사용 횟수 = 클라이언트 요청을 다시 검증한 횟수.

사용 횟수 = 요청에 응답한 횟수

 

 

• 클라이언트-프록시 일반적인 HTTP 트랜잭션
• 프록시와 서버 간에는 Meter 헤더가 추가로 기술됨
• Meter: do-report → 사용량 보고를 요구하는 응답을 보냄.

 

---

비즈니스 로그

click log → 고객의 행위 분석

• 고객이 물건을 구매하다 멈춤
• 유도한 이벤트 페이지로 가지 않고 나감

내가 본 건 가장 기본적인 웹 로그

분산 시스템

유니크한 고객 행위 분석

• User1 - Unique ID → 파드 사이를 이동하더라도 똑같이 따라가야 함.
• 각 파드가 로깅을 하는데, 사용자의 로그가 정상인지

API Gateway

분산 트레이싱

• traceId : Header - 유니크 키를 세팅
• Proxy/Gateway같은 것 하나를 SpanID로 표현

Trace ID 1(UUID) - SpanID(23427309) - GateWay - (표준 logging)
Trace ID 1(UUID) - SpanID(23427309) - Server Pod 2 - (표준 logging)
Trace ID 1(UUID) - SpanID(23427309) - API POD 3 - (표준 logging)

개발자 기준의 로그 - 데브옵스

<마케팅 기준의 로그>

페이지 별/기능별 이동

• 메인페이지 → 로그인 → 상품 → 주문서 → 쿠폰 → 결제 → 결제완료

1. CaseID(unique - Trace ID), 페이지번호, 액션, 시간