보안 경고

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

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

오류 로그 (Error Log)

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

오류 로그는 보통 (전형적으로 유닉스 시스템에서는 error_log, 윈도우즈와 OS/2에서는 error.log) 파일에 기록된다. 유닉스 시스템에서 서버는 오류를 syslog나 파이프를 사용하여 다른 프로그램으로 보낼 수도 있다.

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

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

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

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

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

접근 로그 (Access Log)

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

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

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

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

Common 로그 형식

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

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

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

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

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

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)이다. 다음과 같이 사용한다.

이 형식은 두 항목을 더 추가한 것을 제외하고는 Common 로그 형식과 완전히 같다. 추가된 항목들은 퍼센트 지시어 %{header}i를 사용한다. 여기서 header 자리에 HTTP 요청 헤더 이름이 나올 수 있다. 이 형식의 접근 로그는 다음과 같다:

추가된 항목은:

"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으로 반드시 별명을 정의할 필요는 없음을 보여준다. 대신 CustomLog 지시어에 직접 로그 형식을 지정할 수 있다.

조건부 로그

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

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

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

로그 순환 (Log Rotation)

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

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

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

로그를 파이프로 보내기

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

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

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

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

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

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

가상호스트

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

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

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

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

다른 로그파일

PID 파일

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

스크립트 로그

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

재작성 로그

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