syslog介绍-CS架构来采集系统日志

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部分。

摘自:http://blog.csdn.net/smstong/article/details/8919803

原文地址:https://www.cnblogs.com/bonelee/p/7680507.html