Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[5부 21장] 로깅과 사용추적 #18

Open
kmswlee opened this issue Oct 9, 2022 · 0 comments
Open

[5부 21장] 로깅과 사용추적 #18

kmswlee opened this issue Oct 9, 2022 · 0 comments

Comments

@kmswlee
Copy link

kmswlee commented Oct 9, 2022

로깅과 사용추적

로그란 무엇인가

대개 로깅을 하는 이유는 두가지.
서버나 프록시의 문제를 찾거나 웹사이트 접근 통계를 내려고 로깅
보통 트랜잭션의 기본적인 항목들만 로깅한다. 일반적으로 로깅하는 필드는 다음과 같다.

  • HTTP 메서드
  • 클라이언트와 서버의 HTTP 버전
  • 요청받은 리소스의 URL
  • 응답의 HTTP 상태 코드
  • 요청과 응답 메시지의 크기
  • 트랜잭션이 일어나는 시간
  • Referer, User-Agent 헤더값

버전 정보는 클아이언트와 서버 간에 문제가 생겼을 때 디버깅하는 데,
도움이 될 클라이언트와 서버에 관한 정보를 제공한다.


로그 포맷

상용 혹은 오픈소스 HTTP 애플리케이션은 대부분 표준 로그 포맷을 한개 이상 지원한다.
많은 오픈소스 혹은 상용 패키지가 통계를 뽑으려고 로그를 분석하는데, 여기에 표준 로그 포맷을 이용해서, 어플리케이션과 관리자가 이러한 리소스들을 잘 활용할 수 있다.

일반 로그 포맷

요즘 가장 일반적인 포맷중 하나는, 일반 로그 포맷이다.
본래 NCSA가 정의 했고, 많은 서버가 이 로그 포맷을 기본으로 사용한다. 대부분의 상용 혹은 오픈소스 서버는 이 포맷을 사용하게 설정할 수 있으며, 일반 로그 포맷 파일을 구문분석하는 수많은 상용 혹은 무료 소프트웨어 도구가 있다.
image

혼합 로그 포맷

많이 사용하는 또다른 로그 포맷.
이 포맷은 아파치 같은 서버들이 지원한다. 일반 로그 포맷과 매우 흡사. 필드 두개가 더 추가 되었다.

  • Referer : Referer HTTP 헤더값
  • User-Agent : User-Agent Referer HTTP 헤더값

넷스케이프 확장 로그 포맷

넷스케이프가 상용 HTTP 어플리케이션이 되면서, 다른 HTTP 어플리케이션 개발자들이 사용하는 서버의 여러 로그 포맷을 도입했다.
image

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

또 다른 넷스케이프 로그 포맷인 넷스케이프 확장 2 로그 포맷은 확장 로그 포맷에서 HTTP 프록시와 웹 캐시 어플리케이션과 관련한 더 많은 정보를 포함한다.

이렇게 추가된 필드들은 HTTP 클라이언트와 HTTP 프록시 어플리케이션 간의 통신을 설계하는데 도움된다.
image

넷스케이프 어플리케이션은 다른 HTTP 어플리케이션과 마찬가지로 출력될 로그의 포맷을, 관리자가 수정할 수 있는 유연한
로그 포맷을 포함한 다양한 로그 포맷을 가지고 있다.
관리자는 추가적인 설정을 해서 로그에 기록할 HTTP 트랜잭션(헤더,상태,크기)의 특정 부분을 선택하여 로그를 최적화 할수 있다.

스퀴드 프록시 로그 포맷

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


적중 계량하기

로깅은 클라이언트가 웹서버에 직접 방문했을 때 이런 것들을 추적하는데 유용.
하지만 클라이언트와 서버 사이에 캐시가 있어서, 많은 요청이 서버까지 오지 않고 캐시되어 있는
리소스로 처리되고 끝난다. 캐시는 수많은 HTTP 요청을 처리하므로, 요청이 서버까지 오지 않더라도
정상적으로 처리될 수 있어서, 클라이언트가 컨텐츠에 접근했다는 기록을 남기지 않아 누락을 발생시킨다.

프록시 캐시들은 자체 로그를 유지하기 때문에, 만약 서버가 그 로그에 접근할 수 있거나, 혹은 적어도 얼마나 자주 서버의 컨텐츠가 프록시 캐시에서 제공되는지 알수 있는 방법이라도 있으면
캐시 파기는 피할수 있을것이다.

적중 계량 규약은 HTTP의 확장으로, 그 문제의 해결책으로 제시 되었다.

개요

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

적중 계량이 문제에 대한 완벽한 해결책은 아니지만, 적어도 서버가 원하는 통계정보를 받아볼 수 있는 방법을 제공한다.

Meter 헤더

적중 계량 확장은 Meter라는 새로운 헤더를 추가했다. Cache-Control 헤더에 다양한 캐시 지시자를 기술할 수 있듯이, 캐시나 서버는 Meter 헤더에 사용량이나 보고에 관한 지시자가 기술할 수 있다.
image


개인 정보 보호에 대해

실제 로깅은 서버와 프록시에서 수행하는 관리 기능이므로, 모든 것이 사용자의 트랙잰셕에 적용된다.
사용자는 자신의 HTTP 트랜잭션이 로깅되고 있다는 것을 모를수 있다. 사실 많은 사용자가 웹에 있는
컨텐츠에 접근하려고 HTTP 프로토콜을 사용한다는 것조차 모른다.
image

웹 어플리케이션 개발자와 관리자는 사용자의 HTTP 트랜잭션을 추적하고 있다는 것을 유념하고 있어야 한다.
그들이 읽은 정보를 통해 사용자에 관한 많은 정보를 모을 수 있다.

로깅하는 웹서버와 프록시는 최종 사용자의 개인정보를 보호하는데 신경을 많이 써야한다.

로깅은 관리자와 개발자에게 매우 유용한 도구지만 로깅을 당하는 사용자들의 인지나 허가가 없으면 로깅이 사생활 침해가 된다는 것을 유념해야 한다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant