로그파일

가능한 언어: en | + fr | + ja | + ko | + tr

이 문서는 최신판 번역이 아닙니다. + 최근에 변경된 내용은 영어 문서를 참고하세요.

+ +

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

보안 경고
오류 로그 (Error Log)
접근 로그 (Access Log)
로그 순환 (Log Rotation)
로그를 파이프로 보내기
가상호스트
다른 로그파일

참고

Comments

보안 경고

+ + +

누군가에게 아파치의 로그파일이 있는 디렉토리에 쓰기권한이 + 있다면 (보통 root) 서버를 실행하는 uid를 거의 확실히 얻을 + 수 있다. 이를 고려하지않고 로그가 저장된 디렉토리에 쓰기권한을 + 주지 마라. 자세한 내용은 보안 팁 문서를 참고하라.

+ +

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

오류 로그 (Error Log)

관련된 모듈	관련된 지시어
	`ErrorLog` `LogLevel`

+ + + + +

ErrorLog 지시어는 + 가장 중요한 로그파일인 서버 오류 로그의 이름과 위치를 지정한다. + 아파치 웹서버는 이 파일에 진단정보와 요청을 처리하는 도중 + 발생한 오류를 기록한다. 서버가 시작하거나 동작하는데 문제가 + 있다면 무엇이 잘못되었고 때때로 어떻게 고치는지를 알려주는 + 이곳을 가장 먼저 살펴봐야 한다.

+ +

오류 로그는 보통 (전형적으로 유닉스 시스템에서는 + 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 +

+ +

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

+ +

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

+ +

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

+ +

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

+ +

+ tail -f error_log +

접근 로그 (Access Log)

관련된 모듈	관련된 지시어
`mod_log_config` `mod_setenvif`	`CustomLog` `LogFormat` `SetEnvIf`

+ + + + +

서버 접근 로그는 서버가 처리하는 모든 요청을 기록한다. + CustomLog + 지시어는 접근 로그의 위치와 내용을 지정한다. LogFormat 지시어를 + 사용하여 로그에 포함할 내용을 쉽게 선택할 수 있다. 이 절은 + 서버가 접근 로그에 쓸 내용을 설정하는 방법을 설명한다.

+ +

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

+ +

아파치 웹서버는 이전부터 mod_log_referer, mod_log_agent, + CustomLog + 같은 모듈과 지시어를 사용하여 접근 로그를 다루었다. 지금은 + CustomLog + 지시어가 오래된 지시어들의 모든 기능을 이어받았다.

+ +

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

+ +

Common 로그 형식

+ + +

접근 로그의 전형적인 설정은 다음과 같다.

+ +

+ LogFormat "%h %l %u %t \"%r\" %>s %b" common + CustomLog logs/access_log common +

+ +

그러면 지정한 로그 형식문자열을 별명 + common으로 정의한다. 형식문자열은 퍼센트 + 지시어들로 구성되며, 각각은 어떤 정보를 기록할지 알린다. + 형식문자열에 일반 문자를 적으면 그대로 로그에 출력된다. + 따옴표 문자(")를 출력하고 싶다면 백슬래쉬를 + 앞에 붙여서 형식문자열의 끝이 아님을 표시한다. 형식문자열에 + 줄바꿈 "\n", 탭 "\t"와 같은 + 특수 조절문자를 사용할 수 있다.

+ +

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

+ +

앞의 설정은 공통로그형식(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 +

+ +

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

+ +

127.0.0.1 (%h): 서버에 요청을 한 클라이언트(원격 호스트)의 IP + 주소이다. HostnameLookups가 + On이라면 호스트명을 찾아서 IP 주소 자리에 + 대신 쓴다. 그러나 이 설정은 서버를 매우 느리게 할 수 + 있으므로 추천하지 않는다. 호스트명을 알려면 대신 나중에 + logresolve와 + 같은 로그를 처리하는 프로그램을 사용하는 것이 좋다. + 여기에 나온 IP 주소는 사용자가 사용하는 컴퓨터 주소가 + 아닐 수 있다. 프록시 서버가 사용자와 서버사이에 존재한다면, + 원래 컴퓨터 주소가 아니라 프록시의 주소가 기록될 것이다.
- (%l): 출력에서 "빼기기호"는 요청한 정보가 없음을 나타낸다. + 이 경우 여기에 나올 정보는 클라이언트 컴퓨터의 + identd가 제공할 클라이언트의 RFC 1413 + 신원이다. 이 정보는 매우 믿을 수 없기때문에, 긴밀히 + 관리되는 내부 네트웍이 아니라면 절대로 이 정보를 사용하면 + 안된다. IdentityCheck가 + On이 아니라면 아파치 웹서버는 이 정보를 + 알아보려고 시도하지도 않는다.
frank (%u): 이는 HTTP 인증으로 알아낸 문서를 요청한 사용자의 + userid이다. 보통 이 값은 CGI 스크립트에게 + REMOTE_USER 환경변수로 넘겨진다. 요청의 + 상태코드가 401이라면 (아래 참고) 사용자가 아직 인증을 + 거치지 않았으므로 이 값을 믿으면 안된다. 문서를 암호로 + 보호하지 않는다면 이 항목은 이전 항목과 같이 + "-"이다.
[10/Oct/2000:13:55:36 -0700] + (%t): + 서버가 요청처리를 마친 시간. + 형식은: + +
+ [day/month/year:hour:minute:second zone] + day = 숫자 2개 + month = 숫자 3개 + year = 숫자 4개 + hour = 숫자 2개 + minute = 숫자 2개 + second = 숫자 2개 + zone = (`+' | `-') 숫자 4개 +
+ 로그 형식문자열에 %{format}t를 사용하여 + 다른 형식으로 시간을 출력할 수 있다. format은 + C 표준 라이브러리의 strftime(3)과 같다. +
"GET /apache_pb.gif HTTP/1.0" + (\"%r\"): 클라이언트의 요청줄이 쌍따옴표로 묶여있다. 요청줄은 + 매우 유용한 정보를 담고 있다. 첫째, 클라이언트가 사용한 + 메써드는 GET이다. 둘째, 클라이언트는 자원 + /apache_pb.gif를 요청한다. 세번째, 클라이언트는 + HTTP/1.0 프로토콜을 사용한다. 요청줄의 + 여러 부분을 따로 로그할 수도 있다. 예를 들어, 형식문자열 + "%m %U%q %H"은 "%r"과 똑같이 + 메써드, 경로, 질의문자열, 프로토콜을 로그한다.
200 (%>s): 이는 서버가 클라이언트에게 보내는 상태코드이다. 이 + 정보는 (2로 시작하는 코드) 요청이 성공하였는지, (4로 + 시작하는 코드) 클라이언트에 오류가 있는지, (5로 시작하는 + 코드) 서버에 오류가 있는지 알려주므로 매우 중요하다. + 상태코드의 전체 목록은 HTTP + 규약 (RFC2616 section 10)에서 찾을 수 있다.
2326 (%b): 마지막 항목은 응답 헤더를 제외하고 클라이언트에게 + 보내는 내용의 크기를 나타낸다. 클라이언트에게 보내는 + 내용이 없다면 이 값은 "-"이다. 내용이 + 없는 경우 "0"을 로그하려면 대신 + %B를 사용한다.

+ + +

Combined 로그 형식

+ + +

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

+ +

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

+ +

이 형식은 두 항목을 더 추가한 것을 제외하고는 Common + 로그 형식과 완전히 같다. 추가된 항목들은 퍼센트 지시어 + %{header}i를 사용한다. 여기서 + header 자리에 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)" +

+ +

추가된 항목은:

+ +

"http://www.example.com/start.html" + (\"%{Referer}i\"): "Referer" (맞춤법 틀리지않았음) HTTP 요청 헤더. + 클라이언트가 참조했다고 서버에게 알린 사이트이다. + (즉, /apache_pb.gif를 링크하였거나 포함한 + 사이트이다.)
"Mozilla/4.08 [en] (Win98; I ;Nav)" + (\"%{User-agent}i\"): User-Agent HTTP 요청 헤더. 클라이언트 브라우저가 + 자신에 대해 알리는 식별정보이다.

+ + +

여러 접근 로그

+ + +

설정파일에 여러 CustomLog 지시어를 + 사용하면 접근 로그가 여러개 만들어진다. 예를 들어, 다음 + 설정은 세가지 접근 로그를 만든다. 첫번째는 기본 CLF 정보를 + 기록하고, 두번째와 세번째는 referer와 브라우저 정보를 + 기록한다. 마지막 두 CustomLog 줄은 어떻게 + 이전 ReferLog와 AgentLog 지시어의 + 기능을 흉내낼 수 있는지 보여준다.

+ +

+ LogFormat "%h %l %u %t \"%r\" %>s %b" common + CustomLog logs/access_log common + CustomLog logs/referer_log "%{Referer}i -> %U" + CustomLog logs/agent_log "%{User-agent}i" +

+ +

또, 이 예는 LogFormat으로 반드시 + 별명을 정의할 필요는 없음을 보여준다. 대신 CustomLog 지시어에 + 직접 로그 형식을 지정할 수 있다.

+ + +

조건부 로그

+ + +

클라이언트 요청의 성격에 따라 해당 항목을 접근 로그에 + 기록하지않고 싶을 때가 있다. 환경변수를 + 사용하면 쉽게 해결된다. 먼저, 클라이언트가 특정 조건을 + 만족하면 환경변수를 설정한다. 이 작업에는 보통 SetEnvIf를 사용한다. + 그리고 CustomLog + 지시어에 env=을 사용하여 환경변수 유무에 + 따라 요청을 집어넣거나 뺀다. 예를 들면:

+ +

+ # loop-back 인터페이스에서 요청을 표시한다 + SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog + # robots.txt 파일에 대한 요청을 표시한다 + SetEnvIf Request_URI "^/robots\.txt$" dontlog + # 나머지를 로그에 남긴다 + CustomLog logs/access_log common env=!dontlog +

+ +

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

+ +

+ SetEnvIf Accept-Language "en" english + CustomLog logs/english_log common env=english + CustomLog logs/non_english_log common env=!english +

+ +

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

+ +

로그 순환 (Log Rotation)

+ + +

조금 바쁜 서버조차도 로그파일에 저장되는 정보량은 매우 + 많다. 접속 로그는 보통 만번 요청당 1MB 이상 증가한다. 결과적으로 + 기존의 로그를 옮기거나 지우는 방법으로 로그를 주기적으로 + 순활할 필요가 있다. 아파치는 파일을 열고있는 동안에는 계속 + 이전 로그파일에 쓰기때문에 서버가 실행중일때 로그를 순환할 + 수 없다. 대신 로그파일을 옮기거나 지운후 서버를 재시작하여, 로그파일을 새로 열어야 + 한다.

+ +

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

+ +

+ mv access_log access_log.old + mv error_log error_log.old + apachectl graceful + sleep 600 + gzip access_log.old error_log.old +

+ +

로그를 순환하는 다른 방법은 다음 절에서 설명할 파이프 로그를 사용하는 것이다.

로그를 파이프로 보내기

+ + +

아파치 웹서버는 오류 로그와 접근 로그를 파일에 직접 + 쓰지않고 파이프를 통해 다른 프로세스로 보낼 수 있다. 이 + 기능을 사용하면 서버에 코드를 추가하지않고도 매우 유연하게 + 로그를 처리할 수 있다. 로그를 파이프에 쓰기위해 파일명 + 자리에 파이프문자 "|"와 뒤에 표준입력으로 + 로그 항목을 읽을 실행파일명을 적으면 된다. 아파치는 서버가 + 시작할때 파이프로 연결할 로그 프로세스를 시작하고, 서버가 + 실행되는 동안 프로세스가 죽으면 다시 시작한다. (이 마지막 + 기능때문에 우리는 이 방법을 "믿을 수 있는 파이프 로그"라고 + 부른다.)

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

가상호스트

+ + +

많은 가상호스트가 있는 서버를 + 운영할때 여러가지 방법으로 로그파일을 다룰 수 있다. 먼저, + 호스트가 한개인 서버와 같이 로그를 사용할 수 있다. <VirtualHost> 섹션이 + 아닌 주서버 설정에 로그 지시어를 두면 모든 요청이 같은 접근 + 로그와 오류 로그로 기록된다. 이 방법은 가상호스트별로 쉽게 + 통계처리를 할 수 없다.

+ +

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

+ +

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

+ +

+ LogFormat "%v %l %u %t \"%r\" %>s %b" + comonvhost + CustomLog logs/access_log comonvhost +

+ +

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

다른 로그파일

관련된 모듈	관련된 지시어
`mod_cgi` `mod_rewrite`	`PidFile` `RewriteLog` `RewriteLogLevel` `ScriptLog` `ScriptLogBuffer` `ScriptLogLength`

+ + + + +

PID 파일

+ + +

아파치 웹서버는 시작할때 logs/httpd.pid + 파일에 부모 httpd 프로세스의 process id를 저장한다. 이 + 파일명은 PidFile + 지시어로 변경할 수 있다. process-id는 관리자가 부모 프로세스에 + 시그널을 보내 서버를 재시작하거나 죽일때 사용한다. + 윈도우즈에서는 대신 -k 명령행옵션을 사용한다. 더 자세한 + 정보는 중단과 재시작 페이지를 + 참고하라.

+ + +

스크립트 로그

+ + +

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

+ + +

재작성 로그

+ + +

mod_rewrite의 강력하고 + 복잡한 기능을 사용한다면 디버깅을 위해 거의 항상 RewriteLog를 사용할 필요가 + 있다. 이 로그파일은 재작성 엔진이 어떻게 요청을 변환하는지에 + 대해 자세히 알려준다. 자세한 정도는 RewriteLogLevel 지시어로 + 조절한다.

+ +