在之前的文章中我么谈到了ELK stack的部署和简单的小demo,然后我们又看了elk stack结合filebeat做了一个分析,具体可参考下面的链接:
Linux 部署ELK 日志分析系统与简单测试
ELK stack实战之Filebeat的架构分析、配置解释与示例
本篇文章我们主要谈一下Linux操作系统的rsyslog(syslog),然后结合elk stack做一个分析autho.log(linux自己生成的日志)的demo
syslog与rsyslog syslog首先需要说明的是syslog是一种协议,广泛用于系统日志,syslog系统日志消息可以记录在本地,也可以发送到接受syslog日志的服务器统一进行存储和处理,也可以解析其中的内容做相应的处理。
常见的应用场景是网络管理工具、安全管理系统、日志审计系统。
对于老版本的unix操作系统,默认使用syslog,但是在新版本都已经被rsyslog所替代
老版本的Linux缺省使用Syslog,其配置大致如下所示:
完整的syslog日志中包含产生日志的程序模块(Facility)、严重性(Severity或 Level)、时间、主机名或IP、进程名、进程ID和正文。在Unix类操作系统上,能够按Facility和Severity的组合来决定什么样的日志消息是否需要记录,记录到什么地方,是否需要发送到一个接收syslog的服务器等。由于syslog简单而灵活的特性,syslog不再仅限于 Unix类主机的日志记录,任何需要记录和发送日志的场景,都可能会使用syslog。
这里涉及两个概念:Facility和Severity,中文的意思大致是类型和级别。重点说明两条配置的含义:首先,所有Severity大于等于info的信息都会被保存到「/var/log/messages」中,但是Facility为mail、authpriv、cron的消息例外;其次,所有Facility为mail的消息都会保存到「/var/log/maillog」中,日志文件前面的减号表示的意思是异步写文件。
rsyslog上边也说了,对于现在的很多发行版都默认采用了rsyslog,rsyslog是syslog的升级版,这里我们看些Facility和Serverity
rsyslog通过Facility概念来定义日志消息的来源,以方便对日志进行分类 ,facility有以下几种
除了日志来源以外,对于同一来源产生的日志消息,还进行了优先级的划分,优先级分为以下几种
Emergency 系统已经不能使用 Alert 必须立即进行处理 Critical 严重错误 Error 错误 Warning 警告 Notice 正常信息,但是较为重要 Informational 正常信息 Debug debug信息 案例:rsyslog+ELK分析auth.log 启动/停止/查看rsyslog的状态在配置rsyslog的机器上执行即可
sudo service rsyslog start sudo service rsyslog stop Sudo service rsyslog status 使用系统的logger命令测试rsyslog是否工作在配置rsyslog的机器上执行即可
Logger hello world
查看/var/log/message
[master@localhost log]$ sudo tail -n 1 messages
Sep 29 23:37:00 localhost master: hello word
使用官方提供的 tcpflood
https://github.com/rsyslog/rsyslog/blob/master/tests/tcpflood.c
1、服务器两台
192.168.197.129 配置elk OS:RedHat
192.168.197.131 rsyslog客户端 OS:CentOS7