수안이의 컴퓨터 연구실

[NGN] 정책 기반 NGN 과금 및 제어 국제표준화 본격적 착수 한국정보통신기술협회 2008-07-14 [방송기술] DMB 콘텐츠를 위한 표준 파일 포맷(DMB-AF) 탄생 배경 한국정보통신기술협회 2008-07-14 상황인식 컴퓨팅의 현황과 전망 한국정보사회진흥원 2008-06-03 이더넷 전송망 기술 동향 분석 IITA정보서비스단 2008-07-23 국내 IPTV 서비스와 기술 동향 IITA정보서비스단 2008-07-23 월간 정보보호뉴스 2008년 7월 한국정보보호진흥원 2008-07-15 컴퓨터와 첨단기술을 이용한 범죄수사팀 CATCH 컴퓨터프로그램보호위원회 2008-07-16 Nano Qplus 센서노드 SW 플랫폼 한국전자통신연구원 2008-07-10 UWB 간섭 신호 최대치 검출 프로그램 한국전자통신연구원 2008-07-10 지오웹 맵 서비스 엔진 v1.0 기술 한국전자통신연구원 2008-07-10 리눅스 커널 분석 한국IBM 2008-07-11 리눅스 팁: 리눅스 팁: cron과 at를 사용한 작업 일정 관리 한국IBM 2008-07-11 리눅스 SCSI 하위 시스템 한국IBM 2008-07-11 리눅스 네트워킹 스택 분석 한국IBM 2008-07-14 리눅스 슬랩 할당자 분석 한국IBM 2008-07-14 CFS로 다중 프로세스 관리하기 한국IBM 2008-07-14 LAMP 시스템 조율, Part 1: LAMP 아키텍처 이해 한국IBM 2008-07-14 LAMP 시스템 조율, Part 3: MySQL 조율 한국IBM 2008-07-15 UID와 GID 변경하기 한국IBM 2008-07-15 셀/B.E. 컨테이너 가상화, Part 2: 구현 한국IBM 2008-07-15 LAMP 시스템 조율, Part 2: 아파치와 PHP 최적화 한국IBM 2008-07-15 셀/B.E. 컨테이너 가상화, Part 1: 개념, 아키텍처, 도구 한국IBM 2008-07-14 지상파/IPTV 데이터방송 지원 미들웨어 기술 한국전자통신연구원 2008-07-14 리눅스에서 공유 객체 활용하기 한국IBM 2008-07-16 리눅스 파일 시스템 분석 한국IBM 2008-07-15 리눅스 커널 가상 기계 탐험 한국IBM 2008-07-15 QEMU로 시스템 에뮬레이션하기 한국IBM 2008-07-15 시스템 관리 툴킷: 로그 파일 이해하기 Martin Brown 2008-07-15 리눅스 동기화 메서드 분석 한국IBM 2008-07-16 리눅스 팁: bash 매개변수와 매개변수 확장 한국IBM 2008-07-16 리눅스 시스템 호출을 활용한 커널 명령 한국IBM 2008-07-16 PS3에서 리눅스 개발, Part 1: 장난감을 넘어서 한국IBM 2008-07-16 유닉스와 리눅스를 함께 어울리게 만들기 한국IBM 2008-07-16 휴대전화 시장 NTT도코모 점유율, 처음으로 50% 미만 기록 IITA정보서비스단 2008-07-23 5월 미국 소비자 가전 시장 7% 성장, 금년 첫 플러스 성장 IITA정보서비스단 2008-07-23 글로벌 혁신 기업 사례 분석과 시사점 정보통신연구진흥원 2008-07-14 개방화 물결이 몰아치는 스마트폰 한국소프트웨어진흥원 2008-07-15 BI시장 1000억 돌파 `눈앞` 디지털타임즈 2008-07-15 초저가 노트북 PC 산업 동향 IITA정보서비스단 2008-07-23 글로벌 네트워크형 산업모델의 부상과 시사점 SERI 2008-07-11 가치 창출형 성과평가 시스템의 요건 LG경제연구원 2008-07-14 가치 생산에서 가치 조합으로 LG경제연구원 2008-07-14 국내외 경제환경 변화가 국내 IT산업 수출에 미치는 영향 산은경제연구소 2008-07-11 투자활성화와 고용창출의 관계분석 산업연구원 2008-07-14 글로벌 전자부품 기업 '07년 성과 분석 LG경제연구원 2008-07-15 경영진 영입할 것인가 육성할 것인가 LG경제연구원 2008-07-15 ERP 도입으로 경영혁신을 시도하는 부품ㆍ소재산업 한국소프트웨어진흥원 2008-07-15 미국 경제 내년에도 어려움 지속 예상 국제금융센터 2008-07-07 해외 IT R&D Policy 39호 정보통신연구진흥원 2008-03-31 I. 미국의 과학기술 정책동향 정보통신연구진흥원 2008-03-31 1. 연구개발: 글로벌 경제에서 미국 경쟁력 강화를 위한 정책제안 정보통신연구진흥원 2008-03-31 2. 연구개발: 미국의 동향 및 국가간 연계 정보통신연구진흥원 2008-03-31 III. IT 정책 이슈 리포트 정보통신연구진흥원 2008-03-31 DMCA 접근권 해석에 대한 미 법원 판결 컴퓨터프로그램보호위원회 2008-07-16 디지털정보법률자료실 2008년7월3주 신착자료 컴퓨터프로그램보호위원회 2008-07-16 RFID/USN 산업발전 비전 및 전략(안) 한국RFID/USN협회 2008-06-27 『정보화정책』연구윤리 규정 한국정보사회진흥원 2008-07-16 벤처투자환경변화와 IT기업의 전략적 벤처투자 정보통신정책연구원 2008-07-15 덴마크, 공항 승객을 위한 RFID 시스템 운영 RFIDjournal 2008-07-10 중국, e-commerce 시장 전망 Sina 2008-07-15 호주, 브로드밴드 네트워크 사용 증가 eMarketer 2008-07-15 미국의 IT 부문 고용 증가 지속 Informationweek 2008-07-15 미국, 해외정보감시법(FISA) 통과 http://www.computerworld.com 2008-07-15 미국 하원, 전자메시지보존법 통과 FCW 2008-07-15 Ofcom, 그린 IT 프로젝트 착수 ITPro 2008-07-15 중국, 2008년 상반기 소프트웨어 등록건수 지속 상승 컴퓨터프로그램보호위원회 2008-07-16 러시아 경기과열 우려에 대한 진단과 향후 전망 대외경제정책연구원 2008-07-10 일본의 노사관계와 한국에의 시사 동경대 2008-07-10 미 대선후보의 주요 정책 비교와 시사점 SERI 2008-07-14 미국 가계부채의 급증과 조정 전망 SERI 2008-07-16 정보격차ㆍ정보문화 해외동향(7/14) 한국정보문화진흥원 2008-07-16

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

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 특성상 동시에 파일을 열 수 있는 개수의 제한 등으로 인하여 모든 가상 호스트마다 개별적인 로그 파일을 만들어 줄 수 없을 때 사용할 수가 있다.