Amazon VPC 内简单可靠的集中式日志记录

Question

我需要为 Amazon VPC 中的一组服务器 (10-20) 设置集中日志记录。如果任何单个服务器脱机 - 或者在整个可用区脱机的情况下，日志记录应该不会丢失任何日志消息。它还应该容忍数据包丢失和其他正常的网络条件，而不会丢失或复制消息。它应该持久地存储消息，至少在两个可用区的两个不同 EBS 卷上，但 S3 也是一个好地方。它也应该是实时的，以便消息在生成后的几秒钟内到达两个不同的可用区。我还需要同步不是通过 syslog 生成的日志文件，因此仅使用 syslog 的集中式日志记录解决方案无法满足所有需求，尽管我认为可以解决该限制。

我已经回顾了一些解决方案，我将在此处列出它们：

Flume 到 Flume 到 S3：我可以将两个日志服务器设置为 Flume 主机，它们将在本地或 S3 中存储日志消息，并使用 Flume 配置所有服务器以使用端到端可靠性选项将所有消息发送到两个服务器. 这样，单个服务器的丢失不应导致消息丢失，并且所有消息都会实时到达两个可用区。但是，需要某种方式来连接两台服务器的日志，对传送到两台服务器的所有消息进行重复数据删除。这可以通过在发送端为每条消息添加一个唯一的 id 来完成，然后在日志文件上编写一些手动重复数据删除运行。我还没有找到解决重复问题的简单方法。

Logstash 到 Logstash 到 ElasticSearch：我可以在服务器上安装 Logstash，并让它们通过 AMQP 传送到中央服务器，并打开持久性选项。但是，要使其正常工作，我需要使用一些具有集群功能的 AMQP 实现，或者像 Flume 案例一样扇出交付。AMQP 似乎是另一个具有多种实现的移动部分，并且没有关于哪种设置最有效的真正指导。而且我并不完全相信我可以从 logstash 到 elasticsearch 获得实际的端到端持久性，假设两者之间的服务器崩溃。扇出解决方案再次遇到重复数据删除问题。似乎可以处理所有情况的最佳解决方案是甲壳虫，它似乎通过 redis 存储提供高可用性和重复数据删除。然而，我没有

Logstash 到 ElasticSearch：我可以在所有服务器上运行 Logstash，在服务器本身中拥有所有过滤和处理规则，然后让它们直接登录到移除的 ElasticSearch 服务器。我认为这应该给我带来可靠的日志记录，我可以使用 ElasticSearch 集群功能透明地共享数据库。但是，我不确定设置是否真的能够在 Logstash 重启和间歇性网络问题中幸存下来，而不会在故障转移或类似情况下复制消息。但这种方法听起来很有希望。

rsync：我可以将所有相关的日志文件 rsync 到两个不同的服务器。这里的可靠性方面应该是完美的，因为在同步完成后文件应该与源文件相同。但是，每秒执行几次 rsync 听起来并不有趣。此外，我需要日志在发送后不可篡改，因此 rsync 需要处于仅附加模式。除非我小心，否则日志轮换会把事情搞砸。

带有 RELP 的 rsyslog：我可以设置 rsyslog 以通过 RELP 将消息发送到两个远程主机，并有一个本地队列来存储消息。再次出现重复数据删除问题，RELP 本身也可能会复制一些消息。但是，这只会处理通过系统日志记录的事情。

这些解决方案中没有一个看起来非常好，它们仍然有很多未知数，所以我在此向设置集中式可靠日志记录的人寻求更多信息，以了解实现该目标的最佳工具是什么。

Answer 1

我是LogZilla的创建者，我们即将发布我们软件的 Amazon EC2 云解决方案。我很高兴有机会讨论您的目标以及为您提供此解决方案的可能性。如果您有兴趣，请随时与我联系。

虽然我确信您可以使用 rsyslog，但我们正在将 syslog-ng 与 tcp 结合使用（您也可以使用 tls 加密和基于磁盘的缓冲来保护并帮助确保消息传递）。

我们的测试盒每秒发送多达 3000 个事件，不会丢失任何事件 - 全部在 Amazon EC2 微型盒上（请注意，这在生产中不起作用，主要是因为存储需求，但它证明了我们所做的工作完毕）。

对于 HA，使用两个目标日志服务器然后尝试对它们进行重复数据删除会更容易 - 然后，只需在两个服务器之间使用心跳，并且如果主服务器脱机，则无法连接到备用服务器。如果您愿意，您仍然可以进行重复数据删除，但前者往往更容易实现并且效果很好。

同步非 syslog 文件很简单，只需通过 perl 解析它们并使用 Log::Syslog::Fast 通过 syslog 发送它们 - 我们软件的 contrib 目录中包含一个示例（如果您想要一个，请查看 svn）复制）。您也可以将它们复制到 LogZilla 服务器，然后将它们直接通过管道传输到我们的预处理器中。