如果有 TB 级的日志，如何查询 AWS 负载均衡器日志？

我想查询 AWS 负载均衡器日志，以便自动按计划为我发送报告。

我正在使用 Amazon Athena 和 AWS Lambda 来触发 Athena。我根据此处的指南创建了数据表：https://docs.aws.amazon.com/athena/latest/ug/application-load-balancer-logs.html

但是，我遇到了以下问题：

日志存储桶的大小每天都在增加。我注意到如果 Athena 查询需要超过 5 分钟才能返回结果，有时会产生“未知错误”
因为 AWS Lambda 函数的最大超时时间仅为 15 分钟。因此，我不能继续增加 Lambda 函数超时以等待 Athena 返回结果（例如，如果 Athena 需要 >15 分钟才能返回结果）

你们能给我建议一些更好的解决方案来解决我的问题吗？我正在考虑使用 ELK 堆栈，但我没有使用 ELK 的经验，您能告诉我 ELK 与组合 AWS Lambda + AWS Athena 相比的优缺点吗？谢谢！

首先，您不需要在 Athena 查询执行时保持 Lambda 运行。 StartQueryExecution 返回一个查询标识符，然后您可以使用 GetQueryExecution 轮询该标识符以确定查询何时完成。

当然，如果您将查询作为 Web 请求的一部分来调用，则效果不佳，但我建议您不要这样做。而且，不幸的是，我没有看到 Athena 与 CloudWatch Events 相关联，因此您必须轮询以完成查询。

除此之外，从 Athena 读取访问日志的问题在于对它们进行分区并不容易。 AWS 提供的 example 定义了 Athena 内部的表，默认分区方案使用具有段 /column=value/ 的 S3 路径。但是，ALB 访问日志使用更简单的 yyyy/mm/dd 分区方案。

如果您使用 AWS Glue，您可以define a table format 使用这种更简单的方案。我没有这样做，所以除了文档中的内容之外，无法为您提供信息。

另一种选择是限制存储桶中的数据量。这可以节省存储成本并减少查询时间。我会做类似以下的事情：

Bucket_A 是访问日志的目的地，也是您的 Athena 查询的来源。它有一个生命周期政策，在 30（或 45 或其他）天后删除日志。
Bucket_B 设置为从 Bucket_A 复制日志（以便您永久保留所有内容）。它会立即将所有复制的文件转换为“不经常访问”的存储，从而将成本降低一半。

Elasticsearch 无疑是一个流行的选择。您需要转换文件才能上传。我没有看过，但我确定有一个 Logstash 插件可以做到这一点。根据您希望为报告做什么，Elasticsearch 可能比 Athena 更好或更差。