我想记录完整的请求+响应，包括。 body 在 AWS Lambda 代理中的 API 网关上接收，同时将处理请求传递到不同的服务器(如反向代理请求)。因为从 API 网关到 CloudWatch 的标准日志记录会在 1024 字节后截断请求/响应，所以我无法使用此选项。 所以处理看起来像这样:
请求 -> API 网关 -> Lambda 以记录完整请求，包括。正文 -> 公共(public) API 端点 -> 响应 -> Lambda 记录完整响应，包括。正文 -> API 网关 -> 响应
对于这种情况是否有已知的解决方案？
最佳答案
您可能有充分的理由这样做，但请确保您意识到记录完整的请求/响应正文可能会产生很多不良影响。
例如，如果您的服务需要遵守 GDPR，这是一个大问题。此外，它可能会极大地影响性能并使您遇到一些与配额相关的问题。基本上，这样做通常不是一个好主意。
如果 1K 限制不是问题，那么将这些日志存储在 cloudwatch 上将是最简单的请求选项。如果您只有一堆请求，这还不够，您可以考虑将它们视为异常(exception)。
您可以使用 S3/DynamoDB/Elastic Search，具体取决于您要使用它们做什么，并且也需要权衡取舍。
S3 - 这将允许存储非常大的请求/响应，但它会产生大量碎片。您最终可能会得到很多小文件，并且还需要某种索引(可能将 S3 key 存储在 cloudwatch 日志中)。在这种情况下，搜索可能会有些痛苦(尽管您可以使用 Athena，具体取决于您如何存储它)。
DynamoDB - 易于存储，但如果您的 API 访问过于频繁，您可能会遇到很多配额限制。您可能需要大幅增加成本以防止它们发生。此外，每条记录都有 400Kb 的限制。我个人不推荐这种方法。
ElasticSearch - 默认记录大小限制为 100Mb，但可以增加。这将使以后查询此数据变得容易。
鉴于此线程拥有的信息量，我认为 ElasticSearch 可能更适合这种情况。此外，根据数量的不同，其中一些解决方案最终需要一些发布-订阅机制(例如 Kinesis)来处理突发限制和消息分组(例如，如果您是 S3，您可能希望将多个条目分组到一个单个文件)
关于amazon-web-services - 通过 Labmbda 代理在 API 网关中记录请求/响应，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/61241488/