如何实现Cloudwatch应用日志到Logstash的实时流式传输？

以下方案均可以实现秒级到亚分钟级的日志同步，完全满足实时性要求：

方案1：CloudWatch Logs订阅过滤器 + 中转Lambda + Logstash HTTP输入 #

轻量低成本方案，适合中小规模日志量场景：

• 为目标Lambda对应的CloudWatch日志组配置订阅过滤器，全量同步可留空过滤模式，触发目标选择自定义中转Lambda
• 中转Lambda仅需做简单的格式处理：解压订阅过滤器推送的gzip压缩日志包，提取原始日志字段后批量POST到Logstash的HTTP输入端点
• Logstash侧开启http输入插件，配置对应端口、鉴权规则即可
  该方案端到端延迟通常<10秒，无需额外中间存储，资源消耗极低

方案2：CloudWatch Logs订阅过滤器 + Kinesis Data Streams + Logstash Kinesis输入 #

高可靠高吞吐方案，适合大规模日志生产场景：

• 为目标日志组配置订阅过滤器，推送目标选择Kinesis数据流，CloudWatch会自动将实时生成的日志写入数据流，数据保留时长可自定义配置
• Logstash侧使用官方logstash-input-kinesis插件拉取Kinesis流中的日志数据，解析后进入后续处理链路
  该方案支持每秒GB级的日志吞吐，数据流自带缓存能力，不会因Logstash临时故障丢失日志，端到端延迟<30秒

方案3：优化原有非官方CloudWatch Logstash插件配置 #

如果不想改动现有链路，可通过调整配置解决延迟问题：

• 调低poll_interval参数到10-30秒，该参数默认配置通常为5分钟甚至更高，是导致.sincedb文件滞后、日志拉取延迟的核心原因
• 新增log_group_prefix参数拆分日志组拉取任务，通过多线程并行拉取不同日志组的数据，避免单线程拉取大量日志导致堆积
• 适当降低batch_size参数，避免单次拉取数据量过大导致处理耗时过长
  调整配置后多数场景可将延迟控制在1分钟以内

你提到的Filebeat AWS模块基于S3导出的方案本身依赖CloudWatch的异步批量导出能力，天然不支持实时场景，无需考虑。

内容的提问来源于stack exchange，提问作者Prim