您好,欢迎来到思海网络,我们将竭诚为您提供优质的服务! 诚征网络推广 | 网站备案 | 帮助中心 | 软件下载 | 购买流程 | 付款方式 | 联系我们 [ 会员登录/注册 ]
促销推广
客服中心
业务咨询
有事点击这里…  531199185
有事点击这里…  61352289
点击这里给我发消息  81721488
有事点击这里…  376585780
有事点击这里…  872642803
有事点击这里…  459248018
有事点击这里…  61352288
有事点击这里…  380791050
技术支持
有事点击这里…  714236853
有事点击这里…  719304487
有事点击这里…  1208894568
有事点击这里…  61352289
在线客服
有事点击这里…  531199185
有事点击这里…  61352288
有事点击这里…  983054746
有事点击这里…  893984210
当前位置:首页 >> 技术文章 >> 文章浏览
技术文章

Unix/Linux系统自动化管理:日志管理篇

添加时间:2014-1-3 17:49:43  添加: 思海网络 

系统日志Unix/Linux中一个非常重要的功能组成部分。它可以按照某种规范记录下系统所产生的所有行为。我们可以使用系统日志所记录的信息进行系统排错,系统性能优化,或者根据这些信息调整系统的行为。另外,系统日志还可以为系统的安全管理提供重要的信息。

不同的操作系统可能会使用不同的日志方式,如AIX的Error log和Linux的syslog/syslog-ng。本文将分别论述在AIX上对Error log的监控和在Linux上对syslog/syslog-ng的监控。

AIX Error log 简介及其自动化监控机制

大部分的 Unix/Linux 系统都使用 syslog 作为系统日志方式,AIX 也支持 syslog 机制,但是 AIX 操作系统及其主要应用程序相关的日志都使用 Error log 来记录日志,只有少量的应用程序使用 syslog。AIX syslog 和 Linux syslog 的功能以及配置非常类似,在此不再重复论述。

AIX Error log 机制是 AIX 基本系统 (Base Operating System) 的一部分,在缺省安装情况下无需进行任何配置即可使用 AIX Error log 机制。

AIX Error log 机制组件

AIX Error log 机制主要由以下几个部分组成:

  1. 设备文件 /dev/error: 用于接收内核以及应用程序产生的日志信息。
  2. 守护进程 /usr/lib/errdemon:在系统初始化时自动启动,监控内核以及应用程序传递给设备文件 /dev/error 的日志信息,并将日志信息计入日志文件。
  3. 日志文件 /var/adm/ras/errlog:缺省日志文件。日志文件位置可以通过命令 /usr/lib/errdemon – i 进行配置
  4. 辅助程序:除了设备文件、守护进程和日志文件外,AIX Error log 还提供了丰富的辅助程序对 Error log 进行配置、操作、分析和生成报告。在下面的章节中会对各辅助程序进行详细的说明。

AIX Error log 配置

AIX Error log 可以在不进行任何配置的情况下使用而且缺省配置基本上可以满足各种场景的使用需求,但 AIX 仍然提供了配置接口。通过配置接口可以修改设备文件 /dev/error 的缓冲区尺寸、日志文件的位置、日志文件的尺寸限制以及对重复日志的处理等等。AIX Error log 通过命令 /usr/lib/errdemon 进行配置。

  1. 修改 Error log 设备的缓冲区大小

    Error log 设备 /dev/error 为块设备,需要使用缓冲区进行读写。缺省情况下,/dev/error 的缓冲区大小为 8KB,我们可以通过 /usr/lib/errdemon – B 来配置 /dev/error 的缓冲区大小。如果新配置的缓冲区大小大于现有的配置,新配置将会立即生效;如果新配置的缓冲区大小小于现有的配置,则新配置会在 errdemon 重新启动后生效。

  2. 配置日志文件路径

    缺省情况下,AIX Error log 会使用文件 /var/adm/ras/errlog 存储日志信息,使用 /usr/lib/errdemon – i 可以配置 Error log 日志文件的路径。新配置的日志文件路径会立即生效。

  3. 配置日志文件大小限制

    AIX Error log 的日志文件大小是可配置的,配置命令为 /usr/lib/errdemon – s。如果新配置的日志文件大小大于现有的配置,新配置将会立即生效;如果新配置的日志文件大小小于现有的配置,则现有的日志文件将会被备份为 *.log,然后 errdemon 会用新的日志文件大小配置生成一个新的日志文件。

  4. 配置对重复条目的处理

    如果操作系统或者应用程序发生了重复的信息或者错误,在 Error log 中就会造成重复的条目。AIX Error log 对重复的条目会进行相应的处理,如在一定时间内内容相同的条目将会被标记为重复,如果重复的条目数超过了预先设置的阈值,则新的重复的条目将不会再作为重复条目被记入 Error log。是否打开重复条目处理功能的配置参数为 /usr/lib/errdemon – d,重复条目的时间间隔配置参数为 /usr/lib/errdemon – t,最大重复条目数的配置参数为 /usr/lib/errdemon – m。

 

AIX Error log 使用

AIX Error log 机制启动后,操作系统或者应用程序将会通过 AIX Error log 记录所发生的事件或者错误。本节将给出日常使用 AIX Error log 的常用命令及其使用方法。AIX Error log 的使用主要有生成 Error log 报告和删除 Error log 条目。

生成 AIX Error log 报告

AIX 命令 errpt 可以用来生成 Error log 报告,errpt 提供了丰富的参数来指定源数据的范围和报告的格式。如 -d 参数可以用来指定只显示特定的错误种类,-s 和 -e 参数可以指定特定时间范围内的日志条目,-l 参数可以指定之显示特定序号的日志条目,-a 参数可以指定显示日志条目的详细信息。具体 errpt 的用法可参见 errpt 的 manpage。

在此列举 errpt 使用的一个例子并以此例子说明 AIX Error log 条目中各字段的含义。


清单 1. errpt 命令输出示例
				 
 #errpt -a -l 2 
 --------------------------------------------------------- 
 LABEL:          REBOOT_ID 
 IDENTIFIER:     2BFA76F6 

 Date/Time:       Mon Mar  2 21:38:21 2009 
 Sequence Number: 2 
 Machine Id:      00C0DD724C00 
 Node Id:         p6ml4n05 
 Class:           S 
 Type:            TEMP 
 WPAR:            Global 
 Resource Name:   SYSPROC 

 Deion 
 SYSTEM SHUTDOWN BY USER 

 Probable Causes 
 SYSTEM SHUTDOWN 

 Detail Data 
 USER ID 
           0 
 0=SOFT IPL 1=HALT 2=TIME REBOOT 
           0 
 TIME TO REBOOT (FOR TIMED REBOOT ONLY) 
           0 
 # 

其中各主要字段的含义如下:

LABEL:为该事件预先定义的名称

IDENTIFIER:此事件的数字标识

Date/Time:事件发生的日期和时间

Sequence Number:事件序列号

Machine Id:此事件发生的节点处理器识别符

Node Id:此事件发生的节点名称

Class:事件的类别。AIX Error log 目前支持的类别有:

H: 硬件

S:软件

O:Informational 条目

U:无法确定事件的类别

Type:事件的严重程度,AIX Error log 目前支持的事件严重程度有:

PEND:设备或组件即将失效

PERF:设备或组件的性能已经低于可以接受的阈值

PERM:无法修复的错误。PERM 是所有错误中最严重的一种,PERM log 往往说明某个硬件或者软件组件已经失效并且无法修复。

TEMP:在若干次失败后某个错误被成功修复。TEMP 也可以用于标识 informational 条目。

UNKN:无法确定事件的严重程度

INFO:信息而并非错误

Resource Name:产生信息的组件名称

Deion:事件的简短描述

Probable Causes:事件产生的可能原因

删除 AIX Error log

删除 AIX Error log 条目可以使用命令 errclear,errclear 也提供了选项用于指定删除的范围,如 -d 指定仅删除特定类别的事件,-l 指定仅删除特定序号的条目。通常情况下,errclear 可以被用作 cron 条目周期性执行用以清楚 Error log 文件。

手动生成 AIX Error log 条目

命令 errlogger 可以用于手动生成 AIX Error log 条目。手动生成 AIX Error log 条目可以用于测试 AIX Error log 功能或者测试下面将要论述的自动监控功能等。

 

AIX Error log 监控自动化

AIX 操作系统为 Error log 提供了一种通过 ODM 类 errnotify 进行错误通知 (Error Notification) 的机制。用户可以通过添加一个 errnotify 的 ODM 类实例来实现 AIX Error log 的错误通知,即当 AIX Error log 机制记录了错误条目后,errnotify 会调用预先定义好的命令通知系统管理员或者进行其它的修复动作。

AIX Error log 的错误通知机制的功能完全符合了监控自动化的要求,我们可以通过添加一个 errnotify 类实例来实现对 AIX Error log 的监控,当定义的错误发生后,errnotify 会调用相应的命令来通知系统管理员。需要注意的是只有 root 用户才能添加 errnotify 类实例。

以下是添加 errnotify 类实例以及利用 errnotify 机制自动监控 AIX Error log 的具体步骤:

  1. 生成一个 ODM errnotify 类实例的 stanza 文件

    生成一个 ODM errnotify 类实例的 stanza 文件需要指定若干选项,各主要选项的说明如下:

    en_name:errnotify 类实例的名字,名字需要全局唯一。

    en_persistenceflg:在系统重新引导时是否自动删除该实例,0 为在系统重新引导时自动删除该实例,1 为在系统重新引导时不删除该实例。

    en_type:指定仅监控特定严重程度的 Error log 条目如 INFO、PEND 等。

    en_class:指定仅监控特定类别的 Error log 条目如 H、S 等。

    en_method:定义在监测到 AIX Error log 条目后所采取的动作,动作可以为任何的脚本程序或者操作系统命令。errnotify 自动设置了关于 Error log 条目信息的变量可供监控程序使用:

    $1 error log 条目的序号

    $2 error log 条目的 ID

    $3 error log 条目的事件类别

    $4 error log 条目的事件严重程度

    $5 error log 条目的 Alert flags

    $6 error log 条目的产生的组件名称

    $7 error log 条目的产生的组件种类 (Type)

    $8 error log 条目的产生的组件类 (Class)

    $9 error log 条目的错误标签

    关于 errnotify 类实例的各字段的具体说明,请参见 AIX 文档《 General Programming Concepts: Writing and Debugging Programs 》

    例如我们可以生成一个 errnotify 类实例的 stanza 如下:



    清单 2. errnotify 类实例 stanza
    				 
    errnotify: 
       en_name = "errlog_notify"
       en_persistenceflg = 1 
       en_method = "mail -s \"Events occured in Error log: sequence = $1 error_id = $2
       class = $3 type = $4 alert_flags = $5 res_name = $6 res_type = $7 res_class = $8
       label = $9\" root"
    
    

    该 stanza 的内容可解释为当任何的 AIX Error log 事件发生时,都会给 root 用户发送一个邮件,邮件的内容中包含了 Error log 条目的具体信息。

  2. 将类实例添加到 ODM 数据库

    AIX 命令 odmadd 可以将 ODM 类实例添加到 ODM 数据库中。

    如 : odmadd /errnotifystanza

  3. 验证 ODM errnotify 类实例

    可以用命令 odmget 来验证 errnotify 类实例已经被正确添加。



    清单 3. 使用 odmget 命令查看 errnotify 类实例
    				 
    [node01][/]> odmget -q en_name="errlog_notify" errnotify 
    
    errnotify: 
         en_pid = 0 
         en_name = "errlog_notify"
         en_persistenceflg = 1 
         en_label = ""
         en_crcid = 0 
         en_class = ""
         en_type = ""
         en_alertflg = ""
         en_resource = ""
         en_rtype = ""
         en_rclass = ""
         en_symptom = ""
         en_err64 = ""
         en_dup = ""
         en_method = "mail -s \"Events occured in Error log: sequence = $1 error_id = $2
         class = $3 type = $4 alert_flags = $5 res_name = $6 res_type = $7 res_class = $8
         label = $9  contents = \n`errpt -a -l $1\n\" root"
    

 

  • 手动生成 Error log 条目测试监控是否工作

    在确认 errnotify 类实例已经被正确添加后即可以通过 errologger 手动生成 Error log 条目测试监控是否工作。如:



    清单 4. 使用 errlogger 命令生成测试日志
    				 
     errlogger "this is a test for Error log monitoring"
    

    然后即可以查看 root 的邮件中是否已经收到了该 Error log,如果工作正常 root 的邮件中会收到内容如下的邮件:



    清单 5. mail 命令
    				 
    Message 37: 
    From root Fri Mar 20 02:43:15 2009 
    Date: Fri, 20 Mar 2009 02:43:15 -0400 
    From: root 
    To: root 
    Subject: Events occured in Error log: sequence = 142983 error_id = 0xaa8ab241 
    class = O type = TEMP alert_flags = FALSE res_name = OPERATOR res_type = NONE
     res_class = NONE label = OPMSG  contents = 
    
     --------------------------------------------------------------------------- 
     LABEL:          OPMSG 
     IDENTIFIER:     AA8AB241 
    
     Date/Time:       Fri Mar 20 02:43:14 EDT 2009 
     Sequence Number: 142983 
     Machine Id:      000181404C00 
     Node Id:         hacsmdev3 
     Class:           O 
     Type:            TEMP 
     Resource Name:   OPERATOR 
    
     Deion 
     OPERATOR NOTIFICATION 
    
     User Causes 
     ERRLOGGER COMMAND 
    
            Recommended Actions 
            REVIEW DETAILED DATA 
    
     Detail Data 
     MESSAGE FROM ERRLOGGER COMMAND 
     this is a test for Error log monitoring 				
    

  • 停止监控 AIX Error log

    如果想停止通过 errnotify 监控 AIX Error log,只需要将 errnotify 类实例从 ODM 数据库中删除即可。



    清单 6. 删除 errnotify 类实例
    				 
     [node01][/]> odmdelete -q en_name="errlog_notify" -o errnotify 
     1 objects deleted 
    
  •  

     

    Linux syslog/syslog-ng 简介及其自动化监控机制

    大部分的 Linux 系统中都要使用 syslog 机制来记录系统日志,它具有很强的灵活性,能使系统根据不同日志配置采取不同的动作。一般来讲,syslog 能通过产生日志的子系统和信息优先级对日志做分类处理,包括将日志条目写到一个文件,一个设备,或给用户发送一个信息。它既可以记录本地事件,也可能通过网络纪录另一个主机上的事件。

    但是,随着系统中运行的应用程序越来越多,一个子系统有可能同时被多个应用程序使用,这样就导致一些不是很重要的信息将重要的信息掩盖,仅凭产生日志的子系统和信息优先级来区分日志的方法已经不能明确地甄别出系统管理者感兴趣的信息。

    syslog-ng(下一代系统日志工具)应运而生,它的一个设计原则就是建立更好的消息过滤粒度。syslog-ng 可以完全替代 syslog 的服务,并且通过定义规则,实现更好的过滤功能。

    下面我们将分别对 syslog 和 syslog-ng 机制做具体的介绍。

    Linux syslog/syslog-ng 机制组件

    Linux syslog/syslog-ng 机制主要由以下几个部分组成:

    1. 设备文件 /dev/log: 用于接收内核以及应用程序产生的日志信息。
    2. 守护进程:在系统初始化时自动启动,监控内核以及应用程序传递给设备文件 /dev/log 的日志信息,并将日志信息计入日志文件。
    3. 在 syslog 机制中为 /sbin/syslogd;在 syslog-ng 机制中为 /sbin/syslog-ng。
    4. 配置文件:为守护进程提供配置信息,在程序启动时读取,用于指定日志记录规则。

    在 syslog 机制中配置文件的默认位置为 /etc/syslog.conf;在 syslog-ng 机制中为 /etc/syslog-ng/syslog-ng.conf。

    日志文件 /var/log/messages:缺省日志文件。用于记录邮件以外其他设备优先级高于”info”的日志信息。

    Linux syslog/syslog-ng 配置和使用

    Linux 中 syslog/syslog-ng 的配置较 AIX 简单而灵活,用户只需手动修改 syslog.conf/syslog-ng.conf 文件中的配置条目后,重新启动 syslog 服务即可完成,下面我们具体介绍配置方法:

    • 在 syslog 机制中配置文件 /etc/syslog.conf 的规则格式如下:

      facility.level action

      其中 facility.level 又称为选择符 (selector),facility 指产生日志的子系统,level 指日志级别。

      例如:

      authpriv.* /var/log/secure

      表示将来自子系统 authpriv 的所有优先级日志条目都写入 /var/log/secure 文件中。

      facility 可以设置为下面的关键字之一:

      auth 由 pam_pwdb 报告的认证活动。

      authpriv 包括私有信息 ( 如用户名 ) 在内的认证活动

      cron 与 cron 和 at 有关的信息。

      daemon 与 inetd 守护进程有关的信息。

      ftp 与 FTP 有关的信息

      kern 内核信息,首先通过 klogd 传递。

      lpr 与打印服务有关的信息。

      mail 与电子邮件有关的信息

      mark syslog 内部功能用于生成时间戳

      news 来自新闻服务器的信息

      syslog 由 syslog 生成的信息

      user 由用户程序生成的信息

      uucp 由 uucp 生成的信息

      local0 ~ local7 由自定义程序使用,例如使用 local5 做为 ssh 功能

      * 通配符代表除了 mark 以外的所有功能

      level 可以设置为下面的关键字之一 ( 降序排列,严重性越来越低 ):

      emerg 系统不可用

      alert 需要立即被修改的条件

      crit 阻止某些工具或子系统功能实现的错误条件

      err 阻止工具或某些子系统部分功能实现的错误条件

      warning 预警信息

      notice 具有重要性的普通条件

      info 提供信息的消息

      debug 不包含函数条件或问题的其他信息

      none 没有优先级,通常用于排错

      * 除了 none 之外的所有级别

    • 在 syslog-ng 机制中配置文件 /etc/syslog-ng/syslog-ng.conf 的规则格式如下:

      log { source S1; source S2; ... filter F1; filter F2; ... destination D1; destination D2; ... };

      其中 source 为消息源标志符,filter 为过滤器标志符,destination 为目的地标志符。

      例如:

      source src { unix-dgram("/dev/log"); };

      filter f_warn { level(warn, err, crit); };

      destination warn { file("/var/log/warn" fsync(yes)); };

      log { source(src); filter(f_warn); destination(warn); };

      表示将 /dev/log 设备收到的所有日志信息做过滤处理,只把优先级是 warn, err, crit 的日志写入 /var/log/warn 文件中。

      用户可以选择使用系统提供的 source/filter/destination 规则定义,也可以按规定格式定义用户化的配置项。一般情况下,我们只创建自定义的 destination 并结合系统提供的 source 和 filter 一起使用。关于这些配置项的定义方法请参见 syslog-ng.conf manpage。

    Linux syslog-ng 监控自动化

    在 Linux 系统中,缺省情况下,除 iptables, news 和 mail 子系统外,其它所有子系统的日志信息都会存储在 /var/log/messages 文件中。当系统中运行应用程序越来越多,各相关子系产生的日志也会越来越繁杂,从系统日志中分离出对自己有用的信息并对其实现自动监控往往令系统管理员头痛不已。

    syslog-ng 服务就提供了一种消息粒度更小定义更为灵活的日志过滤机机制,用户可以根据不同的需要定义不同的消息源,过滤器和目的地,从而将特定的日志信息存储到特定的位置;同时,系统管理员还可以创建自动化脚本对这些分类后的日志文件做进一步的处理。例如,定时监控系统错误信息并以邮件的方式通知系统管理员。

    下面我们将介绍对特定日志信息中系统错误进行自动监控的具体步骤:

    1. 根据需要定义 filter 和 destination

      前面我们已经讲过 Linux syslog-ng 中 /etc/syslog-ng/syslog-ng.conf 文件对 source,filter 和 destination 的定义规则,在这里假设当前应用程序使用 local6 做网络管理功能,我们需要对来自这一子系统的优先级为 err(错误)的系统消息做监控和管理。

      那么,我们需要在 /etc/syslog-ng/syslog-ng.conf 文件中定义 filter 如下:

      filter f_local6err { level(err) and facility(local6); };

      定义 destination 如下:

      destination local6err { pipe(“/var/log/local6.err” group(root) perm(0644)); };

      表示目的地为队列 /var/log/local6.err,该队列属于 root 组,其访问属性为 0644。

    2. 组建 log 配置条目

      定义了 filter 和 destination 之后,我们需要将它们组合在一起,形成一个 syslog-ng 的 log 配置条目,例如:

      log { source(src); filter(f_ local6err); destination(local6err); };

      然后重新启动 syslog-ng 服务使新配置生效:

      # /etc/init.d/syslog restart

      Shutting down syslog services done

      Starting syslog services done

     

     

    #

    这样,系统中来自 local6 子系统的所有 err 日志都将被存储在 /var/log/local6.err 队列中。这里之所以将日志目的设置为队列而非普通文件主要是为下一步中自动监控做准备。并且,在设置前需要调用命令 “mkfifo /var/log/local6.err”来预告创建好这个队列。

  • 创建脚本对目标队列做自动监控

    为了能将 /var/log/local6.err 队列接收到系统错误及时地通知给系统管理员,我们需要创建一个脚本定期读取 local6.err 队列,一旦监测到有新的系统错误产生,就以 mail 的形式通知系统管理员。

    下面是一个监测队列的自动化脚本的 perl 实例仅供参考。



    清单 7. 监测队列的自动化脚本
    				 
     #  monitor_fifo 
     #!/usr/bin/perl 
    
     # $fifo 为目标队列
     my $fifo = “/var/log/local6.err”; 
    
     # 首先检测 fifo 的有效性
    	 local $SIG{ALRM} = sub { die "alarm\n" }; 
    	 eval { 
    		 alarm 4; 
    		 open(PIPE, $fifo) or die 
            print “Error: $fifo can not be opened.\n”; 
    		 alarm 0; 
    	 }; 
    	 if ($@ =~ /alarm/) { close PIPE; exit 0; } 
    
     # 读取 fifo 
    	 my $allinfo = ""; 
    	 while (1) 
    	 { 
    		 my $line; 
    		 eval { 
    			 alarm 2; 
    			 $line = <PIPE>; 
    			 alarm 0; 
    		 }; 
    		 if ($@ =~ /alarm/) { 
    				 close PIPE; 
                    # 如果读到系统错误日志,邮件通知系统管理员
    		     if ($allinfo) 
    		         { 
    			  my $command = “echo \“$allinfo\” | mail -s \”$fifo\” root”; 
    			  my $rc = system($command); 
                        if ($rc) 
                        { 
                            print “Notification to root failed.\n”; 
    					 } 
    				 } 
    
    				 exit 0; 
    		 } 
    		 $allinfo .= $line; 
    	 } 
    	 close PIPE; 	
    

    不难发现,这个自动化脚本会将目标队列中现存的所有日志以邮件的形式发送给系统 root 用户,如果系统管理员需要连续地定期地对这一目标队列进行自动监控,那么就需要借助 Linux 系统的 crontab 功能,使系统可以定期地调用 monitor_fifo 脚本。

    例如:

    使用 crontab -e 命令编辑 crontab 配置文件,并添加如下条目:

    */1 * * * * /root/monitor_fifo 1>/dev/null 2>/dev/null

    上面的例子表示每一分钟调用一次 monitor_fifo 脚本。

  • 验证配置是否成功

    管理员可以使用 logger 命令产生几条测试日志信息。

    # logger -p local6.err "This is a local6.err test message1."

    # logger -p local6.err "This is a local6.err test message2."

    # logger -p local6.err "This is a local6.err test message3."

    表示产生三条 facility 为 local6,level 为 err 的消息内容为 This is a local6.err test message# 的系统日志。

    如果配置正确,这条消息将会被存放在目标队列 /var/log/local6.err 中。通过系统调用 /root/monitor_fifo 脚本,这条系统错误日志信息会被邮寄给 root 用户,使用 mail 命令即可读取这些邮件。



    清单 8. mail 命令
    				 
     # mail 
     mailx version nail 11.25 7/29/05.  Type ? for help. 
    "/var/mail/root": 1 message 1 new 
     >N  1 root@p6hv8n02.clus Tue Apr 14 03:19   21/808   /var/log/monitor.warn 
     ? 
    
     Message  1: 
     From root@p6hv8n02.clusters.com  Tue Apr 14 03:19:37 2009 
     X-Original-To: root 
     Delivered-To: root@p6hv8n02.clusters.com 
     Date: Tue, 14 Apr 2009 03:19:37 +0000 
     To: root@p6hv8n02.clusters.com 
     Subject: /var/log/monitor.warn 
     User-Agent: nail 11.25 7/29/05 
     MIME-Version: 1.0 
     Content-Type: text/plain; charset=us-ascii 
     Content-Transfer-Encoding: 7bit 
     From: root@p6hv8n02.clusters.com (root) 
    
     Apr 14 03:19:26 p6hv8n02 root: This is a local6.err test message1. 
     Apr 14 03:19:28 p6hv8n02 root: This is a local6.err test message2. 
     Apr 14 03:19:30 p6hv8n02 root: This is a local6.err test message3. 
    

     

    我们可以看出,通过这一配置,系统管理员可以很方便对系统错误进行自动监控。

  • 注意事项

    在 Linux 系统中,一些安全设置会影响到 syslog/syslog-ng 的使用,所以在配置过程中要特别注意否则 syslog/syslog-ng 将不能正常工作。

    在 RedHat 系统中,使用 syslog/syslog-ng 时 SELinux (Security-Enhanced Linux) 服务必须关闭,可参见如下方法:

    • 修改 /etc/selinux/config 文件,设置 SELINUX=permissive。
    • 重启系统使 selinux 设置生效。

    在 SLES10 SP1 及其以上服务级的系统中,为使 syslog/syslog-ng 正常工作,我们需要修改 /etc/apparmor.d/sbin.syslog-ng 文件或者从 AppArmor 列表中删除 syslog 项。下面两个例子分别介绍如何修改 sbin.syslog-ng 文件和从 Apparmor 列表中删除 syslog 项的具体方法:

      • 修改 sbin.syslog-ng 文件,设置 fifo /var/log/local6.err 为读写权限,并重新启动 boot.apparmor 服务。如下:


    清单 9. 修改 apparmor 访问权限
    				 
     # cat /etc/apparmor.d/sbin.syslog-ng 
     #include <tunables/global> 
     /sbin/syslog-ng { 
     #include <abstractions/base> 
     . 
     . 
     . 
     /var/run/syslog-ng.pid w, 
     /var/log/local6.err wr, 
     } 
    
     # /etc/init.d/boot.apparmor restart 
    

      • 从 AppArmor 列表中删除 syslog 项,并重新启动 boot.apparmor 服务。如下:

    #rm -f /etc/apparmor.d/sbin.syslogd

    #rm -f /etc/apparmor.d/sbin.syslog-ng

    # /etc/init.d/boot.apparmor restart

  • 取消配置

    Linux syslog/syslog-ng 的取消配置操作相对简单,只需要手动编辑 /etc/syslog.conf 或 /etc/syslog-ng/syslog-ng.conf 文件,删除相关的配置信息,然后重新启动 syslog 服务即可。

    在这个例子中,除取消 syslog/syslog-ng 配置外,我们还需要清除 crontab 中的配置信息。

      小结

      本文介绍了 AIX 和 Linux 上的日志方式 AIX Error log 和 Linux syslog 以及如何自动化监控 AIX Error log 和 Linux syslog。监控系统日志会给系统管理员提供丰富的关于系统运行的信息,自动化监控的实现更能为系统管理员在系统发生异常时采取迅速的措施提供了方便

    1. 关键字:Linux、系统、应用程序

    2. 分享到:

      顶部 】 【 关闭
      版权所有:佛山思海电脑网络有限公司 ©1998-2024 All Rights Reserved.
      联系电话:(0757)22630313、22633833
      中华人民共和国增值电信业务经营许可证: 粤B1.B2-20030321 备案号:粤B2-20030321-1
      网站公安备案编号:44060602000007 交互式栏目专项备案编号:200303DD003  
      察察 工商 网安 举报有奖  警警  手机打开网站