本文深入探讨rsyslog的高级配置技巧，包括可靠消息传输、mmnormalize模块简化模板、omprog模块集成第三方程序等，并分享了多个实用案例及注意事项。
第三章 实例
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
扫一扫
1904
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
