로그파일

loop-back 인터페이스에서 요청을 표시한다

robots.txt 파일에 대한 요청을 표시한다

나머지를 로그에 남긴다

효율적으로 웹서버를 관리하려면 발생하는 문제와 함께 서버의 활동과 성능에 대해 알아야 한다. 아파치 웹서버는 매우 종합적이고 유연한 로그 기능을 제공한다. 이 문서는 로그 기능을 설정하는 방법과 로그에 들어갈 내용을 설명한다.

또, 클라이언트가 제공한 정보는 로그파일에 거의 그대로 기록된다. 그래서 악의가 있는 클라이언트가 로그파일에 제어문자를 넣을 수 있으므로, 로그를 다룰때는 주의해야 한다.

| 관련된 모듈 | 관련된 지시어 | |---|---|

오류 로그는 보통 (전형적으로 유닉스 시스템에서는 error_log

, 윈도우즈와 OS/2에서는 error.log

) 파일에 기록된다. 유닉스 시스템에서 서버는 오류를 syslog

나 파이프를 사용하여 다른 프로그램으로 보낼 수도 있다.

오류 로그의 형식은 상대적으로 자유롭고 자세하다. 그러나 대부분의 오류 로그 항목에 공통적으로 나오는 정보가 있다. 예를 들어, 항목은 보통 다음과 같다.

[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] client denied by server configuration: /export/home/live/ap/htdocs/test

로그 항목에서 첫번째 항목은 날짜와 시간이다. 두번째 항목은 보고하는 오류의 심각성을 나타낸다.

지시어로 오류 로그에 기록되는 오류의 심각성을 제한할 수 있다. 세번째 항목은 오류를 발생한 클라이언트의 IP 주소이다. 이 다음부터 오류문이 나오며, 이 경우 서버가 클라이언트의 접근을 거부하도록 설정되었다고 나와있다. 요청한 문서의 (웹 경로가 아닌) 파일시스템 경로도 보인다.LogLevel

오류 로그에는 매우 다양한 종류의 문구가 나올 수 있다. 대부분은 위와 비슷하다. CGI 스크립트의 디버깅 출력도 오류 로그에 기록된다. CGI 스크립트가 stderr

에 쓴 정보는 그대로 오류 로그로 복사된다.

오류 로그에 정보를 추가하가나 생략할 수 없다. 그러나 요청에 대한 오류 로그의 경우 접근 로그에도 대응하는 항목이 생긴다. 예를 들어, 위의 경우 상태코드가 403인 접근 로그 항목이 생긴다. 접근 로그는 사용자정의할 수 있으므로 이 파일을 참고하여 오류 상황에 대한 추가정보를 얻을 수 있다.

검사할때 어떤 문제가 생기는지 오류 로그를 계속 살펴보는 것이 좋다. 유닉스 시스템에서 다음과 같이 한다:

물론 접근 로그에 정보를 기록하는 것은 로그 관리의 시작일 뿐이다. 다음 단계는 이 정보를 분석하여 유용한 통계를 만드는 것이다. 이 문서는 일반적인 로그 분석에 대해서 다루지 않으며, 로그 분석은 실제 웹서버가 할 일이 아니다. 로그 분석에 대한 정보와 로그를 분석하는 소프트웨어에 대해서는 Open Directory나 Yahoo를 참고하라.

아파치 웹서버는 이전부터 modlogreferer, modlogagent,

지시어가 오래된 지시어들의 모든 기능을 이어받았다.CustomLog

접근 로그의 형식은 매우 사용자정의 가능하다. 형식은 C의 printf(1) 형식문자열과 매우 유사한 형식문자열을 사용하여 지정한다. 다음 절에 예를 들었다. 형식문자열에 사용가능한 모든 내용을 알려면 modlogconfig형식문자열을 참고하라.

LogFormat "%h %l %u %t \"%r\" %>s %b" common

그러면 지정한 로그 형식문자열을 별명 common

으로 정의한다. 형식문자열은 퍼센트 지시어들로 구성되며, 각각은 어떤 정보를 기록할지 알린다. 형식문자열에 일반 문자를 적으면 그대로 로그에 출력된다. 따옴표 문자("

)를 출력하고 싶다면 백슬래쉬를 앞에 붙여서 형식문자열의 끝이 아님을 표시한다. 형식문자열에 줄바꿈 "\n

지시어는 정의한 CustomLog별명을 사용하는 새로운 로그파일을 만든다. 접근 로그의 파일명이 슬래쉬로 시작하지않으면

앞의 설정은 공통로그형식(Common Log Format, CLF)이라는 형식으로 로그 항목을 기록한다. 여러 다른 웹서버들도 이런 표준 형식으로 로그를 만들며, 여러 로그 분석 프로그램에서 읽을 수 있다. CLF로 만든 로그파일 항목은 다음과 같다:

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

이제 로그 항목의 각 부분을 설명한다.

이라면 호스트명을 찾아서 IP 주소 자리에 대신 쓴다. 그러나 이 설정은 서버를 매우 느리게 할 수 있으므로 추천하지 않는다. 호스트명을 알려면 대신 나중에 -

가 제공할 클라이언트의 RFC 1413 신원이다. 이 정보는 매우 믿을 수 없기때문에, 긴밀히 관리되는 내부 네트웍이 아니라면 절대로 이 정보를 사용하면 안된다. IdentityCheck

이 아니라면 아파치 웹서버는 이 정보를 알아보려고 시도하지도 않는다.frank

환경변수로 넘겨진다. 요청의 상태코드가 401이라면 (아래 참고) 사용자가 아직 인증을 거치지 않았으므로 이 값을 믿으면 안된다. 문서를 암호로 보호하지 않는다면 이 항목은 이전 항목과 같이 "-

) [day/month/year:hour:minute:second zone]

은 C 표준 라이브러리의 strftime(3)

이다. 둘째, 클라이언트는 자원 /apache_pb.gif

프로토콜을 사용한다. 요청줄의 여러 부분을 따로 로그할 수도 있다. 예를 들어, 형식문자열 "%m %U%q %H

"과 똑같이 메써드, 경로, 질의문자열, 프로토콜을 로그한다.200

"이다. 내용이 없는 경우 "0

"을 로그하려면 대신 %B

를 사용한다.자주 사용되는 다른 형식문자열은 결합된로그형식(Combined Log Format)이다. 다음과 같이 사용한다.

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined

이 형식은 두 항목을 더 추가한 것을 제외하고는 Common 로그 형식과 완전히 같다. 추가된 항목들은 퍼센트 지시어 %{

를 사용한다. 여기서 header}iheader 자리에 HTTP 요청 헤더 이름이 나올 수 있다. 이 형식의 접근 로그는 다음과 같다:

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)"

를 링크하였거나 포함한 사이트이다.)"Mozilla/4.08 [en] (Win98; I ;Nav)"

지시어를 사용하면 접근 로그가 여러개 만들어진다. 예를 들어, 다음 설정은 세가지 접근 로그를 만든다. 첫번째는 기본 CLF 정보를 기록하고, 두번째와 세번째는 referer와 브라우저 정보를 기록한다. 마지막 두 CustomLog

줄은 어떻게 이전 CustomLogReferLog

지시어의 기능을 흉내낼 수 있는지 보여준다.

으로 반드시 별명을 정의할 필요는 없음을 보여준다. 대신 LogFormat

지시어에 직접 로그 형식을 지정할 수 있다.CustomLog

클라이언트 요청의 성격에 따라 해당 항목을 접근 로그에 기록하지않고 싶을 때가 있다. 환경변수를 사용하면 쉽게 해결된다. 먼저, 클라이언트가 특정 조건을 만족하면 환경변수를 설정한다. 이 작업에는 보통

를 사용한다. 그리고 SetEnvIf

을 사용하여 환경변수 유무에 따라 요청을 집어넣거나 뺀다. 예를 들면:

SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog

다른 예로 영어권 사용자의 요청만을 한 로그파일에 기록하고, 비영어권 사용자의 요청은 다른 로그파일에 기록하는 경우를 생각해보자.

SetEnvIf Accept-Language "en" english

조건부 로그는 매우 강력하고 유연하지만, 이것이 로그 내용을 조절하는 유일한 방법은 아니다. 로그파일은 서버의 모든 행동을 기록할때 더 유용하다. 나중에 원하지않는 요청을 제외하고 로그파일을 분석하는 것이 더 쉽다.

점잖은 재시작을 사용하면 서버는 클라이언트와 기존의 혹은 대기된 연결을 잃지않고 새 로그파일을 열 수 있다. 그러나 이를 위해 서버는 오래된 요청의 서비스를 끝내는 동안 이전 로그파일을 계속 사용해야 한다. 그러므로 재시작한후 로그파일을 처리하기 전에 얼마간 기다릴 필요가 있다. 일반적으로 다음과 같이 로그를 순환하고, 디스크공간을 절약하기위해 이전 로그를 압축한다:

mv accesslog accesslog.old

파이프로 연결된 로그 프로세스는 부모 아파치 httpd 프로세스가 띄우고, 프로세스의 userid도 같다. 즉, 파이프로 연결된 로그 프로그램은 보통 root로 실행된다. 그러므로 프로그램을 간단하고 안전하게 만드는 것이 매우 중요하다.

파이프로 부르는 전체 명령어를 따옴표로 묶음을 명심하라. 이 예는 접근 로그에 대한 것이지만, 오류 로그도 마찬가지다.

서버를 재시작하지않고 로그를 순환할 수 있는 것이 파이프 로그를 사용하는 중요한 이유다. 아파치 웹서버는 이를 위해 rotatelogs라는 간단한 프로그램을 포함한다. 예를 들어 24시간마다 로그를 순환한다면:

CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common

다른 사이트에 cronolog라는 비슷하지만 훨씬 더 유연한 로그 순환 프로그램이 있다.

조건부 로그와 같이 파이프 로그는 매우 강력한 도구지만, 나중에 처리하는 등의 더 간단한 방법이 가능한 경우 사용해서는 안된다.

지시어를 사용하면 해당 가상호스트에 대한 요청과 오류만이 지정된 파일에 기록된다. 로그 지시어가 없는 다른 가상호스트는 계속 주서버 로그에 로그를 기록한다. 이 방법은 가상호스트 개수가 적을 경우 매우 유용하지만, 호스트 수가 많다면 관리하기 힘들어진다. 또, ErrorLog파일기술자가 부족한 문제가 자주 발생한다.

접근 로그의 경우 매우 좋은 해결책이 있다. 로그 형식문자열에 가상호스트에 대한 정보를 추가하면 모든 호스트가 같은 로그를 사용하고, 나중에 로그를 가상호스트별로 나눌 수 있다. 예를 들어, 다음 지시어를 봐라.

는 요청을 서비스하는 가상호스트 이름을 기록한다. 나중에 split-logfile 같은 프로그램으로 접근 로그를 가상호스별로 나눌 수 있다.

지시어를 사용하여 CGI 스크립트의 입력과 출력을 기록할 수 있다. 이 지시어는 오직 테스트용으로만 사용해야 한다. 실제 사용하는 서버에서 사용하면 안된다. 더 자세한 정보는 ScriptLogmod_cgi 문서를 참고하라.

mod_rewrite의 강력하고 복잡한 기능을 사용한다면 디버깅을 위해 거의 항상

를 사용할 필요가 있다. 이 로그파일은 재작성 엔진이 어떻게 요청을 변환하는지에 대해 자세히 알려준다. 자세한 정도는 RewriteLog

모듈 | 지시어들 | FAQ | 용어 | 사이트맵

Apache HTTP Server Version 2.4