솔라리스 및 리눅스 로그 관련

전형적인 유닉스(UNIX®) 관리자라면 시스템을 관리하면서 나름대로 자주 사용하는 유틸리티, 스크립트, 기교가 있기 마련이다. 

이러한 유틸리티, 스크립트, 명령 체인 등은 관리자가 수행할 작업을 단순화시켜 준다. 

일부 도구는 운영체제에 딸려오지만, 대다수 도구와 기교는 수년 동안 쌓아온 경험과 시스템 관리를 조금이라도 편하게 하려는 욕구에서 나왔다. 

이 기사 연재는 다양한 유닉스 환경에서 제공하는 도구를 최대한 활용하는 방법을 살펴본다. 

또한 다양한 유닉스 플랫폼에서 시스템을 단순하게 관리하는 방법도 소개한다.

원문 : http://www.ibm.com/developerworks/kr/library/au-satlogfilebasics/index.html

위로

로그 파일

모든 시스템은 시스템 내 다양한 정보를 추적하고 기록하는 로그 파일을 생성한다. 

파일 내용과 용도는 시스템에 따라 다르지만, 본질적으로 파일에 담긴 핵심 정보는 대개 비슷하다.

예를 들어, 모든 유닉스와 리눅스 시스템은 syslog 도구를 사용한다. 

syslog는 운영체제와 응용 프로그램과 서비스가 정보를 기록할 때 사용하는 범용 로그 시스템이다. 

syslog는 로그인 정보, 성능 정보, 하드웨어와 시스템 실패 정보 등 다양한 정보를 기록한다. 

syslog 외에도 시스템에는 서비스 로그, 환경 로그, 응용 프로그램 로그 등 시스템 상태와 동작 상태를 기록하는 다양한 로그가 있다.

로그 파일에서 정보를 분석하고 추출하는 작업은 시간이 많이 걸리고 복잡하다. 

하지만 로그 파일에 담긴 풍부한 정보를 무시하기는 어렵다.

로그 파일은 잠정적인 문제, 결함, 보안 구멍을 찾아내는 데 도움이 되는 정보를 제공한다. 

또한 제대로만 분석한다면 서버에 걸리는 하중과 용량 문제도 미리 파악해 대비할 수 있다.

위로

로그 위치

로그 파일 위치는 시스템에 따라 다르다. 대다수 유닉스와 리눅스 시스템은 /var/log 디렉터리 안에 로그 파일을 생성한다. 예를 들어, Listing 1은 젠투(Gentoo) 리눅스 시스템에 들어 있는 로그 파일 목록이다.

Listing 1. 리눅스 /var/log 디렉터리 내용

$ ll /var/log total 3312 -rw-r----- 1 root root 8218 2007-11-03 06:21 dmesg -rw-rw---- 1 portage portage 650111 2008-02-02 13:01 emerge.log -rw------- 1 root root 24024 2007-11-05 07:26 faillog -rw-r--r-- 1 root root 386032 2007-09-28 14:39 genkernel.log drwxr-xr-x 2 root root 4096 2007-11-03 06:47 iptraf/ -rw-r--r-- 1 root root 292292 2008-02-03 08:07 lastlog -rw------- 1 root root 1346931 2008-02-03 08:50 messages drwxr-xr-x 2 root root 4096 2006-08-30 17:04 news/ drwxr-xr-x 3 root root 4096 2007-09-28 13:22 portage/ drwxrwx--- 2 root portage 4096 2007-11-03 06:40 sandbox/ drwxrwx--- 2 snort snort 4096 2007-10-13 11:34 snort/ -rw-rw-r-- 1 root utmp 496896 2008-02-03 08:07 wtmp -rw-rw-rw- 1 root mc 61189 2007-06-10 11:37 Xorg.0.log -rw-rw-rw- 1 root root 61189 2007-06-10 10:40 Xorg.0.log.old

Solaris®, IBM® AIX®, HP-UX®는 기본 syslog 파일과 대다수 로그 파일을 /var/adm 디렉터리 아래 저장한다. Listing 2를 참조한다.

Listing 2. 전통적인 유닉스 /var/admin 디렉터리 내용

$ ls -al /var/adm total 230 drwxrwxr-x 9 root sys 512 Feb 3 15:30 . drwxr-xr-x 48 root sys 1024 Feb 3 15:32 .. drwxrwxr-x 5 adm adm 512 Feb 2 16:13 acct -rw------- 1 uucp bin 0 Jan 12 18:49 aculog drwxr-xr-x 2 adm adm 512 Feb 2 16:03 exacct -r--r--r-- 1 root root 2856 Feb 3 16:10 lastlog drwxr-xr-x 2 adm adm 512 Feb 2 16:03 log -rw-r--r-- 1 root root 69065 Feb 3 16:08 messages drwxr-xr-x 2 root sys 512 Feb 2 16:09 pool drwxrwxr-x 2 adm sys 512 Feb 2 16:13 sa drwxr-xr-x 2 root sys 512 Feb 2 17:03 sm.bin -rw-rw-rw- 1 root bin 0 Jan 12 18:47 spellhist drwxr-xr-x 2 root sys 512 Feb 2 16:03 streams -rw------- 1 root root 93 Feb 3 16:08 sulog -rw-r--r-- 1 root bin 3720 Feb 3 16:14 utmpx -rw-r--r-- 1 adm adm 29760 Feb 3 16:10 wtmpx

반면, Listing 3에서 보듯이 시스템과 관련 없는 메시지나 정보는 /var/log 아래 쓴다. 예를 들어, 솔라리스는 기본적으로 전자편지 디버그 메시지를 /var/log/syslog에 쓴다.

Listing 3. 솔라리스 /var/log 디렉터리 내용

$ ls -al /var/log/ total 48158 drwxr-xr-x 7 root sys 512 Feb 3 16:07 . drwxr-xr-x 48 root sys 1024 Feb 3 15:32 .. -rw------- 1 root sys 0 Jan 12 18:48 authlog -rw-r--r-- 1 root other 27 Feb 2 16:17 brlog drwxr-xr-x 2 root root 512 Feb 2 16:39 gdm drwxr-xr-x 2 root sys 512 Feb 2 16:09 pool -rw-r--r-- 1 root sys 24480410 Feb 3 12:51 postrun.log drwxr-xr-x 2 root sys 512 Feb 2 16:41 swupas -rw-r--r-- 1 root other 635 Feb 2 17:25 sysidconfig.log -rw-r--r-- 1 root sys 3967 Feb 3 16:08 syslog drwxr-xr-x 3 root sys 512 Feb 2 17:25 webconsole drwxr-xr-x 2 root sys 512 Feb 2 16:37 xen -rw-r--r-- 1 root root 66171 Feb 3 16:07 Xorg.0.log -rw-r--r-- 1 root root 66256 Feb 3 16:06 Xorg.0.log.old

물론 로그 파일 위치를 찾기는 어렵지 않다. 하지만 로그 파일에 담긴 정보를 활용하려면 파일 내용을 이해해야 한다.

드물지만 전혀 엉뚱한 위치에 로그 파일을 저장하는 유닉스 계열도 있다. 하지만 로그 파일 위치를 앞서 언급한 디렉터리 중 하나로 통일하려는 움직임이 계속되어 왔다는 사실을 언급한다.

위로

로그 유형과 내용

로그 파일은 두 가지 유형으로 나뉜다. 하나는 단순한 텍스트 파일로, 메시지와 정보를 단순한 텍스트로 저장한다. 다른 하나는 이진 파일로, 인코딩된 정보를 기록한다. 일반적인 시스템에서 대다수 로그는 텍스트 파일이다. 쓰기가 쉽고, 더 중요한 점은 읽기가 쉬운 탓이다. 그러나 텍스트 파일은 구조적인 방식으로 정보를 추출하기 어렵다는 단점이 있다. 텍스트 파일에는 정보를 자유롭게 기록할 수 있기 때문이다.

이진 파일은 기록할 정보가 아주 구조적이거나 특정한 형식일 때 유용하다. 예를 들어, utmp와 wtmp는 크기가 일정한 블록을 파일에 기록한다. 그러면 정보를 읽고 쓰기가 훨씬 빨라지지만, 대신 특별한 도구를 사용하지 않으면 파일을 읽지 못한다는 단점이 있다.

시스템 로그(syslog)

syslog 서비스는 백그라운드 프로세스로 돌면서 로그 메시지를 받아 하나 이상 개별 파일에 기록하는 데몬이다. syslog로 보내는 모든 메시지는 날짜, 시각, 호스트 이름을 포함한다. 즉, 여러 호스트에서 한 호스트로 메시지를 보내 한 파일에 기록하는 구성도 가능하다.

각 메시지는 메시지를 보낸 서비스(예: mail, dhcp, kernel)와 메시지 심각도도 포함한다. 심각도는 info(정보용), warning, error, critical(심각함), emergency(응급) 등으로 나뉜다.

syslog 서비스는 매우 다양한 구성으로 설정할 수 있다. 필요하다면 (일반적으로는 /etc/syslog.conf를 통해) 기록할 정보 심각도를 제한하거나 로그 파일 위치를 변경할 수 있다. 예를 들어, 모든 표준 정보는 파일에 쓰는 대신 심각한(critical) 정보는 관리자 콘솔로 직접 띄워도 좋다. Listing 4는 솔라리스 10에서 기본적으로 사용하는 syslog.conf 파일이다.

Listing 4. syslog.conf 예제

*.err;kern.notice;auth.notice /dev/sysmsg *.err;kern.debug;daemon.notice;mail.crit /var/adm/messages *.alert;kern.err;daemon.err operator *.alert root *.emerg * ... mail.debug ifdef('LOGHOST', /var/log/syslog, @loghost) ... ifdef('LOGHOST', , user.err /dev/sysmsg user.err /var/adm/messages user.alert 'root, operator' user.emerg * )

syslog는 리눅스/유닉스에서 사용하는 표준 로그 메커니즘이므로 기록하는 정보량이 방대하다. 또한 부트 메시지, 로그인 메시지, 인증 정보, 서비스 시작/종료 정보 등 기록하는 정보 종류도 매우 다양하다. 게다가 전자편지 전송 상태, 파일 시스템 문제, 심지어 DHCP 임대, DNS 문제, NFS 문제까지 기록하는 경우도 많다. syslog가 모든 정보를 무조건 파일로 저장하지 않으므로(다른 곳에다 출력하는 경우도 많으므로) 때로는 syslog가 온갖 정보를 기록한다는 사실이 명백하게 드러나지 않는다.

syslog가 디스크에 저장하는 로그 파일 위치는 유닉스 계열에 따라 다르다. 많은 리눅스 시스템은 /var/log/messages 파일을 사용한다. AIX, 솔라리스, HP-UX는 /var/adm/messages 파일을 사용한다.

Listing 5는 솔라리스에서 /var/adm/messages를 살펴본 결과다.

Listing 5. 시스템 로그 파일 예제

Feb 3 16:06:58 solaris2 ata: [ID 496167 kern.info] cmdk2 at ata1 target 0 lun 0 Feb 3 16:06:58 solaris2 genunix: [ID 936769 kern.info] cmdk2 is /pci@0,0/pci-ide@1f,1/ide@1/cmdk@0,0 Feb 3 16:06:59 solaris2 asy: [ID 267298 kern.notice] asy0: UART @ 3f8 scratch register: expected 0x5a, got 0xff Feb 3 16:06:59 solaris2 asy: [ID 702181 kern.notice] Cannot identify UART chip at 3f8 Feb 3 16:06:59 solaris2 asy: [ID 267298 kern.notice] asy1: UART @ 2f8 scratch register: expected 0x5a, got 0xff Feb 3 16:06:59 solaris2 asy: [ID 702181 kern.notice] Cannot identify UART chip at 2f8 Feb 3 16:07:01 solaris2 genunix: [ID 314293 kern.info] device pciclass,030000@2(display#0) keeps up device sd@1,0(sd#1), but the latter is not power managed Feb 3 16:07:01 solaris2 /usr/lib/power/powerd: [ID 387247 daemon.error] Able to open /dev/srn Feb 3 16:07:08 solaris2 /sbin/dhcpagent[164]: [ID 778557 daemon.warning] configure_v4_lease: no IP broadcast specified for ni0, making best guess Feb 3 16:07:31 solaris2 sendmail[503]: [ID 702911 mail.crit] My unqualified host name (solaris2) unknown; sleeping for retry Feb 3 16:07:32 solaris2 sendmail[507]: [ID 702911 mail.crit] My unqualified host name (solaris2) unknown; sleeping for retry Feb 3 16:07:48 solaris2 svc.startd[7]: [ID 652011 daemon.warning] svc:/system/webconsole:console: Method "/lib/svc/method/svc-webconsole start" failed with exit status 95. Feb 3 16:07:48 solaris2 svc.startd[7]: [ID 748625 daemon.error] system/webconsole:console failed fatally: transitioned to maintenance (see 'svcs -xv' for details) Feb 3 16:07:55 solaris2 pseudo: [ID 129642 kern.info] pseudo-device: devinfo0 Feb 3 16:07:55 solaris2 genunix: [ID 936769 kern.info] devinfo0 is /pseudo/devinfo@0 Feb 3 16:08:31 solaris2 sendmail[503]: [ID 702911 mail.alert] unable to qualify my own domain name (solaris2) -- using short name Feb 3 16:08:32 solaris2 sendmail[507]: [ID 702911 mail.alert] unable to qualify my own domain name (solaris2) -- using short name

위 예제에서 보듯이, 하드웨어 장치 문제에서 현재 전자편지 서비스 구성 문제에 이르기까지 파일에 기록되는 정보 유형은 매우 다양하다.

파일 형식은 간단하다. 각 메시지는 날짜, 호스트 이름, 서비스 이름, 고유 ID(행이 여럿에 걸치는 메시지를 저장하고 식별할 수 있다), 식별자(예, 서비스 이름)와 심각도를 포함한다. 나머지 부분은 각 서비스에서 자유롭게 출력하는 오류 메시지다.

파일 형식이 어느 정도 일관적이므로 원하는 정보를 찾기는 쉽다. 파일 내 모든 메시지는 고유한 ID와 오류 메시지 식별자와 심각도가 매겨져 있다.

예를 들어, 전자편지 시스템이 생성했고 심각도가 'critical'인 메시지를 보려면 $ grep mail.crit /var/adm/messages 명령을 수행한다.

그러나 각 메시지가 뜻하는 구체적인 의미를 해독하기는 다소 어렵다. (syslog 데몬이 기록한) 파일 내 처음 열(column) 몇 개는 표준화되어 있으므로 이해하기 쉽지만, 나머지 정보 형식은 순전히 오류를 보고한 서비스에 달려 있다.

로그 파일 내용을 읽고 분석하기 어렵다는 이유가 여기에 있다. 오류를 보고한 서비스에 맞춰 행 구문을 분석해야 하기 때문이다. 게다가 그렇게 하더라도 형식을 위반하는 행이 존재하기 마련이다.

커널 로그(dmesg와 alog)

모든 리눅스와 유닉스 시스템에는 커널 로그가 있다. 커널 로그는 커널의 일부로, 디스크에 기록하지 못하는 커널 정보를 기록하는 메모리 영역이라 하겠다. 커널이 파일 시스템을 로드하기 전에 생성하는 정보를 기록해야 하기 때문이다.

예를 들어, 시스템을 시작하는 동안에는 파일 시스템에 쓰기를 수행하지 못한다. 대개 부팅 시에는 파일 시스템을 읽기 전용 모드로 연결했다가 시스템이 안전하다고 판단된 후에야 읽기/쓰기 모드로 전환하기 때문이다. 이 때 시스템에 연결된 디바이스 정보와 부팅 과정에서 발생한 문제나 결함이 커널 로그에 기록된다.

어떤 시스템은 정보를 주기적으로 파일(/var/log/dmesg)에 쓴다. 어떤 시스템은 alog 명령(AIX)이나 dmesg(다른 유닉스/리눅스 계열 전부)로만 정보를 살펴볼 수 있다.

커널이 생성하는 정보가 syslog 등을 통해 항상 파일로 저장되지는 않는다. 즉, 디바이스나 하드웨어 내부 정보 등 일부 정보는 dmesg 로그로만 확인할 수 있다는 뜻이다.

예를 들어, Listing 6은 젠투 리눅스 시스템에서 dmesg를 살펴본 결과다. 여기서는 부팅 정보를 보여준다. 설명을 위해 불필요한 부분은 잘라내었다.

Listing 6. dmesg 로그 내용

$ dmesg Linux version 2.6.22-gentoo-r8 (root@gentoo2.vm) (gcc version 4.1.2 (Gentoo 4.1.2 p1.0.1)) #1 SMP Fri Sep 28 14:22:07 GMT 2007 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 0000000000100000 - 0000000020000000 (usable) 0MB HIGHMEM available. 512MB LOWMEM available. Entering add_active_range(0, 0, 131072) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 131072 HighMem 131072 -> 131072 early_node_map[1] active PFN ranges 0: 0 -> 131072 On node 0 totalpages: 131072 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 992 pages used for memmap Normal zone: 125984 pages, LIFO batch:31 HighMem zone: 0 pages used for memmap DMI not present or invalid. Allocating PCI resources starting at 30000000 (gap: 20000000:e0000000) Built 1 zonelists. Total pages: 130048 Kernel command line: root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/hda3 udev Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to ffffd000 (0140c000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c054e000 soft=c052e000 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 2295.874 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 511616k/524288k available (3150k kernel code, 12100k reserved, 818k data, 264k init, 0k highmem) virtual kernel memory layout: fixmap : 0xffe17000 - 0xfffff000 (1952 kB) pkmap : 0xff800000 - 0xffc00000 (4096 kB) vmalloc : 0xe0800000 - 0xff7fe000 ( 495 MB) lowmem : 0xc0000000 - 0xe0000000 ( 512 MB) .init : 0xc04e7000 - 0xc0529000 ( 264 kB) .data : 0xc0413884 - 0xc04e0364 ( 818 kB) .text : 0xc0100000 - 0xc0413884 (3150 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 4674.89 BogoMIPS (lpj=23374475) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0f80b9b9 00000000 00000000 00000000 00000001 00000000 00000000 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L3 cache: 4096K CPU: After all inits, caps: 0f80b9b9 00000000 00000000 00000140 00000001 00000000 00000000 ...

Listing 7은 젠투 리눅스를 탑재한 다른 시스템에서 출력한 결과다. 여기서는 동작 중인 파일 시스템에서 보고한 몇 가지 결함을 보여준다.

Listing 7. dmesg로 얻은 디스크 오류

EXT3-fs: mounted filesystem with ordered data mode. sd 7:0:1:0: [sdf] Result: hostbyte=0x00 driverbyte=0x08 sd 7:0:1:0: [sdf] Sense Key : 0x3 [current] sd 7:0:1:0: [sdf] ASC=0x4b ASCQ=0x0 end_request: I/O error, dev sdf, sector 894959703 EXT3-fs error (device sdf1): ext3_get_inode_loc: unable to read inode block - inode=55935010, block=111869955 sd 7:0:1:0: [sdf] Result: hostbyte=0x00 driverbyte=0x08 sd 7:0:1:0: [sdf] Sense Key : 0x3 [current] sd 7:0:1:0: [sdf] ASC=0x4b ASCQ=0x0 end_request: I/O error, dev sdf, sector 894959703

Listing 7에서 파일 시스템이나 디스크에 결함이 발생했으므로 파일 시스템을 점검해야 한다는 사실을 파악할 수 있다.

Listing 8에서 보듯이, 이 경우는 syslog에도 정보가 기록되었다.

Listing 8. syslog에 기록된 디스크 오류

messages:Feb 3 12:17:53 bear sd 7:0:1:0: [sdf] Result: hostbyte=0x00 driverbyte=0x08 messages:Feb 3 12:17:53 bear sd 7:0:1:0: [sdf] Sense Key : 0x3 [current] messages:Feb 3 12:17:53 bear sd 7:0:1:0: [sdf] ASC=0x4b ASCQ=0x0 messages:Feb 3 12:17:53 bear end_request: I/O error, dev sdf, sector 894959703 messages:Feb 3 12:17:53 bear EXT3-fs error (device sdf1): ext3_get_inode_loc: unable to read inode block - inode=55935014, block=111869955

하지만 심각한 결함이나 실패가 발생한 경우 syslog에 정보가 기록되지 않을 수도 있다. 이 때는 dmesg가 문제를 파악하는 유일한 실마리가 되기도 한다.

위로

사용자 정보(utmp/x, wtmp/x, lastlog)

utmp, wtmp, lastlog 같은 로그 파일은 사용자 로그인 정보와 시스템 정보를 기록한다. 파일에 쓰는 정보는 특별한 utmp 형식이다. 따라서 정보를 읽으려면 특별한 도구가 필요하다.

utmp, wtmp, lastlog 파일은 로그인 시각과 시스템 시작/종료 시각을 기록한다. 로그인 이력을 조사할 때나 최종 부팅 시각 혹은 최종 로그인 시각을 확인할 때 유용하다.

위 로그 파일 내용을 분석하는 방법은 참고자료에 소개한 System Administration Toolkit: Monitoring User Usage 기사를 참고한다.

cron 로그

배경 작업으로 주기적으로 지정된 서비스를 실행하는 cron 데몬 역시 독자적인 로그 정보를 생성한다.

어떤 시스템은 cron 로그를 syslog에 기록하지만, 솔라리스와 전통적인 유닉스 계열에서는 /var/cron/log에 기록한다. 로그 메시지는 실행한 명령, 작업 시작 시각, 작업 종료 시각을 포함한다.

예를 들어, Listing 9는 cron 로그 예제다.

Listing 9. cron 로그 예제

! *** cron started *** pid = 283 Sun Feb 3 16:07:10 2008 > CMD: /usr/local/bin/logmanage >/dev/null 2>&1 > root 946 c Sun Feb 3 17:10:00 2008 < root 946 c Sun Feb 3 17:10:00 2008 > CMD: /usr/local/bin/backup >/dev/null 2>&1 > root 949 c Sun Feb 3 17:11:00 2008 < root 949 c Sun Feb 3 17:11:01 2008

로그 파일에 담긴 정보는 올바로 실행되지 않는 작업을 가려내기에 편리하다. 또한 작업이 실행된 시간, 오래 걸리는 작업, 무한히 실행되는 작업 등을 찾아 잠정적인 문제를 조사하는 과정에서도 유용하다.

위로

로그 파일 관리

시스템 관리자는 로그 파일을 신중하고 효율적으로 관리해야 한다. 자칫하면 로그 파일이 아주 커진다. 또한 문제가 생기면 시스템에서 발생한 과거 이벤트를 뒤져야 한다.

예를 들어, 가짜 리부팅이나 가짜 시스템 종료는 신중하게 조사해야 하는데, 대개 시스템 로그가 유일한 실마리다. 실패가 발생한 시점에서 주변 상황을 정확히 알려주지는 못하지만 정확한 실패 시각, 문제를 일으킨 이벤트 등 유용한 정보가 담겨 있다. 예를 들어, 시스템 로그에서 잠정적인 보안 문제나 수상한 로그인 시도가 발견된다면, 시스템이 공격을 당했다는 뜻일지도 모르고, 이것이 가짜 리부팅이나 가짜 시스템 종료를 일으킨 원인일지도 모를 일이다.

(법적으로 요구되는 특수한 경우를 제외하고는) 로그 정보를 오래오래 간직할 필요는 없다. 활발히 사용되는 시스템이라면 하루에 25MB 정도는 쉽게 저장한다. 덕택에 로그 파일이 디스크 공간 부족 오류를 일으키는 주범이 되기도 한다.

일부 유닉스/리눅스 계열은 자동 로그 관리 프로세스를 제공한다(솔라리스는 /usr/bin/logadm 명령을 기본으로 제공한다). 하지만 직접 만들기도 어렵지 않다. 일반적으로 로그 파일은 짧은 기간 동안(예를 들어, 4주 정도) 저장하며 각 파일은 순차적으로 번호를 매긴다. 예를 들어, messages라는 파일이 있다면 지난 주 파일은 messages.1, 지지난 주 파일은 messages.2로 이름을 매긴다. 그러면 로그 파일 이름을 바꾸기가 매우 쉬워진다.

그러나 파일을 보관하는 과정에서 (파일을 다시 생성할 때) 중요한 정보를 잃지 않도록 주의해야 한다. 오래된 파일은 압축해 공간을 절약해도 좋다. Listing 10은 각 로그 파일을 원래 디렉터리 내 적절한 디렉터리에 복사하여 보관하는 간단한 스크립트다.

Listing 10. 간단한 로그 보관 스크립트

#!/bin/bash # 필요하면 로그 파일과 아카이브를 관리한다. # 로그 파일 네 본을 보관한다. cd /var/log for type in cyrus dmesg emerge.log faillog genkernel.log messages do mkdir -p $type.d cp $type.d/$type.3.bz2 $type.d/$type.4.bz2 cp $type.d/$type.2.bz2 $type.d/$type.3.bz2 cp $type.d/$type.1.bz2 $type.d/$type.2.bz2 cp $type $type.d/$type.1 && cat </dev/null >$type bzip2 -vf9 $type.d/$type.1 done

스크립트는 현재 로그 파일을 복사하고, 다시 생성한 후, 압축한다. 기존 로그 파일은 한 주씩 밀려 올라간다. 그런 다음 현재 로그 파일을 보관한다(즉, 복사하여 다시 생성한 후 압축한다).

위로

요약

로그 파일은 아주 풍부한 정보를 저장한다. 따라서 파일에 담긴 정보와 형식을 이해하면 문제를 진단하고 해결하는 과정이 훨씬 수월해진다. 이 기사에서는 로그 파일 개념을 소개하고, 파일이 저장되는 위치와 파일에 담긴 내용을 살펴보고, 실제로 문제가 발생하기 전에 로그 파일에서 잠정적인 문제를 진단하고 찾아내는 방법을 논의했다. 또한 몇 가지 주요한 로그 파일을 살펴보면서 각 파일이 따르는 형식과 파일에 담긴 내용 사이의 관계를 이해했다.

참고자료

교육

• System Administration Toolkit: Monitoring User Usage(Martin Brown, developerWorks, 2007년 10월): utmp 파일과 wtmp 파일을 통해 사용자와 사용자 활동 정보를 파악하는 방법을 소개한다.
  
  
• System Administration Toolkit: Monitoring Mail Usage(Martin Brown, developerWorks, 2007년 12월): 전자편지와 관련하여 시스템 로그를 살펴보는 방법을 소개한다.
  
  
• System Administration Toolkit: Monitoring Disk Usage(Martin Brown, developerWorks, 2006년 6월): 디스크 사용량을 조사하는 다양한 방법을 소개한다.
  
  
• 시스템 관리 툴킷: 유닉스 명령행 도구 인터페이스 통일하기(Martin Brown, 한국 developerWorks, 2008년 5월): 다양한 UNIX 계열에서 명령을 동일하게 통일하는 방법을 소개한다.
  
  
• System Administration Toolkit: Time and event management(Martin Brown, developerWorks, 2006년 5월): cron과 at을 사용하여 시간 스크립트를 생성하고 관리하는 방법을 소개한다.
  
  
• 예제로 배우는 배쉬 프로그래밍, Part 1: Bourne again shell (bash) 프로그래밍 기초(Daniel Robbins, 한국 developerWorks, 2000년 3월), 예제로 배우는 배쉬 프로그래밍, Part 2: 배쉬 프로그래밍 기초 더 배우기(Daniel Robbins, 한국 developerWorks, 2000년 4월), 예제로 배우는 배쉬 프로그래밍, Part 3: ebuild 시스템(Daniel Robbins, 한국 developerWorks, 2000년 5월): Bash 사용법을 소개하는 기사 연재다.
  
  
• System Administration Toolkit: 이 연재에 속하는 다른 기사를 읽어본다.
  
  
• Making UNIX and Linux work together(Martin Brown, developerWorks, 2006년 4월): 리눅스와 유닉스를 함께 사용하는 방법을 소개한다.
  
  
• 시스템마다 다양한 도구를 사용한다. IBM 레드북 시리즈 중 Solaris to Linux Migration: A Guide for System Administrators는 몇 가지 핵심 도구를 파악하도록 도와줄 것이다.
  
  
• 리눅스 메모리 모델(Vikram Shukla, 한국 developerWorks, 2006년 3월): 리눅스가 메모리, 스왑 영역을 사용하는 방식을 살펴본다.
  
  
• AIX와 UNIX 입문: AIX와 유닉스에 대해 더 많은 지식을 배우자.
  
  
• developerWorks AIX와 유닉스 영역: 다양한 기사, 튜토리얼, 기술 자료를 제공한다.
  
  
• AIX 위키: AIX와 관련한 기술 정보를 공동으로 수집하고 관리하는 공간이다.
  
  
• developerWorks 기술 행사와 웹 캐스트를 놓치지 말자.
  
  
• 기술 온라인 서점: 책과 기타 다른 기술 주제를 다루는 사이트를 살펴보자.
  
  

제품 및 기술 얻기

• syslog-ng: syslog 서비스를 개선하고 확장하여 좀 더 일반적인 범용 로그 메커니즘으로 만든 오픈 소스 유틸리티다.
  
  

토론

• AIX와 유닉스 포럼에 참여하자.
  • AIX 5L 기술 포럼
  • AIX 개발자 포럼
  • 클러스터 시스템 관리
  • IBM 기술 지원
  • 성능 도구 기술
  • 가상화 기술
  • AIX와 유닉스 포럼