Rsyslog——第三章 实例
来源:互联网 发布:神兵天降之 java 编辑:程序博客网 时间:2024/05/02 07:53
第三章 实例
3.1 Tcp+DA模式实现可靠消息传输。
Rsyslog单独使用了一篇文档来介绍实现可靠消息传输。
首先rsyslog阐述了单独使用tcp协议的不可靠性,比如server端宕机等等情况。为此如上面介绍队列时提到的内容,我们需要在client配置一个本地文件,用来在server端宕机这种情况下,暂时保存消息。需要注意的是,队列名是和过滤规则对应的,一个队列只能用于一个过滤规则,例:
此处只是为了说明问题,更简单的写法,是把两条过滤规则写成一条:local3.*;local4.*。还有一点需要强调的是,本地队列只有在需要使用的时候才会创建,当后端出现短暂不可用是,rsyslog的内存队列就可以保存消息,内存队列不够用时,才会创建本地队列。
3.3 mmnormalize模块
当我们需要定义一个复杂的输出时,单纯使用模板会显得比较笨拙,这时候我们就可以使用mmnormalize这个模块来帮助我们简化模板。例如我们部门本身使用一套日志格式,但是某个重要客户,需要将他自己的日志按照他所规定的格式保留一份,为此,我们需要定义一个过滤规则,过滤该用户的日志,然后打散日志,重排,下面我会用模板和mmnormalize两种方式来解决这个问题。
首先使用模板,我使用list的方式定义:
这种方式写出的模板是很冗长的,下面使用mmnormalize模块实现,为此,我们需要先定义一个消息格式,来供mmnormalize使用,rulebase.rb:
然后,rsyslog的配置文件中,我们可以将以上定义的字段当做属性来使用(需要以$!开头),如下:
可以看出这种方式比使用模板要简洁清楚多了。不过额外的你需要多使用一个配置文件。
3.4 omprog模块
如文档所表述的一样,omprog可以指定第三方的程序来处理模块,运行时,第三方的模块被当做rsyslog的子进程启动,两者通过管道通信。此时过滤规则定义的模板,就是子进程的输入格式。
3.5额外的测试。
1、测试了imtcp和imptcp的区别,测试了两者的性能差不多,ptcp略低,这和官网说的ptcp性能更好不一致,可能我还没有压到极限,没有测出真实数据,测试过程中imtcp的cpu使用较高,大概在130%,imptcp的cpu大概在70%左右,可以预见ptcp使用多线程技术,分担了主线程的压力。
2、其他部门的同事测试tcp+da可以解决server端宕机的问题,但是如果server端因为io较高,造成阻塞,rsyslog并不能解决这个问题,syslog阻塞是个很严重的问题,如果apache直接写syslog,而syslog阻塞会导致apache无法处理请求。因此必须在server端加监控,如果io较高,就需要优化参数,或者增加server机器了。
3、使用-dn模式来测试mmnormalize模块,如过mmnormalize没有收到正确的rulebase,debug文件中会搜索‘unparser’会看到未解析的rulebase字符串,如果解析成功,可以搜索‘gennerate’,可以看到自定义的属性,在真实消息中的值。
4、rsyslog中的参数有的是全局参数,例如Createmode,有的则是对应于某一ruleset或者某一过滤规则,所以使用前,需要对参数的有效范围进行测试。
5、如果你希望client和server端都使用rsyslog,那么你不要修改两者之间的传输模板。因为rsyslog 需要根据syslog协议来解析消息,如果你使用t_msg传输,那么server端无法识别该消息。
6、同事反馈之前使用syslog-ng时消息超过设置的最大消息长度,会分成两条发送,rsyslog行为不同,超过设置的最大消息长度,超出部分会丢弃。
7、rsyslog默认会将特殊字符(\t)转换成#009 由全局配置$EscapeControlCharactersOnReceive 决定,如果自己需要根据\t处理输出时,需将该选项改为off。
8、配置文件每一行之前,只能包含空格,如果半酣其他字符,rsyslog不能识别该行。
9、使用omprog时,rsyslog通过管道将消息发送给第三方程序, 因此当消息量较大时,第三方程序要具备相应的处理能力,否则很容易造成管道阻塞,导致rsyslog阻塞。这个问题挺严重的,我们的经验是server日志转发到redis,但是开始的程序处理能力达不到,导致server端的tcp接收队列阻塞。
3.6 未解决的问题
1、本想测试template和mmlognorm两种方式那种更快,但是发现ab压的时候,总是会多出一些输出日志,不知道是不是压力太大,导致有retry操作,发生概率大概3%,现有测试数据,两者的性能差不多。
2、使用 -dn的debug模式,输出太多,不使用debug模式的输出又太少,希望找到其他的输出参数,失败了,估计要看代码了。
原文转载自:http://www.cnblogs.com/tobeseeker/archive/2013/03/10/2953250.html
3.1 Tcp+DA模式实现可靠消息传输。
Rsyslog单独使用了一篇文档来介绍实现可靠消息传输。
首先rsyslog阐述了单独使用tcp协议的不可靠性,比如server端宕机等等情况。为此如上面介绍队列时提到的内容,我们需要在client配置一个本地文件,用来在server端宕机这种情况下,暂时保存消息。需要注意的是,队列名是和过滤规则对应的,一个队列只能用于一个过滤规则,例:
此处只是为了说明问题,更简单的写法,是把两条过滤规则写成一条:local3.*;local4.*。还有一点需要强调的是,本地队列只有在需要使用的时候才会创建,当后端出现短暂不可用是,rsyslog的内存队列就可以保存消息,内存队列不够用时,才会创建本地队列。
3.3 mmnormalize模块
当我们需要定义一个复杂的输出时,单纯使用模板会显得比较笨拙,这时候我们就可以使用mmnormalize这个模块来帮助我们简化模板。例如我们部门本身使用一套日志格式,但是某个重要客户,需要将他自己的日志按照他所规定的格式保留一份,为此,我们需要定义一个过滤规则,过滤该用户的日志,然后打散日志,重排,下面我会用模板和mmnormalize两种方式来解决这个问题。
首先使用模板,我使用list的方式定义:
这种方式写出的模板是很冗长的,下面使用mmnormalize模块实现,为此,我们需要先定义一个消息格式,来供mmnormalize使用,rulebase.rb:
然后,rsyslog的配置文件中,我们可以将以上定义的字段当做属性来使用(需要以$!开头),如下:
可以看出这种方式比使用模板要简洁清楚多了。不过额外的你需要多使用一个配置文件。
3.4 omprog模块
如文档所表述的一样,omprog可以指定第三方的程序来处理模块,运行时,第三方的模块被当做rsyslog的子进程启动,两者通过管道通信。此时过滤规则定义的模板,就是子进程的输入格式。
3.5额外的测试。
1、测试了imtcp和imptcp的区别,测试了两者的性能差不多,ptcp略低,这和官网说的ptcp性能更好不一致,可能我还没有压到极限,没有测出真实数据,测试过程中imtcp的cpu使用较高,大概在130%,imptcp的cpu大概在70%左右,可以预见ptcp使用多线程技术,分担了主线程的压力。
2、其他部门的同事测试tcp+da可以解决server端宕机的问题,但是如果server端因为io较高,造成阻塞,rsyslog并不能解决这个问题,syslog阻塞是个很严重的问题,如果apache直接写syslog,而syslog阻塞会导致apache无法处理请求。因此必须在server端加监控,如果io较高,就需要优化参数,或者增加server机器了。
3、使用-dn模式来测试mmnormalize模块,如过mmnormalize没有收到正确的rulebase,debug文件中会搜索‘unparser’会看到未解析的rulebase字符串,如果解析成功,可以搜索‘gennerate’,可以看到自定义的属性,在真实消息中的值。
4、rsyslog中的参数有的是全局参数,例如Createmode,有的则是对应于某一ruleset或者某一过滤规则,所以使用前,需要对参数的有效范围进行测试。
5、如果你希望client和server端都使用rsyslog,那么你不要修改两者之间的传输模板。因为rsyslog 需要根据syslog协议来解析消息,如果你使用t_msg传输,那么server端无法识别该消息。
6、同事反馈之前使用syslog-ng时消息超过设置的最大消息长度,会分成两条发送,rsyslog行为不同,超过设置的最大消息长度,超出部分会丢弃。
7、rsyslog默认会将特殊字符(\t)转换成#009 由全局配置$EscapeControlCharactersOnReceive 决定,如果自己需要根据\t处理输出时,需将该选项改为off。
8、配置文件每一行之前,只能包含空格,如果半酣其他字符,rsyslog不能识别该行。
9、使用omprog时,rsyslog通过管道将消息发送给第三方程序, 因此当消息量较大时,第三方程序要具备相应的处理能力,否则很容易造成管道阻塞,导致rsyslog阻塞。这个问题挺严重的,我们的经验是server日志转发到redis,但是开始的程序处理能力达不到,导致server端的tcp接收队列阻塞。
3.6 未解决的问题
1、本想测试template和mmlognorm两种方式那种更快,但是发现ab压的时候,总是会多出一些输出日志,不知道是不是压力太大,导致有retry操作,发生概率大概3%,现有测试数据,两者的性能差不多。
2、使用 -dn的debug模式,输出太多,不使用debug模式的输出又太少,希望找到其他的输出参数,失败了,估计要看代码了。
原文转载自:http://www.cnblogs.com/tobeseeker/archive/2013/03/10/2953250.html
0 0
- Rsyslog——第三章 实例
- rsyslog——第二章 rsyslog的概念
- rsyslog研究——第一章 rsyslog整体架构
- 日志采集——rsyslog
- rsyslog 入门 第三篇 omkafka
- linux 服务——rsyslog日志服务
- rsyslog
- rsyslog
- rsyslog
- Rsyslog
- rsyslog
- rsyslog
- rsyslog
- rsyslog
- rsyslog
- 第二章 rsyslog的概念
- 《现代操作系统(中文第三版)》课后习题——第十章 实例研究1:Linux
- IOS第三十二天——Socket连接实例
- IOS UIScrollView背景色 及滑动范围设定
- python并发框架库
- Manage and Create Invoices
- libzip的使用
- 关于C语言几个关键字问题的总结
- Rsyslog——第三章 实例
- [c++,algorithm] 哈密尔顿回路判断
- zlib
- c++ 字符串换行
- Oracle 获取字符串中所有中文汉字(不含标点符号)
- 安卓学习之路-Broadcast学习
- android应用程序目录结构框架搭建
- java解析xml文件
- 获取应用程序的名称和版本号