将 Syslog 与 Kinesis 集成：预期使用 Firehose

在 Kinesis Firehose 发布之后，越来越多的人希望将 Kinesis 与日志系统集成（以加快/简化将日志摄取到 S3 和 Redshift 中）。这是将 syslog-ng 与 Kinesis 集成来解决该问题的方法。

首先，让我们看一下 syslog-ng 配置。在 syslog-ng 配置中，您将源连接到目标：


 source s_sys {
    udp(ip(127.0.0.1) port(514));
};
destination d_test { file("/var/log/monetate/test.log"
perm(0644)
template("$MSGONLY\n")
template_escape(no)
); };
destination d_fact_kinesis { tcp("localhost"
port(4242)
template("$MSGONLY\n")
template_escape(no)
); };
log { source(s_sys); destination(d_test); destination(d_kinesis); };

在这个例子中，我们有一个事件源：UDP，我们有两个目的地：一个文件和一个 TCP。我们在最后一条 log 语句中将它们连接在一起。使用此配置，syslog-ng 通过 UDP 接收的任何数据包都将写入 TCP 端口和文件。文件是我们的备份策略，以防万一Kinesis出问题了，我们也会把事件持久化到本地。 TCP 是我们通往 Kinesis 的路径 。

在 TCP 方面，我们可以轻松地用 Java 实现一个简单的 TCP 服务器，它从 syslog-ng 接收消息并通过 KPL 将它们发送出去。在 Monetate，我们已经做到了这一点。（我会看看我们是否可以开源解决方案）。然而，了解 syslog-ng 流量控制非常重要，更具体地说，如果/当 Kinesis 开始备份时，我们将如何处理背压。

让我们考虑一下我们如何支持这一点。

这是显示整个流程的视觉效果：

在序列中的每个点，我们需要确保我们准备好处理背压。具体来说，当下一个下游组件拒绝接受额外数据时，我们需要验证每个组件的行为。

例如，如果我们的小型 TCP 服务器（“网桥”）盲目地接受来自 TCP 流的数据包，那么当 Kinesis 变慢时，我们将快速 OoM JVM。因此，在“桥”中，我们需要在上游施加背压，以防止这种情况发生。更具体地说，我们需要停止消耗 TCP 流，并希望 syslog-ng 做出适当的反应。

幸运的是，syslog-ng 已经用他们的“输出缓冲区”解决了这种情况，如上所示。输出缓冲区用于存储要传送到目的地的消息。如果该缓冲区达到最大大小，则目标将“断开连接”，以免系统日志崩溃。您可以通过 syslog-ng 中的 log_fifo_size 设置来控制缓冲区的最大大小。

在这种情况下，不同的目的地类型有不同的行为，我们测试了其中的一些。首先，我们考虑使用 syslog-ng 中的“程序”目标在 syslog 和我们的桥接进程之间建立一个直通管道。这很有效，但在备份队列的情况下，syslog-ng 会终止程序并重新生成一个新进程。这不太理想。我们还考虑过使用 UDP。这也很有效，并且实际上消除了背压情况，因为 UDP 是“即发即弃”的。然而，在重负载下，我们注意到数据包丢失，这意味着我们正在丢失事件。

最后，我们决定使用 TCP。使用 TCP，我们不会悄无声息地丢失消息，syslog-ng 也不会不断地重新启动我们的进程。有了这个决定，我们需要确认 syslog-ng 的行为。为此，我们需要监控 syslog-ng。这个方便的花花公子命令行正是这样做的：


 source s_sys {
    udp(ip(127.0.0.1) port(514));
};
destination d_test { file("/var/log/monetate/test.log"
perm(0644)
template("$MSGONLY\n")
template_escape(no)
); };
destination d_fact_kinesis { tcp("localhost"
port(4242)
template("$MSGONLY\n")
template_escape(no)
); };
log { source(s_sys); destination(d_test); destination(d_kinesis); };

在监控系统日志时，我们测试了两种故障场景。第一个测试了一个死桥（没有 TCP 侦听器）。在这种情况下，syslog-ng 将无法连接。我们需要确保 syslog-ng 在这种情况下表现良好。为了对此进行测试，我们在 40 秒内通过系统运行了 100K 条消息（>2K/秒）。在监控 syslog-ng 时，我们看到它试图重新连接：


 source s_sys {
    udp(ip(127.0.0.1) port(514));
};
destination d_test { file("/var/log/monetate/test.log"
perm(0644)
template("$MSGONLY\n")
template_escape(no)
); };
destination d_fact_kinesis { tcp("localhost"
port(4242)
template("$MSGONLY\n")
template_escape(no)
); };
log { source(s_sys); destination(d_test); destination(d_kinesis); };

所有消息都进入了我们的日志文件（哈利路亚！），这意味着断开的 TCP 连接对日志文件目标没有影响。此外，syslog-ng 不断重试建立 TCP 连接，所以当进程确实恢复时，它会重新连接！好的！从上面的输出中需要注意的一件非常重要的事情是“time_reopen”。事实证明，这是一个全局配置选项，它告诉 syslog-ng 等待多长时间，直到重新尝试建立连接。所以，这个行为是可靠的——我们实际上可以配置如果/当我们失去桥接过程时，事情会变得多么嘈杂。

对于最终测试，我们需要查看当我们从 Java 进程本身应用背压时会发生什么。在这种情况下，syslog-ng 可以连接，但 java 进程拒绝读取流/套接字。为此，我们运行了相同的 100K 测试，但暂停了 java 进程中的消耗以模拟 Kinesis 减速。再一次，我们看到了好东西……所有消息都进入了日志文件，这次我们看到来自 syslog-ng 的消息表明输出缓冲区（fifo 队列）已满：


 source s_sys {
    udp(ip(127.0.0.1) port(514));
};
destination d_test { file("/var/log/monetate/test.log"
perm(0644)
template("$MSGONLY\n")
template_escape(no)
); };
destination d_fact_kinesis { tcp("localhost"
port(4242)
template("$MSGONLY\n")
template_escape(no)
); };
log { source(s_sys); destination(d_test); destination(d_kinesis); };

日志消息告诉你一切，在队列填满后，它会将消息丢弃在地板上，直到它可以重新建立套接字。

所以，你已经知道了……要将 syslog 连接到 Kinesis，我建议使用 TCP 输出目标，并在该目标和 Kinesis Producer Library (KPL) 之间使用一些粘合代码。（再一次，我会看看我们是否可以开源其中的一些）只是要小心，并将反压应用于 syslog-ng。

根据我们的实验，syslog-ng 可以支持这一点！

将 Syslog 与 Kinesis 集成：预期使用 Firehose

相关文章