所以我试图找到一个奇怪的bug的来源,这个bug导致特定lambda函数的异常调用峰值。到目前为止,我已经为lambdas添加了日志记录功能,并重新部署以收集有关触发lambda的上下文和事件对象的更多信息。
所以我想知道这些事件的起源,并且从那些上述记录的事件对象中我发现了TopicArn是罪魁祸首,但我如何在这种关系中寻找有罪的发布者呢?我忽视的任何想法或事物?
答案 0 :(得分:4)
您是否启用了CloudTrail?您应该能够将CloudTrail用于log all the calls to your SNS topics。
答案 1 :(得分:1)
根据您的记录方式,您可能还希望将SQS队列附加到主题。这将为您提供完整的数据包。我可以在我的一个中看到有类似的东西:
{
"version": "0",
"id": "7f47b81a-10cc-4b28-be35-123456789",
"detail-type": "Scheduled Event",
"source": "aws.events",
"account": "123456789",
"time": "2017-02-03T18:28:52Z",
"region": "us-east-1",
"resources": [
"arn:aws:events:us-east-1:123456789:rule\/5_min_scheduler"
],
"detail": {
}
}
显然,这是来自云观察预定的事件,但它确实有一个来源。我不确定你会不会这样做,但除了Lambda之外,还有一个主题推送到队列以帮助调试。