elasticsearch 使用Lambda vs Firehose和CloudWatch订阅过滤器发布到ElasticSearch

我目前正在研究CloudWatch日志的实时处理。我们每天生成约30-40GB的日志（API网关完整请求/响应），平均每秒约有100个请求。最终，我们希望处理日志，从查询字符串和响应头中提取统计信息，并将结果发布到ElasticSearch或S3

我目前正在研究两种选择，并努力理解这两种选择之间的区别

使用Lambda函数目标创建CloudWatch订阅筛选器。处理Lambda中的数据并发布到ElasticSearch/S3

创建CloudWatch订阅筛选器并从Firehose目标订阅。使用Lambda转换函数提取数据，将其放回流中，并让Firehose将数据发布到ElasticSearch/S3

订阅过滤器基本上会传递包含“转换前的方法请求主体”和“端点响应头：”的记录以供进一步处理

我不知道从CloudWatch订阅过滤器触发Lambda函数是如何发生的。是否涉及任何批处理，或者是否会为订阅筛选器传递的每个日志事件触发批处理？相反，我知道消防水带确实提供了配料，我可以在一定程度上控制

---

有人能就此提供建议吗？还有其他我可能忽略的选择吗？感谢您的任何输入。

您可以使用订阅过滤器将cloudwatch日志与amazon kinesis流连接起来。这样，每当一个新日志与订阅过滤器匹配时，它就会附加到您的kinesis流中。 一旦您的日志位于Kinesis streams中，您就有了很多选择。例如，您可以将其发送到Kinesis Firehose交付流，并可能使用Datatransformation lambda或直接将其转换为Elastic Search e.t.c

假设您已经拥有cloudwatch日志和kinesis流，您需要的cloudformation资源如下：

  KinesisToCloudwatchSubscription:
    Type: AWS::Logs::SubscriptionFilter
    Properties:
      DestinationArn: !GetAtt [your_kinesis_stream, Arn]
      FilterPattern: your_cloudwatch_logstream
      RoleArn: A role that permits the "kinesis:PutRecord" action
      LogGroupName:  "/aws/lambda/your_lambda_function"

---

Elastic Stack 6.5已于11月14日发布，一个名为beat的新版本允许您轻松地将Cloudwatch日志流式传输到ES。我目前也处于同样的情况。您是否就上述选择之一作出结论？哪一个？为什么？我们用消防水带。我对AWS支持有一些讨论，我记得他们说这是处理这种负载的方法。