我们有几个nodejs服务器，每个请求的详细信息和有效负载都需要记录到SQL Server中，以进行报告和其他业务分析。
服务器之间的请求量和需求的相似性使我想通过集中式日志记录服务来解决这个问题。我的第一直觉是使用 Amazon SQS 之类的东西，让它直接充当 SQL Server 的缓冲区，或者构建一个小型日志记录服务器，该服务器将进行由 SQS 定向的数据库调用。
这听起来像是 SQS 的良好用途，还是我错过了用于此任务的广泛使用的工具？
解决方案实际上取决于您正在使用的数据量，因为每个服务都有限制。仅举几例：
SQS
- 首先，由于您正在处理日志，因此您不希望重复。考虑到这一点，您需要一个FIFO(先进先出(队列。
- SQS 本身并没有真正调用任何东西。您在此处要做的是设置队列，然后调用以通过 AWS JS SDK 提交消息。然后，当您在回调中返回消息时，获取消息 ID 并将该数据传递给调用的 Lambda 函数(您也可以在 NodeJS 中编写这些函数(，该函数将您需要的信息存储在数据库中。
- 也就是说，重要的是要知道 SQS 队列中的消息有大小限制：
最小消息大小为 1 个字节(1 个字符(。最大值为 262,144 字节 (256 KB(。
要发送大于 256 KB 的消息，您可以使用 Amazon SQS 适用于 Java 的扩展客户端库。此库允许您发送 Amazon SQS 消息，其中包含对 中消息负载的引用 亚马逊 S3。最大有效负载大小为 2 GB。
云观察日志
(不要与高级云观察服务本身混淆，后者更多的是发送指标(
- 这里的想法是将事件数据提交到 CloudWatch 日志
- 它在这里也有一个限制：
事件大小：256 KB(最大值(。此限制无法更改
- 与 SQS 不同，CloudWatch 日志可以自动将日志数据传递到 Lambda，然后可以将其写入您的 SQL 服务器。AWS 文档介绍了如何进行设置。
S3
只需设置一个存储桶并让您的服务器向其写入数据即可。这里的好处是，由于S3用于存储大文件，因此您真的不必担心前面提到的大小限制。S3 存储桶还具有可以触发 lambda 函数的事件。然后，您可以愉快地继续发送徽标数据。
如果您的日志数据变得足够大，您可以横向扩展到 AWS Batch 之类的内容，从而为您提供可用于处理日志数据的容器集群。最后，您还可以获得数据备份。如果您的数据库出现故障，您将日志数据存储在 S3 中，并且可以将脚本放在一起以加载所有内容进行备份。 您还可以使用生命周期策略将旧数据迁移到成本较低的存储，或直接将其全部删除。