我正在尝试找到集中式解决方案来从数据库（RDS）移动我的应用程序日志记录。
我在考虑使用CloudWatchLog，但注意到PutLogEvents请求有限制：
PutLogEvents请求的最大速率是每秒5个请求 每个日志流。
即使我将我的日志分成许多流（基于EC2，日志类型 - 错误，信息，警告，调试），限制为5 req。对于活动应用程序，每秒仍然是非常严格的限制。
另一个解决方案是以某种方式累积日志并发送批处理日志记录的PutLogEvents，但这意味着我被迫使用数据库来累积该记录。
所以问题是：
答案 0 :(得分：3)
PutLogEvents旨在根据定义放置几个事件（根据它的名称：PutLogEvent＆＃34; S＆＃34;）:) Cloudwatch日志代理正在单独执行此操作，您不必担心这个问题。
但请注意：我建议您不要生成大量日志（例如，不要在生产中运行调试模式），因为随着日志量的增长，cloudwatch日志会变得非常昂贵。 / p>
答案 1 :(得分：0)
我的建议是在AWS实例上使用Logstash解决方案。
或者，您可以在另一个现有实例或容器上运行logstash。
https://www.elastic.co/products/logstash
它专为此范围而设计，并且非常出色。
Cloudwatch，主要不是为您的需求而设计的。
我希望这会有所帮助。
答案 2 :(得分：0)
如果您直接从您的应用程序调用此API：简短的答案是您需要批量记录事件（PutLogEvent s <5>为5）。
如果您正在将日志写入磁盘，之后您正在推送它们，那么已经有一个知道如何推送日志的代理（http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/QuickStartEC2Instance.html）
Meta：我建议您对此进行原型设计，并确保它适用于您拥有的日志卷。另外，请记住，由于cloudwatch api的工作原理，一次只有一个应用程序/用户可以推送到日志流（请参阅您必须传入的令牌） - 这样您可能需要使用多个流，每个用户/每个日志类型一个，以确保您的应用程序不竞争日志。
Meta Meta：考虑一下如果日志记录子系统出现故障，您的应用程序将如何运行，以及您是否可能会丢失日志（即，您始终/始终保证获取日志的关键是至关重要的吗？ ）。这可能会推动你做的事情/你最终选择的解决方案。