考虑到一个通过 UDP 接收日志并使用 TLS 转发到中央日志服务器的 docker 容器，我想知道我是否可以满足于一个队列或者是否需要多个队列。
确实，我知道除了将日志发送到收集器之外我不会做任何其他事情，我真的不明白为什么需要多个队列。如果存在其他操作（例如在文件上写入日志或为故障转移复制输出），它们当然是有意义的，但是如果转发是唯一的任务怎么办? 在直接队列模式（即无队列）下拥有主队列和“发送到收集器”操作是否足够？如果中央服务器发生故障（或网络中断），则日志将简单地重新排队到主消息队列？
例如，在下面这个场景中，这Action Q完全是合理的，但如果我们放弃登录，那/var/log/messages不是Action Q毫无用处了吗？这不仅毫无用处，而且还会减慢转发速度，对吗？
场景图：https://i.stack.imgur.com/8kFQP.png（无法发图片）
答案1
首先，快的介绍 rsyslog 和队列。
rsyslog 的每个输入都通过一个或多个线程，这些线程收集日志消息并将其添加到主队列。然后，工作线程从主队列中拉取消息，并将其传递到目的地和/或将消息添加到动作队列。（这基本上就是您发布的图像所做的事情）
如果工作人员无法将消息传递到目的地，则该队列的所有进度都将被阻止，直到该传递能够成功（或达到重试限制并永久失败）。如果您不想阻止所有日志处理，则应该为该目的地（或目的地组）创建一个操作队列。
现在就你的情况而言，最后一点可能不让你感兴趣，因为你只想中继日志。
说到点子上，每个动作都有一个专用的队列。这个队列可以在记忆中， 有可能在磁盘上或者可以是两个都。还有直接模式，这意味着设计上有一个队列，但实际的驱动程序会将消息转发给操作，而无需动作排队。
所以直接队列可能是您正在寻找的队列类型。如果输出操作失败，操作处理器会通知操作队列，然后该队列会取回未处理的元素，并在一段时间后再次尝试该操作。因此，直接队列还具有普通的队列。
现在回到最后一个问题：不但没用而且还会减慢转发速度，对吧？
我不太确定，如果直接队列比动作队列快得多链表或者固定数组模式，因为我从来没有测试过（甚至没有使用过）直接队列） 前。
编辑：欲了解更多深入知识，请参阅下面的答案。
答案2
您希望在需要分离消息处理的地方使用队列。在您的简单（和常见）示例中，您正在写入本地文件并通过 TCP 将消息发送到远程计算机。
通过 TCP 发送日志是一个可能阻塞的过程。如果出现网络问题或服务器问题，发送方将暂停日志传送。如果没有该操作的队列，则这意味着您也不会将日志写入本地文件（包括诸如表明远程系统已关闭的日志等有用信息 ;-) ）
因此在这种情况下，您确实需要一个动作队列，以便 TCP 连接可以阻塞而不阻塞对 /var/log/messages 的写入。
这里还有一些其他的事情需要考虑。
队列可以放在动作或规则集上，如果您要发送到多个地方（或想要从一个地方故障转移到另一个地方），您需要将它们分组到一个规则集中，并将队列放在规则集上。
如果你要将一个动作放入队列，你确实需要使用新的 action() 语法，旧的语法 ($foo 行在动作之前) 太容易让人误解发生了什么
使用 TCP 传输时，您仍然可能会丢失消息，当 rsyslog 将消息发送给发送机器上的操作系统时，如果该操作系统接受了该消息（即没有说“队列已满，请等待”），则发送方的 rsyslog 被迫假定该消息将被传递。但如果发生中断（网络或接收服务器），rsyslog 将永远不会知道该消息已丢失。RELP 协议旨在处理这种情况，并在出现网络/接收器问题时重新发送消息。
就队列而言，“直接队列”就是“无队列”，这是当您有多个操作时发生的正常情况
所以传统的
邮件。* /var/log/邮件 kern。* /var/log/kern
是“直接队列”的一个例子，它们是处理消息的最快方式。
磁盘队列在处理之前将每条消息保存到磁盘，速度非常慢（大约减慢 1000 倍），但系统崩溃后仍可继续运行
内存队列将日志存储在 RAM 中（固定数组的链表在分配 RAM 的方式和速度方面有所不同）
磁盘辅助队列是内存队列，它将溢出到磁盘文件而不是阻止进一步处理（清空队列不是按顺序进行的，磁盘部分与处理内存队列中的日志同时清空）。这是处理长时间中断的好选择，但请注意，中断后，您将开始快速获取当前日志，但较旧的日志将以较慢的速度到达。
队列可能会用得过多。当您有内存队列时，线程 A 需要锁定队列才能将消息添加到队列，然后线程 B 需要锁定队列才能从队列中检索消息以进行处理。如果您有轻量级输出（即写入文件），则锁定和解锁队列所花费的 CPU 远远多于仅将消息写出所花费的 CPU 数量。