我们有一项使用原始 AWS EC2 实例来处理请求的服务。响应时间在 2-3 毫秒范围内。该响应时间对于服务的健康和成功至关重要。
服务工作的一部分是将请求详细信息发送到其他地方，以便可以汇总并呈现给客户以供历史记录之用。我们已通过使用 Syslog 记录到 Rsyslog 中配置为转储到的特定设施来解决这个问题/var/log/local5.log，我们运行配置为跟踪该日志文件的 AWS Kinesis 代理并将 JSON 日志批量发送到 Kinesis 流。我们探索了直接从应用程序中使用 SQS/SNS/Kinesis，但所有这些都会在响应时间中引入 10-30 毫秒，这使得它无法启动。我们还尝试在本地系统上运行后台队列，但这显然占用了资源并导致比它值得的更多问题。
我们最近开始将这项服务迁移到容器中，并开始思考如何聚合这些日志。我认为有以下几种选择：
- 运行一个辅助维护进程，监听系统日志请求并在本地发送到系统日志
- 运行一个单独的服务，该服务可以独立于监听系统日志请求的应用程序进行扩展
- 有些事我还没想过……
我尝试使用 Vector 作为外部服务上的 Syslog 源（分配 DNS 并让本地应用程序记录到远程 syslog），但我发现我用于在应用程序中记录到远程 Syslog 的库在消息长度达到一定长度后被切断（约 1000 个字符 /https://github.com/reproio/remote_syslog_sender#message-length) 对于我们想要记录的一些日志来说它不够大。
这让我怀疑我们现在通过 Syslog（Ruby Syslog 标准库）记录的请求是否受到限制。我不确定是否如此，但我想找到一种方法来处理所有请求。
Vector 在 AWS 上站稳脚跟很有挑战性，因为虽然你可以在 UDP 上监听，但我无法让 AWS NLB 通过 UDP 进行健康检查，而且它也没有通过 TCP 做出响应。
现在，我正在考虑一个基于卷的解决方案，我们将继续跟踪日志。这是最好的方法吗？还是我遗漏了什么？