syslog架构
Unix/Linux系统中的大部分日志都是通过一种叫做syslog的机制产生和维护的。syslog是一种标准的协议，分为客户端和服务器端，客户端是产生日志消息的一方，而服务器端负责接收客户端发送来的日志消息，并做出保存到特定的日志文件中或者其他方式的处理。
在Linux中，常见的syslog服务器端程序是syslogd守护程序。这个程序可以从三个地方接收日志消息：（1）Unix域套接字 /dev/log；（2）UDP端口514；（3）特殊的设备/dev/klog（读取内核发出的消息）。相应地，产生日志消息的程序就需要通过上述三种方式写入消息，对于大多数程序而言就是向/dev/log这个套接字发送日志消息。
关于syslog的协议
介绍
在Unix类操作系统上，syslog广泛应用于系统日志。syslog日志消息既可以记录在本地文件中，也可以通过网络发送到接收syslog的服务器。接收syslog的服务器可以对多个设备的syslog消息进行统一的存储，或者解析其中的内容做相应的处理。常见的应用场景是网络管理工具、安全管理系统、日志审计系统。
完整的syslog日志中包含产生日志的程序模块（Facility）、严重性（Severity或 Level）、时间、主机名或IP、进程名、进程ID和正文。在Unix类操作系统上，能够按Facility和Severity的组合来决定什么样的日志消息是否需要记录，记录到什么地方，是否需要发送到一个接收syslog的服务器等。由于syslog简单而灵活的特性，syslog不再仅限于 Unix类主机的日志记录，任何需要记录和发送日志的场景，都可能会使用syslog。
长期以来，没有一个标准来规范syslog的格式，导致syslog的格式是非常随意的。最坏的情况下，根本就没有任何格式，导致程序不能对syslog 消息进行解析，只能将它看作是一个字符串。
在2001年定义的RFC3164中，描述了BSD syslog协议：
http://www.ietf.org/rfc/rfc3164.txt
不过这个规范的很多内容都不是强制性的，常常是“建议”或者“约定”，也由于这个规范出的比较晚，很多设备并不遵守或不完全遵守这个规范。接下来就介绍一 下这个规范。
约定发送syslog的设备为Device，转发syslog的设备为Relay，接收syslog的设备为Collector。Relay本身也可以发送自身的syslog给Collector，这个时候它表现为一个Device。Relay也可以只转发部分接收到的syslog消息，这个时候它同时表现为Relay和Collector。
syslog消息发送到Collector的UDP 514端口，不需要接收方应答，RFC3164建议 Device 也使用514作为源端口。规定syslog消息的UDP报文不能超过1024字节，并且全部由可打印的字符组成。完整的syslog消息由3部分组成，分别是PRI、HEADER和MSG。大部分syslog都包含PRI和MSG部分，而HEADER可能没有。
syslog的格式
下面是一个syslog消息：
<30>Oct 9 22:33:20 hlfedora auditd[1787]: The audit daemon is exiting.
其中“<30>”是PRI部分，“Oct 9 22:33:20 hlfedora”是HEADER部分，“auditd[1787]: The audit daemon is exiting.”是MSG部分。
PRI部分
PRI部分由尖括号包含的一个数字构成，这个数字包含了程序模块（Facility）、严重性（Severity），这个数字是由Facility乘以 8，然后加上Severity得来。不知道他们为什么发明了这么一种不直观的表示方式。
也就是说这个数字如果换成2进制的话，低位的3个bit表示Severity，剩下的高位的部分右移3位，就是表示Facility的值。
十进制30 = 二进制0001 1110
0001 1... = Facility: DAEMON - system daemons (3)
.... .110 = Severity: INFO - informational (6) Facility的定义如下，可以看出来syslog的Facility是早期为Unix操作系统定义的，不过它预留了User（1），Local0～7 （16～23）给其他程序使用：
Numerical Facility
Code
0 kernel messages
1 user-level messages
2 mail system
3 system daemons
4 security/authorization messages (note 1)
5 messages generated internally by syslogd
6 line printer subsystem
7 network news subsystem
8 UUCP subsystem
9 clock daemon (note 2)
10 security/authorization messages (note 1)
11 FTP daemon
12 NTP subsystem
13 log audit (note 1)
14 log alert (note 1)
15 clock daemon (note 2)
16 local use 0 (local0)
17 local use 1 (local1)
18 local use 2 (local2)
19 local use 3 (local3)
20 local use 4 (local4)
21 local use 5 (local5)
22 local use 6 (local6)
23 local use 7 (local7)
Note 1 - Various operating systems have been found to utilize
Facilities 4, 10, 13 and 14 for security/authorization,
audit, and alert messages which seem to be similar.
Note 2 - Various operating systems have been found to utilize
both Facilities 9 and 15 for clock (cron/at) messages.
Severity的定义如下：
Numerical Severity
Code
0 Emergency: system is unusable
1 Alert: action must be taken immediately
2 Critical: critical conditions
3 Error: error conditions
4 Warning: warning conditions
5 Notice: normal but significant condition
6 Informational: informational messages
7 Debug: debug-level messages
也就是说，尖括号中有1～3个数字字符，只有当数字是0的时候，数字才以0开头，也就是说00和01这样在前面补0是不允许的。
HEADER部分
HEADER部分包括两个字段，时间和主机名（或IP）。
时间紧跟在PRI后面，中间没有空格，格式必须是“Mmm dd hh:mm:ss”，不包括年份。“日”的数字如果是1～9，前面会补一个空格（也就是月份后面有两个空格），而“小时”、“分”、“秒”则在前面补“0”。月份取值包括：
Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
时间后边跟一个空格，然后是主机名或者IP地址，主机名不得包括域名部分。
因为有些系统需要将日志长期归档，而时间字段又不包括年份，所以一些不标准的syslog格式中包含了年份，例如：
<165>Aug 24 05:34:00 CST 1987 mymachine myproc[10]: %% It's
time to make the do-nuts. %% Ingredients: Mix=OK, Jelly=OK #
Devices: Mixer=OK, Jelly_Injector=OK, Frier=OK # Transport:
Conveyer1=OK, Conveyer2=OK # %%
这样会导致解析程序将“CST”当作主机名，而“1987”开始的部分作为MSG部分。解析程序面对这种问题，可能要做很多容错处理，或者定制能解析多种syslog格式，而不仅仅是只能解析标准格式。
HEADER部分后面跟一个空格，然后是MSG部分。
有些syslog中没有HEADER部分。这个时候MSG部分紧跟在PRI后面，中间没有空格。
MSG部分
MSG部分又分为两个部分，TAG和Content。其中TAG部分是可选的。
在前面的例子中（“<30>Oct 9 22:33:20 hlfedora auditd[1787]: The audit daemon is exiting.”），“auditd[1787]”是TAG部分，包含了进程名称和进程PID。PID可以没有，这个时候中括号也是没有的。
进程PID有时甚至不是一个数字，例如“root-1787”，解析程序要做好容错准备。
TAG后面用一个冒号隔开Content部分，这部分的内容是应用程序自定义的。
RFC3195
BSD syslog协议使用UDP协议在网络中传递，然而UDP是一个不可靠的协议，并且syslog也没有要求接收方有所反馈。为了解决这个问题，RFC又定义了一个新的规范来可靠的传递syslog消息，它使用TCP协议：
http://www.ietf.org/rfc/rfc3195.txt 不过大多数情况下，使用UDP发送不需要确认的syslog消息，已经能够满足要求了，并且这样做非常简单。因此到目前为止，RFC3195的应用还是很少见的。
几种syslog的实现
由于syslog是一种RFC标准协议，所以其实现是平台无关的，目前在各种Unix/Linux系统、网络设备、终端设备中得到广泛支持，当然最重要的还是用于类Unix系统中。
syslogd
这是最传统的syslog协议服务器端的实现，运行于大多数的Linux系统中。由于其安全性差、语法太自由而导致了很多的问题，目前有了一些替代品出现。
rsyslogd
1. 后端存查日志支持的客户端多。
2. 在同一台机器上支持多直rsyslogd进程，可以监听在不同端口。
3. 直接兼容系统自带的syslog.conf 配置文件。
4. 可将消息过滤后再次转发。
5. 配置文件中可以写简单的逻辑判断
6. 有现成的前端web展示程序
现在RHEL以及CentOS都已经把rsyslog作为默认的syslog安装，不再使用syslogd了。
syslog-ng
也就是(next generation)下一代syslog，也是用来代替传统syslogd的，只是这个玩意竟然不开放源代码，所以也就不折腾这个了。
kiwisyslog
Kiwi Syslog Server 是一个免费的Windows平台上的syslog守护进程。它接收，记录，显示和转发系统日志，如路由器，防火墙，交换机，Unix主机和其他功能的设备主机的syslog消息。有许多可供自定义的选项。其特点包括PIX防火墙日志记录，Linksys的家庭防火墙日志，SNMP陷阱和TCP的支持，有能力进行筛选，分析和修改信息，并透过VBScript或JScript引擎执行动作。
syslog配置文件与应用
syslog配置文件决定了处理日志信息的规则。主要依据就是前面协议部分提到的facility和Severity。下面按照实际的例子说明。
# Log all kernel messages to the console. # Logging much else clutters up the screen. #system kern.err;cron.err;daemon.err;lpr.err;news.err;uucp.err;syslog.err -/var/log/rflogview/system_errors kern.=info;kern.=notice;cron.=info;cron.=notice;daemon.=info;daemon.=notice;lpr.=info;lpr.=notice;uucp.=info;uucp.=notice;syslog.=info;syslog.=notice;news.=info;news.=notice -/var/log/rflogview/system_info kern.=warn;cron.=warn;daemon.=warn;lpr.=warn;news.=warn;uucp.=warn;syslog.=warn -/var/log/rflogview/system_warnings #user user.=info;user.=notice -/var/log/rflogview/user_info user.=warn -/var/log/rflogview/user_warnings user.err -/var/log/rflogview/user_errors #mail mail.=info;mail.=notice -/var/log/rflogview/mail_info mail.=warn -/var/log/rflogview/mail_warnings mail.err -/var/log/rflogview/mail_errors #secure auth.=info;auth.=notice;authpriv.=info;authpriv.=notice -/var/log/rflogview/secure_info auth.=warn;authpriv.=warn -/var/log/rflogview/secure_warnings auth.err;authpriv.err -/var/log/rflogview/secure_errors #boot local7.=info;local7.=notice -/var/log/rflogview/boot_info local7.=warn -/var/log/rflogview/boot_warnings local7.err -/var/log/rflogview/boot_errors #kern.* /dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;news.none;authpriv.none;cron.none /var/log/messages # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* /var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg * # Save news errors of level crit and higher in a special file.
uucp,news.crit /var/log/spooler # Save boot messages also to boot.log local7.* /var/log/boot.log # # INN # #news.=crit /var/log/news/news.crit #news.=err /var/log/news/news.err #news.notice /var/log/news/news.notice
基本语法格式
类型.级别 [；类型.级别] `TAB` 动作
类型（Facility）
在配置文件中的名字如下：
facility参数 | syslog.conf中对应的facility取值 |
LOG_KERN | kern |
LOG_USER | user |
LOG_MAIL | |
LOG_DAEMON | daemon |
LOG_AUTH | auth |
LOG_SYSLOG | syslog |
LOG_LPR | lpr |
LOG_NEWS | news |
LOG_UUCP | uucp |
LOG_CRON | cron |
LOG_AUTHPRIV | authpriv |
LOG_FTP | ftp |
LOG_LOCAL0～LOG_LOCAL7 | local0～local7 |
级别（Severity）
在配置文件中的名字如下：
priority参数 | syslog.conf中对应的level取值 |
LOG_EMERG | emerg |
LOG_ALERT | alert |
LOG_CRIT | crit |
LOG_ERR | err |
LOG_WARNING | warning |
LOG_NOTICE | notice |
LOG_INFO | info |
LOG_DEBUG | debug |
特殊*表示所有，none表示所有都不。
其中的=是特殊符号，如果存在说明只有本Severity的消息才进行处理，如果不存在则处理本Severity及其以下级别的消息。；用于“与”操作两个选择条件。！用于取反。
动作
动作”域指示信息发送的目的地。可以是：
/filename
@host
远程主机； @符号后面可以是ip,也可以是域名，默认在/etc/hosts文件下loghost这个别名已经指定给了本机。
user1,user2 指定用户。如果指定用户已登录，那么他们将收到信息；
*
syslog客户端编程
既然syslog是一个标准的协议，所以客户端和服务器端可以独立开发。对于应用程序员来说，重新开发一个syslog服务器的可能性不大，但是在程序中使用syslog的日志功能非常常见，也就是客户端开发。客户端有两种方式开发，一是完全基于协议从底层开发，也就是直接写unix域套接字、向UDP514发送定制消息。这样做往往比较麻烦，所以大多数语言都提供了库函数供上层应用使用，C、PHP、Java等都有相应的库函数。
大多数的开源套件如apache，mysql，sendmail，postfix等都在内部使用了syslog来进行日志处理。接下来我们以C语言为例，开发一个简单的利用syslog进行日志管理的程序。
以C为例说明：
#include <syslog.h>
int main(void)
{
int log_test;
openlog("log_test", LOG_PID|LOG_CONS, LOG_USER);
syslog(LOG_INFO, "PID information, pid=%d", getpid());
syslog(LOG_DEBUG, "debug message");
closelog();
return 0;
}
按照打开日志、写入日志、关闭日志的方式进行操作。其实理解了syslog协议，编程就很简单了，关键点还是在syslog（）函数中指定日志的类别（Facility）和级别（Severity）。上面例子中，日志的类别是LOG_USER，对应的配置文件名就是user，进行了两个级别日志的写入，一个是LOG_INFO，对应于配置文件的info，另一个是LOG_DEBUG对应于配置文件的debug。
由于对应的系统的syslog.conf文件中有如下一行：
*.info;mail.none;authpriv.none;cron.none /var/log/messages
所以，我们会在/var/log/messages这个文件中找到在程序中产生的日志信息，如下：
May 13 14:52:29 localhost log_test[13900]: PID information, pid=13900
因为DEBUG级别低于INFO，所以不会被存入文件。
更多的关于各个库函数的详细用法，请参考API文档。
日志文件的分析
syslog记录的日志内容并没有什么固定的格式，可以说相当的随意。所以，自动分析工作有一定的难度，需要处理好包容问题。庆幸的是，所有的日志内容都是人类可读的ASCII文本，所以对于管理员比较友好。可以根据不同的系统，定制一些自动化分析脚本来辅助工作。
日志文件的轮替logrotate
日志文件会随着日志的增加而不断增大，从而带来效率问题和空间使用问题。在常年运行的服务器上面，通常会有logrotate程序定期进行日志文件的轮替和删除工作。关于logrotate的配置与设置，这里不进行详述。
