수안이의 컴퓨터 연구실

출처 : 시스템 로그 분석 (해킹 피해와 보안 추적의 결정적 파일) - 안정철 지음
(안정철 님에게 책 내용에 대해 발췌하는 것에 대해서 허락을 구하지 못하였습니다. 삭제를 요구하시면 바로 삭제 조취 하겠습니다.)

Session 03. 에러 로그 분석 방법

웹 서버가 어떻게 사용되고, 혹 잘못된 부분이 없는지를 분석할 때에 유용하게 사용될 수 있는 것 중의 하나가 에러 로그 파일이다. "에러 로그"는 웹 서버가 운영 중에 발생되는 잚소된 모든 기록을 포함하고 있다. 웹 서버의 시작이나 중지와 같은 통보정도에 지나치지 않는 일반 메세지까지 말이다. 에러 로그 파일은 'ErrorLog' 지시어를 이용하여 어느 곳에 기록할 지를 지정하며, 기본으로 설정되는 로그 파일의 경로는 "/usr/local/apache/logs/error_log"가 된다. 에러 로그의 기록을 원하지 않는 경우에는 다음과 같이 "null" 디바이스로 전송하면 된다.



이러한 방법은 웹 서버가 디스크에 엑세스하는 시간을 줄여, 실제로 아파치가 로그를 기록하는데 소비하는 시간을 감소시켜 준다. 이외에 유닉스 시스템 로그 데몬에 에러 메세지를 전송 하는 것도 가능하다. 이것은 한 호스트에 하나의 에러 로그만이 가능하며, 만약 여러 개의 ErrorLog를 지정하게 되면 마지막에 지정된 것이 사용될 것이다. 아파치의 에러 로그는 유닉스 시스템에서 사용하는 것과 같이 제일 하단의 'debug'에서부터 'emergency'까지의 전체 8개의 범위를 가지고 있다.

일반적으로 로그의 모든 메세지들을 에러 로그 파일에 기록하는 것은 디스크의 소모뿐만 아니라 로그를 기록하기 위한 프로세스 시간을 필요로 하게 된다. 이러한 부분들을 고려하여 아파치 웹 서버는 'LogLevel' 지시어를 이용한 각 로그 레벨 단위의 기록이 가능하도록 하고 있다. 예를 들어, 'notice' 또는 그 이상의 범위에 해당하는 내용만 기록에 남기고자 한다면 아래와 같이 입력할 수 있다.


이와 달리, 'debug' 레벨을 선택하게 되면 아파치에서 발생하는 모든 에러 메세지를 로그에 기록하게 되므로 자원의 공간과 프로세스 시간을 낭비하는 결과를 초래하게 된다. 물론 이와 같이 모든 내용을 기록한다는 것이 여러분들에게 어떠한 생각을 줄여 줄지는 모르지만, 'debug'와 같이 모든 내용을 기록한다는 것이 에러 로그에 있어서는 그리 비효율적이라 생각은 들지 않는다. 로그의 범위는 여러분들의 고민으로 남겨 두도록 하겠다.

다음 표는 각 단계별 로그 레벨의 의미를 나타낸 것이다.

로그 레벨	에러의 이미
emerg	불안정한 시스템 상황
alert	즉각적인 조치 필요
crit	중대한 에러
error	비교적 중대하지 않은 에러
warn	경고
notice	중대한 것은 아닌 일반적인 메세지
info	정보
debug	디버그 레벨

아파치의 에러를 시스템 로그 데몬인 'syslogd'를 전송하기 위해서는 다음과 같이 기존의 에러 로그 파일의 이름을 'syslog'로 변경하여야 한다.



기본적으로 에러 로그는 syslog에 'local7'의 이름으로 기록이 되며, syslog.conf에서 syslogd 데몬은 어떠한 에러 메세지들을 받을 것이지 제어하게 된다. syslog.conf에 다음의 라인을 포함하게 되면 /var/log/httpd.log에 내용을 저장하게 된다.



이외에 local7.* 과는 달리 앞쪽에서 언급하였던 로그 레벨을 기반으로 로그를 따로 저장 할 수가 있다. 아래의 예은 warn 로그 레벨 이상의 정보를 /var/log/httpd_warn.log 에 저장하는 것과 info 레벨 또는 그 이상의 메세지를 error 레벨 이하로 기준하여 /var/log/httpd_info.log 에 저장하게 된다. 쉽게 이야기하면 httpd_info.log는 info,notice,warn 레벨을 포함하는 것이다.


웹 서버의 문제 해결은 에러 로그와 함께 아파치를 처음 접하는 초보자가 설치 후 애기치 못한 문제에 봉착하였을 경우에는 당황하지 말고 에러 로그를 찾아봄으로써 문제의 대부분을 해결할 수 있다.

웹 서버에 문제가 있을 때에는 발생되는 문제를 즉시 확인하기 위하여 계속적으로 로그 파일을 확인해 보아야 하는 경우도 있기 마련이다. 이럴 때에는 유닉스에서 제공해 주는 'tail' 명령어를 이용하여 다음과 같이 사용하면 된다.



또 다른 방법으로는 펄을 이용할 수가 있다. File::Tail 모듈을 사용하면 되고 이것을 통하여 여러분들이 다양하게 응용하여 사용해 볼 수 있으며, http://www.cpan.org/modules/by-module/File/File-Tail-0.98.tar.gz에서 구할 수 있다.



"tail -f" 를 이용한 로그 파일을 살펴보면 이래와 같은 내용을 확인할 수 있다.



지금까지 아파치 서버의 대표적인 Access_log와 error_log의 분석 방법에 대하여 알아보았다. 아파치 서버는 오늘날 운영중인 웹 서버중 운영 빈도가 높은 서버중 하나이다.

아파치 서버에 저장된 로그 파일로부터 유용한 정보를 얻어내기 위해서는

- 사용자 스스로 로그 파일에서 필요한 정보만을 추출하는 방법
- 자동화된 로그 분석 프로그램을 이용하는 방법

위 2가지 방법으로 나눌 수 있다. 대부분의 경우에는 수작업에 기록된 내용을 분석하고 통계를 알아내는 방법보다는 분석 프로그램을 이용하여 다양한 정리된 자료를 원할 것이다. 그러나 경영자 입장에서 웹 로그로부터 얻을 수 있는 가장 중요한 정보중 하나는 히트(hit)와 페이지뷰(pageview)이다. 히트는 웹 서버에서 받은 모든 요청과도 같다. 페이지 상에 포함된 이미지, 사운드 파일, 그리고 기타 모든 것들이 하나의 히트로 간주되며, 이와 달리 페이지뷰는 좀 더 정확하게 전체의 각 부분이 아니라 페이지 전체를 하나로 본 것이라 이해하면 된다.

이 히트와 페이지뷰를 통하여 누가 사이트를 방문하였고, 방문한 사용자들은 어디로부터 왔으며, 어떠한 페이지를 보았고, 또 얼마나 오랫동안 머물렀는지, 그리고 사용한 브라우저는 무엇인지 등 다양한 정보를 방문객으로부터 얻어낼 수가 있다.

이러한 정보를 다양하게 분석하려면 분석 툴 보다는 수작업에 의한 것이 더 다양한 정보를 획득할 수 있다는 점을 잊지 말기 바란다. 그러나 로그 분석 툴이 사람의 수작업을 통한 것보다 좀 더 정확하고 신속한 장점도 있음을 알아두자.

아무리 웹 서버의 로그를 잘 분석하고 적절히 조치할 수 있다하더라도 서버 관리자에 의한 환경 설정에 따라 외부로부터의 공격 가능성과 웹 서버 자체 또는 사용하는 어플리케이션 프로그램의 버그로 인한 공격에는 늘 노출되어 있음을 인식하자. 특히 요즘 사회이슈로 자주 등장하는 인터넷 웜의 경우 각 서버에 공통적인 취약점을 찾아서 공격하므로 웹 서버의 경우는 로그 분석만이 아니라 보안 패치가 수시로 이루어져야 한다.

아파치의 경우 공개 소프트웨어이면서 많이 운영되다 보니 시스템 자체의 취약점이 자주 발견되고 즉시 패치자료가 공개되고 있다. 따라서 아래의 사이트에서 수시로 패치자료를 다운받아 설치해두는 점이 좀더 안정적인 시스템 운영에 도움이 되리라 생각한다.

출처 : 시스템 로그 분석 (해킹 피해와 보안 추적의 결정적 파일) - 안정철 지음
(안정철 님에게 책 내용에 대해 발췌하는 것에 대해서 허락을 구하지 못하였습니다. 삭제를 요구하시면 바로 삭제 조취 하겠습니다.)

Session 02. 접속 로그 분석 방법

아파치 웹 서버에서 기본적으로 각 클라이언트의 요청을 기록하는 'access_log'는 이름에서도 느낄 수 있는 것처럼 웹 서버에 접근되는 모든 것을 기록하게 된다. 접속 로그는 방문자 정보를 얻는데 있어서 가장 중요한 역할을 담당하고 있다. 우선, 여러분들이 정보를 가져올 'access_log'는 다음과 같이 TransferLog 지시어를 사용하여 어느 위치에 로그를 남길 것인지 결정을 할 수가 있다.
그 러나 1.3.X 버전부터 사용자 정의 로그 포맷을 지원하고 있다. 대부분의 웹 서버들은 CLF(Common Log Format)로 파일을 생성하고 있으며, 이외에도 ELF(Extended Log Format), 그리고 Combined Log Format이 있다. 몇몇 서버들은 이외의 다른 형식 포멧을 사용학 있지만 CLF와 비슷한 형식을 취하고 있으며, 아파치 웹 서버는 기본적으로 이 포맷 방식을 따르고 있다. 지금 시점에서 여러분들이 사용하는 아파치 웹 서버의 로그 파일 설정은 다음과 같이 이루어져 있을 것이다.


CLF는 각 클라이언트 요청에 한 라인으로 구성되어져 있고, 공백에 의해 각 필드는 7가지의 정보를 포함하여 구분되어 있다. 기본 포맷은 다음과 같은 형식을 갖추고 있다.


첫 번째 필드는 원격지 호스트 주소 정보를 가지고 있다. 이것은 어느 누가 여러분들의 웹 사이트를 방문하였는가를 말해주는 것이다. 기본적으로, 이곳은 원격지 호스트의 정보가 IP 주소로 기입이 된다. 물론 아파치 웹 서버에서 호스트 이름을 찾아 기록할 수 있도록 설정할 수는 있으나, 아파치 1.3.X 버전에서는 성능상의 문제로 호스트 이름 대신 IP 주소로 기록하고 있다.


아 파치 웹 서버는 IP 주소 대신 'HostNameLookups' 지시어를 사용하여 호스트 이름으로 기록을 할 수가 있다. 그러나 이러한 방법의 사용은 결과적으로 서버의 전반적인 성능을 떨어뜨릴 수 있는 요인 중의 하나가 될 수 있으므로 권장하지 않는다.

HostNameLookups on과 같이 사용하면 되며, on 이외에 double을 사용하여 역 방향 이름을 찾아 조회하는데도 사용할 수 있다.

logresolve 프로그램을 이용하여 IP 주소를 도메인으로 변경하는 방법은 아래와 같다.


두 번째 필드는 대부분의 경우 아무런 정보를 가지고 있지 않다는 '-'로 표시될 것이다. 이것은 방문자를 식별하는 정보를 얻는 경우에 이용되며, 실질적인 인증을 통한 로그인 이름이 아니라 사용자의 이메일 주소 및 식별할 수 있는 정보 등을 의미한다. 이 정보는 'identd'에 또는 브라우저의 직접적인 정보 제공에 의해 기록되어 질 수 있으나, 이러한 기능은 이미 오래 전에 사라져 사용되지 않고 있는 정보로 생각하면 된다.

세 번째 필드 또한 '-'로 표시되는 경우가 많으며, 방문자가 사용자 인증을 통하여 접속한 경우에 사용자의 로그인 이름이 기록된다. 네 번째 필드는 클라이언트가 서버의 자원을 요청한 시각이며, 다섯 번째 필드 "request"에는 요청한 자원이 어떤 것인지를 나타낸다. 주로 웹 서버의 자원을 클라이언트로 가져가기 위해 GET을 사용하며, 그 다음에는 실제적인 문서, 즉 URL을 의미한다. 클라이언트는 '/'를 시작으로 DocumentRoot 디렉토리로 지정한 경로에 기반하여 사용자에게 문서를 보여주게 된다.

URL의 마지막에는 HTTP 프로토콜 버전이 따라오게 되는데, 이 번호는 1.0 또는 1.1이 될 것이다. HTTP/1.0은 초창기의 프로토콜 버전으로 최근의 브라우저는 HTTP/1.1을 지원하고 1.0에 비해 많은 성능개선을 한 HTTP/1.1이 주로 사용되고 있다.

여 섯 번째의 필드는 웹 서버의 상태 코드를 의미하는 것으로서 클라이언트의 요청이 성공적이었는지, 또는 문제 발생이 있었는지를 코드번호로 나타내고 있다. 대부분의 경우에는 성공적인 전송을 의미하는 200번일 것이며, 서버에서 문제가 발생할 시에는 5XX번대로 시작한 에러코드가 기록될 것이다.

마지막인 일곱 번째 필드는 클라이언트에게 전송된 바이트를 나타낸다. 이것은 하루에 얼마나 데이터가 전송되었는가를 알아내고자 할 때 사용될 수 있다.

다음의 예를 살펴보자.


192.168.0.151 의 IP 주소에서 요청한 것을 보면 2005년 3월 1일 11시 43분 50초에 Test 센터를 요청하였으며 HTTP/1.1 프로토콜을 사용하였다. 상태 코드는 200을 나타내는 것으로 보아 클라이언트에게 성공적으로 전송되었음을 알 수가 있고 총 11,177bytes가 전송되어졌다. 각 필드에 해당하는 의미를 간단하게 기술해 놓은 CLF(Common Log Format)을 구성하는 각 필드는 다음과 같다.

아이템	의미
Host	클라이언트의 호스트 이름이나 IP Address
Ident	IdentityCheck가 enable 되어 있고, 클라이언트가 ident에 응답을 보내면 identity 정보를 남기게 되며, 보통은 "- "로 대체된다.
Authuser	인증이 있을 경우 여기에 사용자 이름이 기록되게 되며, 그렇지 않을 경우 "- "로 대체된다.
Date	접속한 시간과 날짜를 나타내며, 포맷은 다음과 같다 : 날짜 포맷 = [day/month/year:hour:minute:second zone] day = 2*digit month = 3*letter year = 4*digit hour = 2*digit minute = 2*digit second = 2*digit zone = (+' | -') 4*digit
Request	클라이언트가 요청한 자료
Status	요청한 것에 대한 서버의 처리 사항으로 상태 코드라 한다.
Bytes	헤더를 제외한 전송된 Byte 양

지금까지 기본 로그 포맷에 대하여 알아보았다. 이번에는 'CustomLog' 지시어를 이용한 사용자 정의 로그 포맷에 대해 살펴보고자 한다.

'CustomerLog' 지시어는 'TransferLog'의 기능을 내포하고 마찬가지로 로그 파일이 어느 위치에 저장되어야 할지를 가리키며 추가적으로 저장되는 로그의 포맷을 사용자에 의해 지정을 할 수가 있다. 이전에는 CLF(Common Log Format)이라 불리는 고정된 형식으로만 사용이 가능하였다. 그러나 지금은 CLF 포맷을 여러분들이 원하는 형태 즉, 필요한 정보로 맞춤 정장과도 같이 여러분들의 입맛대로 만들 수가 있는 것이다.

원하는 형태의 로그 파일을 만들기 위해서는 포맷을 지정하여야 하고, 이 역할을 'LogFormat' 지시어가 한다. 다음의 내용을 httpd.conf에서 찾아볼 수가 있을 것이다.


이 뜻은 인용 부호 "'' 안의 로그 포맷을 "common"의 이름으로 만드는 것이다. 각 문자들이 나타내는 것은 특정 정보를 의미하며, 기술한 순서에 따라 로그 파일에 기록된다. 로그 포맷으로 사용 가능한 변수와 이에 대한 의미는 다음 표와 같다.

포맷	의미
%a	원격지 IP 주소
%A	로컬 IP 주소
%B	HTTP 헤더를 제외하고 전송된 바이트
%b	HTTP 헤더를 제외하고 전송된 바이트. CLF 포맷에서는 전송된 것이 없을 경우 0으로 표시하기 보다는'-'로 표시한다.
%{FOOBAR}e	서버에 의해 지정된 환경변수
%f	파일 이름
%h	원격지 호스트
%H	요청한 프로토콜
%{Foobar}i	Foobar의 내용 : 클라이언트에서 서버로 요청된 헤더라인으로 예를 들자면, Referer 헤더일 경우 %{Referer}i로 사용되어 진다.
%l	원격지 사용자 이름(이것이 사용되어 지기 위해서는 IdentityCheck가 반드시 enable 되어져 있어야 한다.)
%m	요청 방식
%{Foobar}o	서버에서 응답되는 HTTP 헤더. 예를 들면 : %{Content-Type}o, %{Last-Modified}o
%p	요청을 처리하는 서버의 참조적인 포트
%P	현 요청을 처리하고 있는 아파치 자식 프로세서의 프로세스 ID
%q	쿼리 문자열(쿼리가 있을 경우 "?" 뒤로 쿼리문이 포함되며 그렇지 않을 경우 공백으로 처리된다.)
%r	HTTP 메소드를 포함한 요청의 첫 라인
%s	HTTP 상태 코드. 만약 클라이언트의 요청이 내부적인 리다이렉트를 발생시켰을 경우 %s는 초기 요청을 상태 코드를 %>s는 최종 상태 코드를 포함하게 된다. 일반저긍로 %s의 사용 보다는 %>s가 유용하다.
%t	요청한 시간과 날짜(standard english format)
%{format}t	strftime() function을 이용한 포맷 형식에 따른 시간 [Day/Month/Year:Hours:Minutes:Seconds Time Zone]
%T	요청을 처리하는데 걸린 시간(초)
%u	인증이 요청된 원격 사용자 이름
%U	요청된 URL
%v	요청을 처리하는 서버의 참조적인 서버 이름
%V	UseCannoicalName 설정에 따른 서버 이름

여기서 많이 쓰이지 않는 'ident'와 'authuser' 필드는 제거하여 로그 파일에 기록되지 않게 할 수도 있으며, 다음과 같이 에이전트와 참조 로그를 한 로그 파일에 만드는 것도 가능하다.


이와 같이 로그 포맷에 대해서 알아보았는데, 이외에 다른 방법들은 없을까? 'CustomLog'와 'LogFormat'을 이용한 효율적이고도 다양한 방법들로는 무엇이 있는지 함께 알아보도록 하자.

때 로는 HTTP의 각 상태코드 별로 로그를 취합하여 효율적인 분석이 필요한 경우도 있다. 이럴 경우에는 %와 변수 사이에 HTTP 상태 코드를 집어넣어 해당하는 이벤트가 발생하는 경우에 로그를 남길 수 있다. 예를 들어, 잘못된 링크만을 따로 저장하고 할 때에는

LogFormat %404{Referer}i BrokenLinks
CustomLog /usr/local/apache/logs/broken_links BrokenLinks

와 같이 사용하면 된다. 최근에는 멀티미디어 서비스 및 이미지의 사용이 많아지고 있는 추세로 로그 파일에 많은 양의 데이터가 쌓이고 있다. 이에 대한 해결책으로는 아파치의 'mod_setenvif' 모듈을 이용하는 것으로서 방안을 제시해 주고 있다.



(a) - (c) 까지는 gif 이미지를 gif-requests.log에, 그 이외의 것은 nongif-requests.log에 저장 하는 것이며, 나머지 (d) - (g)는 CLF 포맷으로 이미지 파일인 gif를 제외한 로그를 access_log에 남기라는 의미이다.



www.Test.net 을 통해서 들어오게 되면 apache_site_referral 변수를 설정하여 로그를 남길 수도 있다. 한 가지 주의할 점은 SetEnvIf[NoCase]에 의한 환경 변수의 지정은 CustomLog와 같이 변수를 이용한 저장일 경우에는 CustomLog 지시어 전에 설정되어 있어야 한다.

지금까지 여러 다양한 방법의 사용을 알아보았다. 마지막으로 가상 호스트를 많이 운영하는 분들을 위하여 여러 개의 로그 파일을 하나의 파일로 만드는 방법을 보자.


이 것은 기본 로그 포맷 앞에 "canonical name"과 IP 주소, 포트 번호를 나타내는 추가적인 정보가 더 기술되어 있다. 이러한 방식을 통한 운영은 OS 특성상 동시에 파일을 열 수 있는 개수의 제한 등으로 인하여 모든 가상 호스트마다 개별적인 로그 파일을 만들어 줄 수 없을 때 사용할 수가 있다.

출처 : 시스템 로그 분석 (해킹 피해와 보안 추적의 결정적 파일) - 안정철 지음
(안정철 님에게 책 내용에 대해 발췌하는 것에 대해서 허락을 구하지 못하였습니다. 삭제를 요구하시면 바로 삭제 조취 하겠습니다.)

Session 01. 웹 로그 분석의 개요

인터넷의 대중화로 한 기업의 이미지를 대표함과 동시에 기업의 생존전략 도구로서 필수불가결한 것 중의 하나가 바로 사용자에게 실질적인 서비스를 제공해 주고 있는 웹 서버이다. 더욱이 시간이 흐르면서 지금의 상황에 반문이라도 하듯이 늘어나고 있는 방대한 양의 컨텐츠와 멀티미디어 서비스 등으로 인하여 인터넷에서의 웹 서버 역할은 날로 중요해지고 있다.

웹 서버를 운영하는 목적 중의 하나는 클라이언트에게 다양한 정보를 제공하는 역할을 수행하는 것이다. 그렇다면 관리자는 이러한 환경의 제공만으로 본연의 역할을 다한 것일까? 어떠한 목적으로의 운영을 결정하였는가에 따라, 이 질문에 대한 대답은 달라질것이며 필자의 입장에서는 클라이언트에게 더 나은 정보 및 환경을 제공하기 위한 방법의 하나로 웹 서버의 단순한 운영만으로는 시스템 운영자 또는 웹 마스터의 역할을 다한것이라고 생각하지 않는다.

한 예로 모 기업의 마케팅 부서 담당자 입장에서 생각해보면, 마케팅 담당자는 그 기업의 생산 계획에서 판매 계획에 이르기까지 전 과정을 체크해야 한다. 여기에 웹 사이트를 이용한 제품 및 여러 가지 홍보 등은 결코 빠질 수 없는 중요한 광고매체로 인식되고 있으며, 대부분의 담당자들은 웹사이트에 기록된 일종의 가공되지 않은 데이터를 원하지는 않을 것이다.

웹사이트를 방문한 사용자들의 정보가 필요로 하는 것에 따라 한눈에 파악하기 쉽도록 만들어지고, 많은 유용한 정보들을 포함하도록 한다면 곧 이러한 정보와 전통적인 데이터들의 통합된 정보는 마케팅적인 면에서 큰 장점을 가지고 있다는 것은 굳이 언급하지 않아도 알 수 있다. 효과적인 광고, 웹사이트에서의 방문자 행동, 구매비율과 같이 총체적으로 이미 분석된 정보를 활용할 수가 있다. 이러한 모든 것들이 현재의 마케팅의 이해와 함께 웹사이트의 분석에 마케팅적으로 이용될 수 있는 부분으로 시장에서 새로운 비즈니스로서 성장하고 있다.

웹 서버의 로그 파일은 초기에 문제의 진단 및 처리량 등의 파악에 이용될 목적으로 디자인되었으나, 지금과 같이 웹사이트의 성능 개선 및 다양한 곳에 이용되리라고는 예상하지 못했다. 현 상에서의 이와 같은 모든 로그 정보들이 웹사이트 운영에 중요한 정보로서 자리매김하였으며, 이는 단순히 접속되는 데이터로 모든 방문객과 모든 페이지에 대해 기록할 수 있게 하여 웹사이트 내에 누군지는 모르지만 수많은 방문객에 관계없이 웹 서버는 바쁘게 움직이고 있다. 이제 필자가 여러분들과 함께 웹 로그의 중요성을 설명한 만큼 아파치 웹 서버에서 제공하는 로그의 이해에 기본을 두고 방문자 정보 분석에 첫 발걸음을 내딛어보자!

01. 어떠한 정보를 이용할 수 있을까?
시작하기에 앞서 여러분들은 웹 서버에서 제공하는 정보로는 어떠한 것이 가능한지 알아야 한다. 아파치 웹 서버는 클라이언트가 요청하는 모든 정보를 로그 파일에 기록하게 되고, 기록된 여러 다양한 정보는 다음을 포함하여 분석을 하게 된다.

1. 원격접근 호스트의 주소
이것은 "누가 나의 웹사이트를 방문했는가" 와도 비슷하다고 할 수 있다. 좀 더 자세히 말하자면, 방문자가 어디에서 접속했는지를 말해준다.

2. 방문횟수 및 시간
방문자가 얼마나 자주 웹사이트를 방문했는가를 알려준다. 주로 오전 9시부터 오후 6시까지의 업무시간 사이에 많은 방문이 이루어진다고 생각할 수 있고, 그렇지 않은 이외의 시간은 집에서의 접속으로 추정할 수가 있다.

3. 요청한 웹 서버의 자원
사이트에서 가장 인기 있는 페이지는 어디일까? 클라이언트가 요청한 자원의 정보를 기록하여 운영자는 어느 부분이 가장 인기 있는 부분이며, 또 그렇지 않은 부분을 판별할 수가 있다.

4. 방문자의 운영체제(Operating System), 브라우저 그리고 브라우저 버전
여러분들의 사이트를 방문하는 사용자가 Mac 또는 PC를 이용한 접속이 몇 %나 될까? 또는 넷스케이프, 인터넷 익스플로러를 이용한 퍼센트는 기본 정보 이외의 'User Agent'정보를 이용하여 방문자의 부가적인 정보를 얻을 수 있다. 위와 같은 정보들은 정확하지 않을 수도 있으나, 완벽히 신뢰하지 못할 만큼은 아니다. 이 뜻은 웹 서버의 로그 자료에만 너무 의존하지 말아야 한다는 점이다. 어떤 페이지에 어느 정도의 사용자가 방문했는지 정확히 알ㄹ줄 수 있을까? 물론 수치상으로 기록된 정보로는 그렇지만, 프록시 캐쉬 등을 이용한 경우에는 웹 서버에 직접적으로 접근하지 않으므로 로그에 기록되지 않을 수가 있다.

비록 이러한 데이터들이 정확하지 않더라도 여러분들의 사이트를 얼마나 방문하는지 등의 대략적인 정보로 사용할 수가 있기 때문에 웹 서버의 로그 파일이 중요한 역할을 한다는 것은 의심할 여지가 없다.

02. 로그 파일은 어떻게 작동되나?
매 시간 웹사이트의 모든 정보는 웹 서버에 의해 파일로 기록된다. 아파치 웹 서버는 이 정보를 접속 로그, 에러 로그 등으로 불리는 다양한 형태로 저장한다. 로그 파일에는 어느 시간에 어떤 페이지를 요청했는지의 기록뿐만 아니라, 클라이언트가 요청한 것에 대한 추가적인 여러 유용한 정보들이 존재한다. 아파치를 설치하면 기본적으로 두개의 파일이 쓰이며, 이중의 하나는 access_log이고, 다른 하나는 error_log이다.

이 파일들은 아파치의 기본 설치에 따라 '/usr/local/apache/logs'에 위치하게 되며, 설정 파일을 통해 로그 파일의 위치는 변경이 가능하다. 이전의 버전에서는 로그 파일이 내용에 따라 다음과 같이 두 가지로 나누어져 있었으나, 현재의 1.3.x에서는 차후 설명할 mod_log_config에 따라 통합적인 방법의 사용이 가능하였다.

• 접속로그
• 에러 로그

접속 로그는 웹 서버로부터 전송되는 정보가 기록되는 것으로 여러 페이지 중의 하나를 방문한 사용자가 어떤 링크를 통하여 혹은 배너를 통하여 접속하게 되었는지의 정보 등을 알 수 있다. 이러한 정보는 여러분들이 방문자의 관심 사항을 간접적으로나마 파악할 수 있게 한다.

아울러 온라인 광고를 하는 경우 이 정보를 이용하여 어느 사이트에 배너 광고를 해야 효율적인가를 결정할 수 있고 더불어 기업의 입장에서는 어떠한 사이트와 좋은 관계를 유지해야 하는가의 판별력에도 도움을 줄 것이다. 클라이언트가 사용한 브라우저에 대한 정보를 에이전트 로그에 기록되며, 웹 서버 운영상에 나타나는 에러 또는 CGI 스크립트 실행 시 발생되는 문제점은 에러 로그 파일에 쓰여진다.