日志系统将我们系统运行的每一个状况信息都使用文字记录下来，这些信息有助我们观察系统运行过程中正常状态和系统运行错误时快速定位错误位置的途径等；下面主要概述一下linux操作系统中的日志功能
每个操作系统中都有自己的强大的日志功能，windows有，而linux同样也有；linux操作系统中的日志功能主要通过服务syslog来实现(redhat6.0以后使用的是syslog-ng)，而syslog服务下有两个进程syslogd和klogd，这两个进程一个用来记录系统日志信息，一个用来记录内核日志信息；但是操作系统在运行中会产生非常多的日志信息，如果我们将这些信息都记录下来的话，那我们的磁盘I/O一定很繁忙，这对系统的性能有很大的影响，这就有违了我们的初衷，所以我们根据产生日志的来源和日志信息的重要性，将系统运行中所产生的日志进行分类；syslogd和klogd两个进程所记录的日志信息和详细程度又各有不同：
Klogd：记录了系统初始化时所产生并显示在物理终端上的信息，并保存在”/var/log/dmesg”文件中，我们可以使用“cat /var/log/dmesg”进行查看，也可以使用专门的命令“dmesg”进行查看
Syslogd：在系统初始化完成，将系统控制权转交给init，此时产生的日志信息都有syslogd记录，并存放在“/var/log/messages”文件中，主要保存的信息有“系统标准错误日志信息，非内核产生的引导信息，各个服务程序的子系统产生的信息等等”；在监控系统运行时一般使用“# tail -f /var/log/messages”来监控新生成的日志信息
但是系统运行中所产生的信息非常多，即使只记录这些信息，也有很大量；此时如果我们仍然将所有日志信息都保存在一个messages文件中，那么管理起来就非常困难了；那这怎么办呢？我们引进了另外一种技术“日志滚动”
日志滚动：当日志messages文件大小或时间到一定程度之后，将这个文件定义为messages.1，并重新创建一个新的messages文件，此时messages.1不再记录新的内容，只是存放以前的内容，如果新的messages文件再次达到这个标准之后，现在这个messages文件重命名为messages.1，原有的messages.1命名为messages.2，这样依次类推；但是这样一直滚动下去，很久以前的日志信息对我们现在管理已经没有很大用处了，所以我们可以定义只保留滚动多少次的日志文件；所以日志信息我们应该经常滚动，且一般定义多个标准
日志的滚动就是将这个日志文件进行切割，在redhat上有一个专门的命令可以完成这个动作：logrotate；系统上有一个专门的系统任务计划来完成日志切割“/etc/cron.daily”下有一个脚本叫做logrotate，这个命令的配置文件在“etc/logrotate.conf”下(定义了系统的日志滚动机制)
内容格式是：
weekly #全局定义每周滚动一次
rotate 4 #只保留四个滚动版本
include /etc/logrotate.d #上面几行是日志系统全局属性，下面是各个小系统的具体属性，执行时以局部属性为准；局部日志属性可定义多个
/var/log/wtmp { #定义这个子系统自己的日志滚动机制，日志存放文件
monthly #多长时间滚动一个
minsize 1M #日志文件最小1M
create 0664 root utmp #创建一个文件，权限是0664，属主是root，文件名是utmp
rotate 1 #只保留一个滚动版本
}
日志滚动的脚本文件：# vim /etc/cron.daily/logrotate
如果不自己定义，则按照全局定义的日志滚动属性，也可以在“/etc/logrotate.d/cups”文件下定义：
一些其他子系统产生的日志信息保存位置：
/var/maillog #邮件系统产生的日志信息
/var/log/secure #每个用户在登录时所产生的安全信息(什么时间谁以哪个用户来自哪个主机尝试登录，尝试了几次，这个文件经常查看)
syslog的配置文件在：/etc/syslog.conf
这个配置文件格式是：每一行都定义一个子系统产生的哪些级别的日志记录到什么位置
facility.priority action
Facility：日志来源
auth #认证子系统产生的
authpriv #权限授权子系统产生的
cron #任务计划子系统产生的
daemon #守护进程子系统产生的
kern #内核子系统产生的,定义klogd的记录内容
lpr #打印子系统产生的
mail #邮件子系统产生的
mark #标记子系统产生的
news #新闻子系统产生的
security #安全子系统产生的，与auth来源类似
syslog #定义syslog自己的要记录的
user #用户子系统所产生的的
uucp #Unix to unix cp子系统所产生的
local0-->local7 #用户自定义使用
* #所有来源
Priority(log level)日志级别：(级别越低记录的越详细)
debug #程序或系统的调试信息(记录非常详细，一般只在系统无法启动，排除错误时使用)
info #一般信息
notice #不影响系统正常功能，但需要注意的信息
warning/warn #可能影响系统功能，需要提醒用户注意的重要事件；这种信息可能会引起部分功能的运行
err/error #错误信息，已经影响系统部分功能；蓝色警报
crit #比较严重的信息；橙色警报
alert #必须马上处理的信息；红色警报
emerg/panic #导致系统不可用的信息；一般这一刻出现，下一刻系统就会down掉
* #所有日志级别，类似debug
none #和*相反，表示哪个级别都没有
Action(动作)指定日志记录的位置：
系统上的绝对路径 #普通文件，如/var/log/***
| #通过管道送给其他命令处理
终端 #显示在哪个终端(物理终端，虚拟终端，伪终端等等)
@HOST #远程主机；产生的日志信息，自己不记录，而传送给其他主机记录，一般用于日志服务器，可以增强当前服务器的安全；默认情况下只为自己记录日志信息
【如果要使得我们的服务器称为日志服务器，只需在“/etc/sysconfig/syslog”文件中的"SYSLOGD_OPTIONS="-r -m 0""这一行中添加一个“-r”选项，重新启动服务即可开启日志服务器功能】
用户 #产生的日志信息都发送给某个用户，如root
* #登录到系统上的所有用户，一般emerg级别的日志是这样定义的
syslog日志服务属性定义实例：
mail.info /var/log/maillog #将mail相关的级别为info及info以上级别的信息记录到/var/log/maillog文件中
auth.=info @10.0.0.1 #将auth相关的info级别的信息记录到10.0.0.1主机上，前提是10.0.0.1主机能够接收到其他主机发来的日志信息(此时只记录info级别)
user.!=error #记录与user相关的，但不记录error级别的信息，只记录其他所有级别
user.!error #与user.error相反，此时只记录比error级别低的日志信息
*.info #记录所有可能产生日志子系统的info级别及其以上级别的日志信息
mail.* #记录与mail所产生的所有级别的日志信息
*.* #记录所有日志信息
cron.info;mail.info #记录cron相关的info及以上级别的日志信息和mail相关的info和以上级别的日志信息，多个日志来源之间以“;”分号隔开
cron,mail.info #和上边是一个意思，如果两个日志来源的记录级别相同，可以缩写，来源之间以“,”逗号隔开
mail.*;mail.!=info #记录与mail相关的所有级别的日志信息，但不包括info级别的所有信息
Syslog的默认配置文件定义解释：
# cat /etc/syslog.conf
*.info;mail.none;authpriv.none;cron.none /var/log/messages #所有可能产生日志信息的子系统的info级别及以上级别的日志信息，都保存在messages文件中，但是不包括mail，authpriv，cron子系统的
authpriv.* /var/log/secure #所有用户授权的日志信息都记录到secure文件中
mail.* -/var/log/maillog #所有邮件子系统产生的日志信息都异步保存在maillog文件中，“-”表示异步写入，其他日志信息都要同步写入
cron.* /var/log/cron #所有任务计划的日志信息都记录到cron文件中
*.emerg * #无论系统上哪个程序产生emerg级别的信息，都立即通知给系统上的所有用户，马上就要down机了
uucp,new.crit /var/log/spooler #来自uucp和new子系统的crit级别的信息都保存在spooler文件中
local7.* /var/log/boot.log #自己定义的日志记录，此处系统默认定义的是系统引导信息，保存在boot.log文件中；但此处并没有定义谁向这个文件中填写，所以这个文件是空文件，我们需要在其他文件中定义这个日志信息要发送到local7中，才会写到boot.log文件中，一般意义不大
这个文件保存之后日志系统配置文件并不会立即生效，此时如果我们使用“service syslog restart”命令来重启日志服务，可能会使得其他一些正在记录日志信息的子系统不能完整的记录，所以我们一般使用“service syslog reload”来重读配置文件，并生效，相当与发送1号信号