我写了一个简单的lambda函数(在python 3.7中(，每天运行一次，它可以在创建新分区时更新我的Glue数据目录。它是这样工作的：
- 在特定S3位置创建对象异步触发函数
- lambda从事件中提取密钥(例如：s3://my bucket/path/to/object/(
- 通过AWS SDK，lambda询问glue分区是否已经存在
- 如果没有，则创建新分区。如果是，则终止该过程
此外，该函数有3个打印语句：
- 一开始就说它开始执行
- 中间的一个，表示分区是否存在
- 一个在最后，一旦成功执行
此函数每次调用的平均执行时间为460ms，分配了128MB RAM，并且它的并发执行次数不能超过12次(因为12是每天可以生成的新分区的最大数量(。没有其他lambda函数同时运行，可能会窃取并发容量。此外，为了确定起见，我已经将超时限制设置为10秒。
几周来，它一直在完美地工作，除了今天早上，其中2次执行在达到10秒的限制后超时，这很奇怪，因为它比平均持续时间大了20倍。
最让我惊讶的是，在一种情况下，只有第1条打印语句记录在CloudWatch中，而在另一种情况中，甚至没有记录，就好像函数被调用了，但从未真正启动过进程。
我不知道是什么原因造成的。任何想法或建议都将不胜感激。
可能AWS的服务有问题，我也遇到了同样的问题。
不确定它是否有帮助。您可以查看：
https://status.aws.amazon.com
[CloudFront High Error Rate]
4:28 PM PDT我们正在调查错误率和多个边缘位置的延迟。下午5:08 PDT我们可以确认从多个位置访问内容的错误率和高延迟提高边缘位置，这也导致了比平时更长的时间CloudFront配置更改的传播时间。我们有找出根本原因并继续努力解决问题。5:54PM PDT我们开始看到错误率上升的恢复以及从多个边缘位置访问内容的高延迟。错误除欧洲外，所有地区的房价都有所回升。此外，我们继续努力为将配置更改传播到Cloudfront的延迟分配。下午6:21 PDT从下午3:18 PDT开始，我们经历了从多个位置访问内容的错误率和高延迟提高边缘位置。错误率的提高和延迟的增加访问内容在PDT下午5:48完全恢复。在此期间随着时间的推移，客户可能也经历了比平时更长的变化CloudFront配置的传播延迟和无效。CloudFront配置更改和无效的积压工作PDT下午6:14完全处理。所有问题都已完全解决并且系统运行正常