系统管理员工具包: 日志文件基础知识_VMware, Unix及操作系统讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  VMware, Unix及操作系统讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 4249 | 回复: 0   主题: 系统管理员工具包: 日志文件基础知识        下一篇 
cc
注册用户
等级:中校
经验:1900
发帖:195
精华:0
注册:2011-7-25
状态:离线
发送短消息息给cc 加好友    发送短消息息给cc 发消息
发表于: IP:您无权察看 2011-8-19 13:00:48 | [全部帖] [楼主帖] 楼主

关于本系列

典型的 UNIX 管理员拥有一套经常用于辅助管理过程的关键实用工具、诀窍和系统。有一些重要的实用程序、命令行以及脚本可用来简化各种处理过程。其中一些工具来自于操作系统,而大部分的诀窍则来源于长期的经验积累和减轻系统管理员工作压力的要求。本系列文章主要专注于最大限度地利用各种 UNIX 环境中可用的工具,包括简化异构环境中的管理任务的方法。



日志文件

所有系统都会生成不同数量的日志文件,这些文件用于跟踪和记录关于计算机的不同信息。这些文件的内容和效用因系统而异,但是文件提供的核心信息通常是一致的。

例如,所有的 UNIX 和 Linux 计算机都使用 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 上,邮件调试项在缺省情况下写入 /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 的变体,一些日志在其他地方可能比较杂乱,但是,已对标准化文件位置进行了一些有意义的尝试,使日志文件都归入前文已经提及的目录之一。



日志类型和数据

日志类型共分为两种:文本日志文件(包含简单的文本格式的消息和信息)和用二进制格式编码的文件。前者用于典型系统中的大多数日志,因为它们易于编写,而且(也许是更重要的)它们易于阅读。文本文件的不足之处是有时难以通过结构化方式提取信息,因为文件的文本格式允许使用任何方式或结构编写信息。

后者的格式对于非常结构化的信息或需要以特定方式或格式编写的信息更为实用。例如,以二进制数据的固定块的形式将 utmp 和 wtmp 数据写入文件,这样可以用快速有效的格式读取和写入信息。遗憾的是,这意味着如果不使用特定的工具将难以读取信息。

系统日志 (syslog)

syslog 服务是在后台运行的守护进程,可接受日志输入并将其写入到一个或多个单独文件。报告给 syslog 的所有消息都标有日期、时间和主机名,并且可以让单个主机从许多主机接受所有日志消息,并将信息写入单个文件。

提出问题的服务(例如,邮件、dhcp 和内核)和指示消息严重性的类也可以标识消息。可以将严重性标记为信息

(纯信息)、

警告、错误、重要

(需要解决的严重问题)甚至

紧急

(系统需要紧急帮助)。

服务非常容易配置(通常通过 /etc/syslog.conf 或等效项进行配置),并允许您选择要记录的信息类和记录信息的位置。例如,您可以将所有的标准信息写入文件。但是,对于重要消息,如果管理员立刻需要相关信息,则可以立即将这些消息发送到控制台。清单 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 通常还用于记录电子邮件消息传递、文件系统问题,甚至 DHCP 租期、DNS 问题和 NFS 问题。因为 syslog 可以将数据写入不同的区域,所以 syslog 在写入信息时并不总是十分明显。

在磁盘上复制 syslog 的主要目的地与在 UNIX 变体之间不同。许多 Linux 版本将信息写入 /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


在示例输出中可以看到大量的信息,范围从硬件设备中的问题一直到邮件服务的当前配置中的问题。

文件的格式非常简单:它包含日期、主机名、服务名称、唯一 ID(使系统记录多行消息并标识它们)和条目的标识符和类。每行上的其余文本只是系统记录错误消息的自由格式文本。

文件的该格式使提取所需信息变得更加方便。文件中的所有行都是使用唯一 ID 标记的,并且所有的行都标有错误消息的标识符和类。

例如,您可以使用邮件系统提取关键问题的信息,方法是使用 grep 挑选使用 mail.crit 标记的项: $ grep mail.crit /var/adm/messages.

处理日志中个别行的详细信息比较复杂。尽管文件的前几列是标准化的(它们由 syslog 守护进程写入),但是,行的其余格式完全依赖于报告错误消息的组件。

它使阅读和分析文件的内容变得非常复杂,因为您需要根据标识符和报告工具来处理每行。更有甚者,有些行不符合某个格式。

内核日志(dmesg 和 alog)

所有 UNIX 和 Linux 系统的日志实际上是内核的一部分。日志实际上是内核中内存的一部分,用于记录无法写入磁盘的有关内核的信息,这是因为该信息是加载文件系统之前生成的。

例如,在启动过程中,不能以写入方式访问文件系统(大多数内核以读取模式启动文件系统,直到认为系统足够安全,能够切换到读/写模式为止)。此日志中的数据包含关于连接到系统的设备的信息,以及在启动和操作过程中系统记录的任何错误和问题的信息。

在一些系统上,信息会定期写入文件 (/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 格式编写的,所以您需要特殊的工具才能提取该信息。

这些日志中的数据记录登录次数和系统启动/关闭次数,即登录的历史记录和对登录过程中使用的上一次启动或登录时间的快速访问。

有关系统管理工具包中包含的介绍如何分析这些文件的其他文章,请参阅参考资料

cron 日志

cron 时间守护进程负责定期在后台运行许多服务,并生成自已的信息日志。

在某些系统上,cron 日志是使用 syslog 记录的,而在 Solaris 和一些传统 UNIX 变体上,信息则写入文件 /var/cron/log。日志中包含的信息包括所执行命令的详细信息和作业开始和终止的时间。

有关日志内容的示例,请参见清单 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 变体包括自动化日志管理进程(Solaris 包括 /usr/sbin/logadm 命令),但是创建自已的日志管理经常并不困难。典型的功能就是短期(例如四周)内保留个别日志,并按顺序对它们编号。例如,如果您具有文件消息,上一周的文件位于 messages.1,则两周前的文件位于 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


运行脚本副本可重新创建和存档日志文件。请注意如何迁移文件;对于每种情况,我们仅将当前文件移动到一周前。最后,我们将存档并重新创建原始文件。



总结

从 AIX 创建新的 AD 用户和组

日志文件可能包含大量的信息,但是深入了解文件的信息和格式对诊断和解决问题非常有帮助。本文介绍了日志文件的基础知识、并介绍了日志文件位置和这些文件内容的详细信息,以及它们如何帮助您诊断问题并在成为问题之前识别问题。本文还介绍了不同文件的格式,以及不同文件和它们的内容之间的关系。




赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论