我需要为 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 …