rsyslog的多规则集

    自从4.5.0和5.1.1版本开始，rsyslog支持在单个配置中的多个规则集。这对于路由根据一系列指定的规则收到的远程消息十分有用。注意到输入模块必须支持绑定到非标准规则集，所以这个功能可能并不是对所有的输入都适用。

    在本片文章中，我是用imtcp，一个输入模块支持绑定到非标准规则集因为rsyslog开始支持他们。

什么是规则集？

    如果你接触过syslog.conf（rsyslog.conf），你知道它是由我称为规则的东西组成的（其他的一些资料可能倾向于叫他们选择符，是一个sysklogd名词）。每个规则由一个过滤器和一个或者多个当该过滤器评测为真时所要执行的动作组成。一个过滤器可能和传统的传统的syslog基于优先级的过滤器一样简单（比如“*.*”或者“mail.info”），或者是一个和像脚本一样的表达一样复杂。关于它们的细节在配置文件文献中介绍。然后是动作说明符，一个动作是对于消息要做的一些事情，比如，将它写到一个文件或者将它传送到一个远程的日志服务器。

    一个传统配置文件有一个或者多个这种规则组成，当一个新的消息到达时，它的处理开始于第一条规则（在它们出现在rsyslog.conf中的顺序）并且对于每一条规则继续直到或者所有的规则都已经被处理或者一个称为为丢弃的动作发生为止，在这种情况下处理终止并且消息被丢弃（终止也会发生在最后一条规则被处理之后）。

    多-规则集（英文为multi-ruleset）现在支持允许指定不止一个这种规则序列。你可以认为传统的配置文件仅仅是一个单个默认规则集，其被自动绑定到每一个输入上，这也是确实发生的。当rsyslog.conf被处理的时候，配置文件分析器查找指令：

其中name可以是用户喜欢的任何名字（但是必须不能以“RSYSLOG_”开始，这是保留给rsyslog使用的名字空间）。如果它发现了这个指令，它开始一个新的规则集（如果这个名字还不知道）或者转化为一个已经存在的一个（如果这个名字已经知道）。所有在这个$Ruleset指令和下一个之间定义的将被追到到这个命名的规则集中。注意到保留名字“RSYSLOG_DefaultRuleset”用于指定rsyslog的默认规则集，你可以在任意你可以使用一个规则集名字的地方使用这个名字，包括为它绑定一个输入的时候。

    在一个规则集中，消息如上面描述的那样被处理：它们从第一条规则开始并且以在配置文件中出现的规则顺序被处理，知道没有规则或者丢弃动作被执行。注意到有了多规则集以后不是所有的rsyslog.conf规则被执行而只是包含在指定规则集中的被执行。

    输入必须显式绑定到规则集中，如果它们不这样做，默认的规则集被绑定。

    这带来了下一个问题：

“绑定到一个规则集”意味着什么？

    这个术语被使用在和“为一个接口绑定一个ip地址”相同的一一下：它意味着一个指定的输入，或者一个输入的一部分（比如一个tcp监听者）将会使用一个特定的规则集来“将它的消息传递到”。所以当一个新的消息到达时，它将会通过绑定的规则集被处理。所有来自于其他的规则集的规则是不相干的，并且将不会被处理。

    这使得multiple ruleset可以非常方便地通过不同的方式处理本地或者远程的消息：将接收者分别绑定到不同的规则集上，并且你不需要通过其他的任何方式区分消息。

    绑定到规则集是输入指定的。对于imtcp，这是通过：

指令来完成的。注意到“name”必须是一个在绑定指令给出时已经定义的一个规则集的名字。有很多方法可以保证它的发生，但是我个人认为最好在rsyslog.conf的顶部定义所有的规则集并且在底部定义所有的输出。这种方式反转了传统推荐的顺序，但是看起来确实是一个实现的有用和直接的方式。

为什么规则集对于不同的解析器配置如此重要？

    自定义消息分析器，被用来处理不同的消息格式（并且否则可能-无效），可以绑定到规则集。因此multiple rulesets是一个非常有用的方法来处理以不同的畸形格式，以一个一致的方法发送消息的设备，这在syslog的世界里并不是不寻常的，一个通过配置样本的深入的即使可以在$RulesetParser配置指令找到。

我可以将一个不同的规则集设为默认么？

    可能通过使用：

指令来实现。请注意，但是，这条指令实际上是全局的：也就是说，它并不修改下一个输入绑定的规则集，而且是为没有显式绑定到一个的数据提供了一个系统范围内的默认的规则集。像这样，这条指令不能作为将不支持规则集绑定的输入绑定到非默认规则集的解决方法。

规则集和主队列：

    默认情况下，规则集并没有它们自己的队列。它必须通过$RulesetCreateMainQueue指令来激活，或者如果使用了rainerscript格式，通过在规则集指令中指定队列参数，例如ruleset(name=”whatever” queue.type=”fixedArray” queue. ...)，更多细节可以参考http://www.rsyslog.com/doc/queue_parameters.html。

示例：

（1）、分离本地和远程日志

    让我们认为你有一个相当标准的系统，它将它的本地信息记录到默认的rsyslog.conf中指定的通常的一系列文件中，例如，你的rsyslog.conf可能看起来是：

现在你希望从一个远程的系统中接收消息并将它们记录到一个特定的文件中，但是你并不希望将这些消息写到上面指定的文件中。传统的方式是在所有其它过滤该消息的规则前面添加一条规则，处理它之后丢弃它：

注意到“stop”就是丢弃动作！。同时注意到我们假设192.0.2.1是唯一的远程发送（为了保持它简单）。

    有了multiple rulesets后，我们可以为远程接收的例子仅仅定一个一个特定的规则集并且将它绑定到接受者，如下：

(2)、为三个不同的接口分离本地和远程日志：

    这个例子和第一个很像，但是它添加了一点扩展，尽管非常相似，我希望它足够不同来提供一个有效的例子，你可能想有超过两个规则集。

    再次，我们可能想使用常规的日志文件来只进行本地存储。但是这次我们建立了三个syslog/tcp监听器，每一个监听不同的端口（比如10514，10515和10516）。从这些接收者接收到的日志应该放到不同的文件。同时，从10516中收到的日志（仅仅这个端口！）的带有"mail.*"优先级，应该被写到一个特定的文件而不是10516的通常的日志文件中。

    下面是配置：

上面是不是应该是test1？？？

性能：

（1）、更少的过滤器

    没有规则处理可以比一条都不处理要快。因此，它对于一个高性能的系统来识别分离的动作并且尝试将它们分离成不同的规则集是有用的。在上面的示例一节中，我们有一个例子，其中有三个不同的监听器需要写到三个不同的文件中，这对于说明multiple ruleset更易于使用并且提供更多的性能是个绝佳的例子。性能更好只是简单地因为没有必要检查接收服务-取而代之的是消息被自动推送到正确的规则集并且可以通过非常简单的规则进行处理（可能甚至是通过“*.*”-属于最快的可用过滤器）。

（2）、输入数据的划分

    自从rsyslog5.3.4开始，规则集允许更高的并发性，它们提供了在它们自己的“main”队列中运行的能力，这意味着一个自身的队列都和一个特定的规则集相关。这意味着绑定到规则集的输入在将一个数据元素插入到队列中时不再需要相互竞争。取而代之的是，入队操作可以并行完成。

    一个例子：让我们假设我们有三个TCP监听器。没有规则集的话，它们都需要将消息插入到主消息队列中。所以如果它们其中之一想要提交在同一时间将一个新到达的消息添加到队列中，只有一个可以这样做而其它的需要等待。通过multiple rulesets，它自身的队列可以为每一个规则集创建。如果现在每个监听器绑定到它自己的规则集，那么并行的消息提交就是可能的。在一个足够大的核心数的机器上，可以导致极大的性能提升。

    高度建议在高性能的系统中定义一个专用的规则集，对于每一个输入有一个专用的队列。

    默认情况下，规则集没有他们自身的队列，他必须通过$RulesetCreateMainQueue指令进行激活。

 

另请参加：

     Legacy Format Samples for Multiple Rulesets

     本文是rsyslog项目的一部分。Copyright © 2009-2014 by Rainer Gerhards and Adiscon. Released under the GNU GPL version 3 or higher.

原文：http://www.rsyslog.com/doc/v8-stable/concepts/multi_ruleset.html#fewer-filters