블로그 > 엔지니어 http://blog.naver.com/find999/150002211630 | |
Log File에 대한 포괄적 접근 초기에 Log file의 분석 및 기록에 대한 흥미는 주로 이익의 추구에 의해 고무되어왔다. 대부분, 자사 Web Site의 가치 증가를 접속 수의 증가로 확인시키기를 원한다. 이 자료는 해당 Site로 통하는 Traffic 양을 통해 광고 비용과 Hosting 서비스의 가격 결정에 대한 판단 자료로 고객, 광고주, 투자자 그리고 관리자에게 보여주는데 꼭 필요하다. 추가적으로, 수년간 비공식적 시스템 관리자로 일하며, syslog와 Built-in Log Rotation System에 대한 다양하지만, 이해하기 쉽지않은 구성 Parameter를 분석한 결과, 문제를 포괄적으로 접근하고, 주요 System Event를 저장, 통보하며 원시 Data를 영구적으로 보관하는 시스템을 구성하고자 한다. Log 대상
특정 서비스의 Event에 대한 무관심으로 서비스는 사용되지도 않고, 제공될 수 없다고 생각한다. 예를 들어, System 설치 동안 모든 것을 설치하려고 하는데, 이는 추가될 서비스 및 Utility들을 찾아내기 위한 추가 시간을 줄이고 향후 필요 시에 설치를 피하기 위해서이다. 그러나, 이 전체 설치 선택 시에는 일반적으로 NFS와 rshd/rlogind와 같은 보안에 취약한 서비스가 함께 설치, 활성화된다. 이러한 문제의 중요성을 파악하고 있는 관리자는 여러 방법으로 제공되어지는 서비스를 알 수 있어야 한다. 1. 모든 사용자에 의해 수행되는 전체 Process를 보기위해 ps 명령어를 Verbose Option 서비스를 Disable시키는 것에 대한 내용은, 이 주제의 범위에 포함되지 않지만, 주로 /etc/inetd.conf의 해당 Line를 Comment화 시키거나, 서비스의 Package를 제거, 또는 자동적으로 시작되지 않게 rc Directory에서 Startup Scrip를 이동시키는 방법 등이 Syslog를 사용하는 Service
예를 들어, sendmail의 Source Code에 syslog() 라는 UNIX C Library Function의 호출이 곳곳에 쓰여지는데, 이 Function은 syslogd에 다음과 같이 구성된 메시지를 보낸다. 1. Log 항목을 요청하는 Program의 Type (즉, mail, news 또는 일반 Daemon 등) Sendmail의 Daemon은 수신되는 Mail을 Accept 또는 Reject시 info 항목을 보내고, Client와 Connection이 끊어질 경우 notice 항목을 보낸다. Sendmail은 수행 중 성공 또는 실패 작업에 따라 메시지의 항목을 만드는 경우가 수백가지가 된다.그러므로, syslog에 연관된 Daemon의 경우, 문제는 서비스가 Log 항목들을 생성하는 방법이 아니라, 이들을 적절하게 처리하기 위해 어떻게 syslog를 구성하느냐에 있다. Syslog 구성
# # Log all the mail messages in one place. 이 구성 File의 첫번째 항목은 mail과 인증 서비스를 제외한 모든 서비스에서 발생시키는 info에서 emergency 의 우선순위를 가지는 메시지를 /var/log/messages에 저장한다. Sendmail은 아주 많은 항목의 메시지를 발생시켜 실제 중요한 메시지들을 쉽게 확인할 수 첫번째 항목은 또한 특정 이름이 지정되지 않은 Daemon에 의해 생성된 메시지도 저장한다. 이와 같은 Daemon 중에 named라는 DNS Server Daemon은 해당 사용에 대한 시간 통계를 발생시키는데(Compile될 때 Enable 되어야 함) 좋은 예 중에 하나이다. 이와 같은 이유로, daemon.info 메시지를 별도의 Log File에 기록하고 Main log file에 대해서는 daemon.!=info를 사용하여 이를 배제시키는 것이 바람직하다. 두번째 항목은 모든 mail 메시지를 /var/log/maillog로 보내며, 세번째 항목은 인증 메시지를 /var/log/secure로 보낸다. 마지막 항목의 Destination Field의 "*"은 도움을 표시하는 구실로써 현재 Login 되어 있는 모든 사용자의 화면에 표출되게 한다. 여러 Machine들이 각각의 Machine에서 개별적으로 Log를 보관하지 않고, Loghost 라고 하는 하나의 syslog server로 보낼 수 있게 구성할 수 있다. 구성이 올바르게 되었을 때, Loghost는 다른 Machine에서 보내는 UDP Packet를 기다리며, 이 메시지를 Local Log file에 기록하게 된다. 다음의 절차는 Red Hat Linux에 대해 이런 기능을 설정하여 준다. 1. Loghost에서, syslogd를 수행시키는 rc Startup Scrip에서 -r Parameter를 추가 그러나, 이런 기능은 외부 침입자에게 Loghost가 서비스 공격 및 자신의 Log file에 대한 보호를 하기 어렵게 만든다. 이런 기능은 Loghost가 방화벽의 보호 아래에 있거나, 특정 syslog Client에 제한적 접근을 할 수 있는 ipfwam 또는 ipchains와 같은 Kernel syslog에 대한 man Page에서 해당 syntax, 여러 구성 예제 그리고 서비스 형태의 전체 List 및 보안 Level에 대해 다루고 있다. 여러 가능한 정보를 보기 위해, syslog, syslog.conf 그리고 syslogd의 man Page를 보는 것이 필요하다. syslog는 각각의 서비스에서 발생시키는 Client Library Function이고, syslogd는 syslog.conf에 의해 구성되는 Daemon이라는 것을 기억하여야 한다. Syslog 문제 해결
첫째, 구성 File을 다시 읽을 수 있게 syslogd를 재시작시킨다. syslogd를 재시작시키는 한 방법은 syslogd에 Hangup Signal을 보내는 것인데, ps 명령어로 syslogd의 pid를 찾아 kill -HUP <pid>를 수행한다. 다른 방법으로는, Linux 또는 Solaris 환경에서 /etc/rc.d/init.d/syslog restart와 같이 Startup Scrip를 restart Parameter로 수행하는 것이다. 다음은, 목적지 File이 존재하는지를 점검하여야 하는데, syslogd가 수정을 하기위해 반드시 존재하여야만 한다. touch <filename> 명령어로 Empty File을 만들 수 있다. syslog가 재시작되면, 해당 File에 적정한 메시지가 기록될 것이다. Syslog를 사용하지 않는 서비스
Apache Web server에 대한 Logging는 httpd.conf에 의해 구성되는데, /usr/local/etc/httpd 또는 표준 Red Hat RPM Distribution에서는 /etc/httpd/conf에 일반적으로 위치한다. 정규적으로 log를 사용하기 위해 쓰여져야 할 Line은 다음과 같다. LogFormat "%h %l %u %t \"%r\" %>s %b" common CustomLog logs/access_log common LogFormat은 Format 특정자의 조합을 대표하여 나타내는 common, referer 및 agent와 같이 alias를 정의하는데, 여기에서 요청하는 Host를 나타내는 %h, 요청 받은 Page를 여러 개의 Log file들에 해당 항목을 분산하는 방법 이외에, 이들을 하나의 Log File에 둘 수 있다. 다음의 정의는 각 요청에 대한 모든 정보를 access_log로 둘 수 있다. CustomLog logs/access_log combined Apache에서의 오류에 대한 Logging은 오류의 정도에 따라 info, warn, error와 같은 여러 Level을 가지며, syslog와 비슷하다. 오류 Log에 보내지는 메시지의 최소 우선 ErrorLog logs/error_log Web Server가 자체 Log file을 유지하게 구성이 되면, 이 File들의 크기를 조정하여야 하며, 해당 File System이 Full이 되지 않게 조심하여야 한다. Server가 많이 사용 Log File들의 감시
첨부에 있는 logtail.pl script는 Log file이 최종 점검된 이후 발생된 항목에 대해 <logfile> Parameter는 관찰될 Log file이며, <logposfile>은 수행될 때마다 <logfile>의 크기를 저장할 수 있는 기록가능한 File이다. 이 Script는 이전에 통보된 Log 부분은 생략하며, 최신의 항목만을 stdout에 표출시킨다. # # # logtail.pl Script가 하루에 한번만 수행될 경우, 수행 시간을 Log Rotation이 되기 이 Section에서 마지막으로 swatch라는 log에서 특정 Pattern을 점검하는 Utility를 소개한다. swatch는 원하는 Pattern(예를 들어 "panic")을 찾을 경우, Terminal Bell, mail 전송, 또는 다른 Program을 실행할 수 있다. 특정 machine 과 서비스에 대한 swatch 구성은 원하는 Log 항목과 관심을 가질 대상에 대한 약간의 경험 지식이 있어야 한다. 이 경험은 원시 Log File을 logtail.pl로 관찰하는 것이 가장 최선의 방법이다. Log File의 Rotating
Solaris는 System Log Rotating에 대한 간단한 방법이 제공된다. 기본적으로 Root Account의 Cron 작업은 아래와 같은 간단한 Shell Scrip를 수행시키는데, 이는 현 System Log를 Save File로 이름을 변경하고, 기존 저장된 파일은 더 오래된 저장 File 이름으로 이동시키며, 결과적으로 가장 오래된 기존 File은 삭제 시킨다. # Solaris usr/lib/newsyslog Red Hat Linux에서는 더욱 유연성을 가지는 logratate system을 소개하였다. 이것에 # /etc/logrotate.d/syslog 이들 전략들은 모두 보관되는 log File들의 이름에 제한이 있는데, 단순히 원래 이름에 숫자의 확장자만을 더 붙이는 것이고, 위치 또한 현재 File과 동일 위치에 저장된다. 만약 보관되는 File이름이 해당 날짜에 따라 지정되고, 이들 보관 File들이 영구 저장에 별도로 할당된 영역으로 이동될 수 있으면 더욱 좋을 것이다. 다음 Section 은 이러한 Log File 보관과 Log Rotation 기능의 보완 방법에 대해 기술한다. Log File의 보관
Usage: archive.pl -- from <srcfile> --to <destdir> 선택 Parameter들은 Script가 보관전에 원시 또는 목적 File들이 존재하는지를 확인할 것인가, 그리고 보관되는 이름을 어떵게 지정할 것인가를 제어 할 수 있는 Boolean 스위치를 나타낸다. 기본적으로, archive.pl은 '\..*' pattern 을 사용하여 확장자를 Matching하여 첫번째 Dot(.) 이후의 모든 것을 확장자로 인식한다. boot.log.0이라는 File에 대해서는 기본적으로 boot.19990801로 보관되어 바람직하게 되지 않는다. 이 File을 boot.log.19990801로 보관하기 위해, 확장자 Pattern을 '\.\d*'를 사용하여 숫자로 된 확장자 만을 인식할 수 있게 할 필요가 있다. Solaris newsyslog Script(위에서 언급된)는 가장 오래된 Log File을 제거하지 않고 /usr/local/bin/archive.pl -- from $LOG.3 --to archive Linux 환경에서, 유사하 명령을 logrotate 구성 File에 삽입시킬 수 있다. 다음은 수정된 Apache rotation File이다. # Enhanced /etc/logrotate.d/apache /var/log/httpd/error_log { Apache의 logrotate file에 대한 이 수정은 access_log.3 과 error_log.3을 Rotate되어 삭제되는 대신, 예를 들어 access log는 /var/log/httpd/archive/access_log.19990801.gz로 저장되어 Log File 분석 Tool에 의해 계속 점검될 수 있다. 저장된 Log File들의 분석
보관된 Web Server Log와 관련하여 Server의 시작 시점에서 부터의 모든 Web server의 이전 활동에 대한 요약을 지속적으로 유지하는 것은 특별히 가치 있는 시도이다. Server의 활동에 대한 최신 요약을 고객에게 제시할 수 있다면 Web Site에 광고를 고려하는 고객이나, Web site의 Traffic을 이용하고자 하는, 또는 전체 Domain을 구매하려고 하는 잠재적인 투자자에게 깊은 감동을 줄 수 있을 것이다. 이전 개요를 구성하기 위해서는 On-line으로 모든 이전 access log를 저장하고 이들을 시간대별, 또는 일별로 Analog와 같은 분석 Tool을 써서 처리하여야 한다. Analog 는 Web Server Log File들을 점검하여 Server Directory, 특정 Files, Browser Domains, 그리고 Browser Type에 따라, Access되어지고 몇몇 형태로 구성되어진 Page 및 files의 수 개요를 만들어 낸다. Analog 구성 File은 일반적으로 /usr/local/etc/httpd/analog/analog.cfg 또는 제공된 RPM에 의해 다른 곳에 저장된다. 이 구성 File은 분석될 Logs의 위치가 수정되고, Web Server Log가 기록되는 방법을 지정하는 Format 형식을 가져야만 한다. LOGFORMAT은 Apache 구성 File에서의 LogFormat line에 해당한다. # /usr/local/etc/httpd/conf/analog.cfg LOGFILE /var/log/httpd/access_log* HOSTNAME "Company X" BROWSER ON DNSFILE "/usr/local/etc/httpd/analog/dnsfile.txt" 이 구성 File은 Analog가 httpd/ 와 httpd/archive/ Directory에 있는 Log Files을 해석하는 방법을 나타내고, Browser Types과 참조 Sites에 따라 Analog에서 다른 최신 개요에 더하여, 최종적으로 완성해야 할 것은 Web Site 주기 동안 증대에 대한 이전 검토의 일별 개요를 보관하는 것이다. 다음 명령어는 archive.pl Script를 사용하여 Analog에서 발생되는 현재의 개요를 timestamp를 포함하는 다른 이름으로 변경을 시킨다. 그 결과 status/ Directory 아래에 모든 일별 개요들이 나타나게 된다. /usr/local/bin/archive.pl \ 보관된 개요들의 집합은 19990801.html 과 같은 이름을 가질 것이다. 결 론
|
0