レベル: 中級 Martin Brown (mc@mcslp.com), Professional Writer, Freelance
2008年 2月 26日 典型的な UNIX® マシンあるいは Linux® マシンは動作中に数多くのログ・ファイルを作成します。これらのログ・ファイルには有用な情報が含まれているものもあれば、容量やリソースの計画を作成する際に役立てられるものもあります。この記事では、さまざまなログ・ファイルの中に記録されている基本的な情報や、ログ・ファイルの場所について調べ、またシステム内で起きている問題を解決するためにそうした情報を利用する方法について学びます。
このシリーズについて
典型的な UNIX 管理者は、管理プロセスを補助する上で欠かせない、ユーティリティーや特殊な手法、そしてシステムをいくつも定常的に使用しています。これらはさまざまなプロセスを単純化するために使われる重要なユーティリティーであり、コマンドラインのチェーンであり、そしてスクリプトです。こうしたツールの一部はオペレーティング・システムに付属しているものですが、特殊な手法の大部分は、システム管理者としての長年の経験と、作業を楽にしたいという欲求から生まれてきています。このシリーズでは、異機種混合環境での管理を単純化するための方法を含めて、さまざまに異なる UNIX 環境で利用可能なツールを最大限に活用するための方法に焦点を絞って説明します。
ログ・ファイル
すべてのシステムは、マシンに関するさまざまな情報を追跡、記録する、さまざまな量のログ・ファイルを生成します。これらのファイルの内容と使い道はシステムごとに異なりますが、多くの場合、これらのファイルが提供するコアとなる情報は一貫しています。
例えば、すべての UNIX マシンと Linux マシンは syslog を使います。syslog は、オペレーティング・システムやアプリケーション、サービスが情報をログとして記録するために使用する汎用のロギング・システムです。syslog は、さまざまなハードウェアやシステムからレポートされるログイン情報やパフォーマンス情報、そして障害情報などを含んだ大量のデータを記録します。システムには、syslog 以外にも、マシンとそのマシンの動作についての情報を記録する、(サービス、環境、アプリケーションに関する) さまざまな種類のログがあります。
情報を探すためにログ・ファイルの内容を解析し、抽出する作業は時間がかかり、複雑な作業になることもありますが、これらのログに含まれている豊富な情報を無視することはできません。ログ・ファイルは、潜在的な問題や、障害、セキュリティーの欠陥に関する手掛かりを提供してくれるため、ログ・ファイルを適切に使用して、サーバーの負荷や容量に関する警告を提供するために役立てることもできます。
ログの場所
さまざまなログ・ファイルの場所はシステムごとに異なります。ほとんどの UNIX システムと Linux システムでは、ログの大半は /var/log に置かれています。リスト 1 は Gentoo Linux システムの中にあるログ・ファイルのリストを示しています。
リスト 1. Linux の /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 ディレクトリーの中のファイルに書き込まれます (リスト 2)。
リスト 2. 従来の UNIX の /var/adm の内容
$ 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
|
また、システム・レベルではないメッセージや情報の一部は、/var/log の中に置かれているログ・ファイルに書き込まれます (リスト 3)。例えば Solaris では、デフォルトで、メールの debug レベルのログは /var/log/syslog に書き込まれます。
リスト 3. Solaris の /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
|
もちろん、ファイルを見つけることは、ログ・ファイルを利用するにあたって必要なことのほんの一部であり、重要なことは、これらのファイルがどんな情報を含んでおり、それが何に役立つのかを知ることです。
UNIX のバリエーションによっては、一部のログは他の場所に分散して置かれているかもしれません。しかしこれまで、先に触れたディレクトリーのうちの 1 つにログ・ファイルの場所を標準化しようという、大きな努力がなされてきています。
ログのタイプとデータ
ログのタイプは 2 つのカテゴリーに分かれます。つまり単純なテキスト・フォーマットでメッセージや情報を含むテキスト・ログ・ファイルと、バイナリー・フォーマットにエンコードされたファイルという 2 つです。テキスト・ファイルは書き込みが容易であり、そしておそらくもっと重要なこととして、読み取りが容易なため、典型的なシステムでのログ･ファイルのほとんどに使われます。テキスト・ファイルの問題点は、どのような形式や構造でも情報を書き込めてしまうフォーマットであるため、構造を持った形式で情報を抽出しにくい場合があることです。
バイナリー・フォーマットは、非常に構造化された情報や、あるいは特定の方法やフォーマットで書き込む必要のある情報に、より適しています。例えば utmp データと wtmp データをファイルに書き込む際には、バイナリー・データの固定ブロックに書き込むことで、簡単で効率的なフォーマットで情報を読み書きできるようにします。これは残念ながら、特別なツールを使わない限り情報を読むことは困難であるということを意味しています。
システム・ログ (syslog)
syslog サービスは、バックグラウンドで実行してログ・エントリーを受け付け、それらを 1 つあるいは複数のファイルに書き出すデーモンです。syslog にレポートされるすべてのメッセージは日付、時刻、ホスト名でタグ付けされます。また何台ものホストからのログ・メッセージをすべて 1 台のホストで受け付け、その情報を 1 つのファイルに書き出すこともできます。
またメッセージを、問題が起こっているサービス (例えば mail や dhcp、カーネルなど) によって、またメッセージの重大度を示すクラスによって識別することもできます。重大度の種別としては、info (単なる情報)、warning、error、critical (対応が必要な深刻な問題)、さらには emergency (システムに緊急の対処が必要) などがあります。
サービスの構成は (通常は /etc/syslog.conf やこれに等価なものを使うことで) 非常に柔軟に行うことができ、どのレベルの情報をどこにログとして記録するのかを選択することができます。例えば、標準的な情報はすべて 1 つのファイルに書き出すようにすることができます。一方で、管理者が即座に情報を必要とする重要なメッセージは、すぐにコンソールに送信されます。リスト 4 は Solaris 10 システムにおける、デフォルトの syslog.conf ファイルの主な構成内容を示しています。
リスト 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 は UNIX/Linux での標準的なロギング機構であるため、膨大な種類の情報を記録するために使われます。こうした情報の中に含まれるものには、ブート・メッセージや、ログインや権限の情報、そしてサービスの起動や終了などがあります。また syslog は、E メール・メッセージの送信情報やファイルシステムの問題、さらには DHCP リースや DNS、NFS の問題を記録するためにもよく使われます。syslog はさまざまな領域にデータを書き込むことができるため、syslog が情報を書き込んでいることが必ずしも明確にわかるとは限りません。
syslog がディスク上のどこに書き込まれるかは、UNIX のバリエーションによって異なります。多くの Linux ソリューションでは、syslog の情報を /var/log/messages に書き込みます。AIX、Solaris、HP-UX では、syslog は /var/adm/messages に書き込まれます。
リスト 5 は Solaris マシンの /var/adm/messages の例です。
リスト 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, g
ot 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
|
このサンプル出力を見ると、ここにはハードウェア機器の問題からメール・サービスの現在の構成に関する問題に至るまで、非常に広範な情報があることがわかります。
syslog ファイルのフォーマットは非常に単純です。このファイルに含まれているものは、日付、ホスト名、サービス名、固有の ID ( ID によってシステムは複数行にまたがるメッセージを記録することができ、またそれらのメッセージが識別できるようになります)、そしてエントリーの ID とクラスです。各行の中の、それ以外のテキストは、エラー・メッセージを記録するシステムによるフリーフォームのテキストです。
こういうフォーマットをしているおかげで、syslog ファイルから必要な情報を抽出するのは簡単です。ファイルの中のすべての行は固有の ID でタグ付けされており、またすべての行はエラー・メッセージの ID とクラスでタグ付けされています。
例えばメール・システムでの重要な問題に関する情報であれば、mail.crit でタグ付けされたエントリーを grep を使って抽出することができます ($ grep mail.crit /var/adm/messages)。
ログの中にある個々の行の詳細を処理しようとすると、もう少し複雑になります。このファイルの最初の何列かは (syslog デーモンによって作成されるので) 標準化されていますが、行の中の残り部分のフォーマットは、エラー・メッセージをレポートするコンポーネントに完全に依存しています。
そのため、ID とレポート・コンポーネントとに従って各行を扱う必要があり、ファイル内容の読み取りや構文解析は複雑になります。ID とレポート・コンポーネントに従う場合であっても、一部の行がフォーマットに従っていないこともあります。
カーネル・ログ (dmesg と alog)
すべての UNIX システムと Linux システムには、実際にはカーネルの一部となっているログがあります。このログは実際にはカーネルのメモリーの 1 つのセクションであり、カーネルに関する情報を記録するために使われますが、この情報は (ファイルシステムがロードされる前に生成されるため) ディスクには書き込めない可能性があります。
例えば、ブート・プロセスの間はファイルシステムにアクセスして書き込むことはできません (大部分のカーネルは、システムを読み書きモードに切り替えても十分安全と見なせるまで、ファイルシステムを読み取りモードにしてブートします)。このカーネルの一部となっているログのデータには、システムに接続されている機器に関する情報と、ブート・プロセスやオペレーション・プロセス中にシステムが記録した、すべての障害や問題に関する情報が含まれています。
一部のシステムでは、こうした情報が定期的にファイル (/var/log/dmesg) の中にダンプされます。また他のシステムでは、alog コマンド (AIX) あるいは dmesg (他のすべての UNIX/Linux のバリエーション) を使わないと、そうした情報を利用することができません。
カーネルが生成する情報は、必ずしも syslog などの別ファイルに書き出されるとは限りません。これはつまり、一部の情報 (例えば機器やハードウェアの内部データなど) は dmesg ログからしか得られないということです。
例えば、リスト 6 は Gentoo Linux システムの dmesg の出力の一例を示しています。ここではメインのブート情報を示してあります (簡潔にするために一部を省略してあります)。
リスト 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
...
|
リスト 7 は Gentoo Linux を実行する別のマシンからの出力を示しています。この例を見ると、実行中のファイルシステムがいくつかの障害をレポートしていることがわかります。
リスト 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
|
リスト 7 を見ると、ファイルシステムまたはディスクに障害があるようなので、おそらくファイルシステムをチェックする必要がある、ということがわかります。
この例では、情報は syslog にもレポートされていました (リスト 8)。
リスト 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
|
しかし深刻な障害や故障の場合には、システム上で何が起きているのかを知るための有効な情報源は dmesg のみ、ということもあります。
ユーザーに関する記録 (utmp/x、wtmp/x、lastlog)
これらのファイルには、ユーザーのログインに関するログと、システム・データのログが含まれています。これらのファイルの中の情報は特別な utmp フォーマットで書き込まれるため、この情報を抽出するためには特別なツールが必要です。
これらのログの中に記録されているデータには、ログイン時刻やシステムの起動および終了時刻が記録されています。どちらのデータも、目的は、ログインに関する履歴を記録し、また最後のブート時刻やログインしていた期間を迅速に得られるようにするためです。
「参考文献」には、これらのファイルを構文解析する方法を説明した「システム管理ツールキット (System Administration Toolkit)」シリーズの別の記事を紹介してありますので、その記事を参照してください。
cron のログ
cron の時刻デーモンは数多くのサービスをバックグラウンドで一定周期ごとに実行しますが、独自の情報ログも生成します。システムには、syslog を使って cron のログを記録するものもあれば、Solaris や従来の UNIX の一部のバリエーションのように、/var/cron/log ファイルに cron のログ情報を書き込むものもあります。このログに含まれる情報には、実行されたコマンドの詳細や、ジョブがいつ起動および停止したかの詳細が含まれています。
このログの内容の一例として、リスト 9 を見てください。
リスト 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 を超えることも珍しくありません。またログがディスクの容量不足エラーの原因になることもよくあります。
UNIX/Linux バリエーションには自動的なログ管理プロセスが含まれているものもあります (Soraris には /usr/sbin/logadm コマンドがあります)。しかし独自のログ管理プロセスを作成することも、それほど難しくはありません。典型的な作成方法としては、個々のログを短期間 (例えば 4 週間) 保持し、それらに順番に番号を付けます。例えば messages というファイルであれば、先週のファイルは messages.1、2 週間前のファイルは messages.2、というようにします。これによってファイルのマイグレーションが非常に容易になります。
ただし、マイグレーションやアーカイブのプロセスの間に大量の情報を失うことなく、適切にファイルをコピーでき、再作成できるように注意する必要があります。古いファイルの場合には、スペースを節約するためにファイルの内容をアーカイブすることもできます。リスト 10 は、元々の場所の中にある適切な名前のディレクトリーに個々のファイルをコピーしてアーカイブする、簡単なスクリプトを示しています。
リスト 10. ログをアーカイブするための簡単な機能
#!/bin/bash
# Manage logs and archive them if necessary
# Keeps 4 copies of logs
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
|
このスクリプトを実行すると、ログ・ファイルがコピーされ、再作成され、そしてアーカイブされます。ファイルをマイグレートする方法に注目してください。ここでは、現在存在しているログ・ファイルを移動して、それぞれのファイルをさらに 1 週間前のログ・ファイルとしています。そして最後に、元のファイルをアーカイブして再作成しています。
まとめ
ログ・ファイルは非常に豊富な情報を含んでいる可能性がありますが、そうした情報の深さやファイルのフォーマットを理解できると、問題を診断、解決しようとする際に非常に役立ちます。この記事では、ログ・ファイルの基本やログ・ファイルが保存される場所、そしてこれらのファイルの内容の詳細について学びました。またログ・ファイルが、問題が実際に起きる前に問題を診断したり発見したりする上でいかに役立つのかを学びました。さらにこの記事では、さまざまなファイルのフォーマットと、さまざまなファイルとその内容との間の関係についても検証しました。
参考文献 学ぶために
製品や技術を入手するために
-
syslog-ng は syslog サービスのオープン・ソース実装であり、syslog を汎用のログ機構にするための改善や機能強化が含まれています。
議論するために
- AIX と UNIX のための下記のフォーラムに参加してください。
著者について  | | | Martin Brown は 7 年以上プロのライターとして活躍してきました。彼はさまざまな話題に関して数多くの本や記事を執筆しています。専門領域は広く、無数の開発言語やプラットフォーム (Perl、Python、Java™、JavaScript、Basic、Pascal、Modula-2、C、C++、Rebol、Gawk、Shellscript、Windows®、Solaris、Linux、BeOS、Mac OS/X その他) から、Web プログラミング、システム管理やシステム統合にまでわたります。彼は Microsoft®の SME (Subject Matter Expert) であり、ServerWatch.com と LinuxToday.com、そして IBM developerWorks に頻繁に寄稿しており、また Computerworld や The Apple Blog、その他のサイトにもブロガーとして頻繁に寄稿しています。彼の Web サイトを通じて彼に連絡を取ることができます。 |
記事の評価
| 
