两个Lambda用户的故事 (A Tale of Two Lambda Users)

故事1：业余 (Tale #1: The Amateur)

One moment everything is fine, then … Bam! Your Lambda function raises an exception, you get alerted and everything changes instantly.

一会儿一切都好，然后……Bam！ 您的Lambda函数引发异常，您将收到警报，并且所有内容都会立即更改。

Critical systems could be impacted, so it’s important that you understand the root cause quickly.

关键系统可能会受到影响，因此快速了解根本原因非常重要。

Now, this isn’t some low-volume Lambda where you can scroll through CloudWatch Logs and find the error in purely manual fashion. So instead you head to CloudWatch Insights to run a query on the log group, filtering for the error:

现在，这不是小批量的Lambda，您可以在其中滚动浏览CloudWatch Logs并以纯手工方式查找错误。 因此，您转而使用CloudWatch Insights在日志组上运行查询，以过滤错误：

Looks like we found our error! While helpful, unfortunately it omits any other log messages associated with the failed invocation.

看起来我们发现了错误！ 虽然有用，但不幸的是，它忽略了与失败的调用相关的任何其他日志消息。

With just the information shown above maybe — just maybe — you can figure out what the root cause is. But more likely than not, you won’t be confident.

仅通过上面显示的信息，也许-也许-您就可以找出根本原因了。 但是您很有可能不会自信。

Do you tell people you aren’t sure what happened and that you’ll spend more time investigating if the issue happens again? As if!

您是否告诉人们您不确定发生了什么，并且您将花费更多的时间调查问题是否再次发生？ 仿佛！

So instead you head to the CloudWatch Logs Log Stream, filter records down to the relevant timestamp, and begin manually scrolling through log messages to find the full details on the specific errored invocation.

因此，您可以转至CloudWatch Logs日志流，过滤记录到相关时间戳，然后开始手动滚动日志消息以查找有关特定错误调用的完整详细信息。

Resolution Time: 1–2 hoursLambda Enjoyment Usage Index: Low

解决时间： 1-2小时Lambda享受使用率指数：低

故事2：专业人士 (Tale #2: The Professional)

Same Lambda function, same error. But this time the logging and error handling are improved. As the title implies, this involves replacing print() statements with something a ‘lil better.

相同的Lambda函数，相同的错误。 但是这次日志和错误处理得到了改善。 顾名思义，这涉及用更好的东西代替print()语句。

What is that something and what does this Lambda function look like anyway? Let’s first go through what error debugging looks like for the professional, then take a look at code. Fair?

那是什么东西，这个Lambda函数到底是什么样的？ 让我们首先了解一下专业人员的错误调试，然后看一下代码。 公平？

Again, we start with an Insights query:

同样，我们从一个Insights查询开始：

And again we find the error in the logs, but unlike last time, the log event now includes the @requestId from the Lambda invocation. What this allows us to do is run a second Insights query, filtered on that requestId to see the full set of logs for the exact invocation we are interested in!

我们再次在日志中找到错误，但是与上次不同，该日志事件现在包括来自Lambda调用的@requestId 。 这使我们能够执行的是运行第二个Insights查询，该查询根据该requestId进行过滤，以查看我们感兴趣的确切调用的完整日志集！

Now we get 5 results, which together paint the full crime scene picture of what happened for this request. Most helpfully, we immediately see the exact input passed to trigger the Lambda. From this we can either deduce what happened mentally, or run the Lambda code locally with the exact same input event to debug.

现在我们得到5个结果，这些结果共同描绘了此请求发生的全部犯罪现场图片。 最有用的是，我们立即看到传递来触发Lambda的确切输入。 由此，我们可以推断出发生的事情，或者使用完全相同的输入事件在本地运行Lambda代码进行调试。

Resolution Time: 10–20 minutesLambda Enjoyment Usage Index: High!

解决时间： 10–20分钟Lambda享受使用率指数：高！

守则揭示 (The Code Reveal)

I’d like to imagine my readers are on the edge of their seats, begging to know the difference between the Amateur and the Pro’s code from the tale above.

我想想象我的读者坐在座位上，乞求从上面的故事中了解Amateur和Pro的代码之间的区别。

Whether that’s true or not, here is the Amateur Lambda:

不管是不是真的，这是Amateur Lambda：

It is, of course, intentionally simple for illustrative purposes. Errors were generated by simply passing an event dictionary without artist as a key, for example: event = {'artisans': 'Leonardo Da Vinci'}.

当然，出于说明目的，它是故意简单的。 只需通过不带artist作为关键字的事件字典即可生成错误，例如： event = {'artisans': 'Leonardo Da Vinci'} 。

Now for the Professional Lambda, which performs the same basic function but improves upon the print() statements and error handling.

现在是Professional Lambda，它执行相同的基本功能，但改进了print()语句和错误处理。

Interesting! So why are we using the logging module and formatting exception tracebacks?

有趣！ 那么，为什么我们要使用日志记录模块并对异常回溯进行格式化？

可爱的Lambda记录 (Lovely Lambda Logging)

First, the Lambda runtime environment for python includes a customized logger that is smart to take advantage of.

首先，适用于python的Lambda运行时环境包括一个自定义的记录器 ，可以很好地利用它。

It features a formatter that, by default, includes the aws_request_id in every log message. This is the critical feature that allows for an Insights query, like the one shown above that filters on an individual @requestId, to show the full details of one Lambda invocation.

它具有一个格式化程序 ，默认情况下，每个日志消息中都包含aws_request_id 。 这是允许Insights查询的关键功能，就像上面显示的对单个@requestId过滤的显示@requestId ，以显示一个Lambda调用的完整详细信息。

异常处理 (Exceptional Exception Handling)

Next, you are probably noticing the fancy error handling. Although intimidating looking, using sys.exec_info is the standard way to retrieve information about an exception in python.

接下来，您可能会注意到奇特的错误处理。 尽管令人生畏，但使用sys.exec_info是检索有关python中异常的信息的标准方法 。

After retrieving the exception name, value, and stacktrace , we format it into a json-dumped string so all three appear in one log message, with the keys automatically parsed into fields. This also makes it easy to create custom metrics based off specific errors without requiring complex string parsing.

检索到异常的名称，值和stacktrace之后，我们将其格式化为json转储的字符串，以便所有三个都出现在一条日志消息中，并且键自动解析为字段。 这也使基于特定错误创建自定义指标变得容易，而无需复杂的字符串解析。

Lastly, it is worth noting that in contrast, logging an exception with the default Lambda logger without any formatting results in an unfortunate multi-line traceback looks something like this:

最后，值得注意的是，相比之下，使用默认的Lambda记录器记录异常而未进行任何格式化会导致不幸的多行回溯，如下所示：

结语 (Wrapping Up)

I hope if your Lambda functions look more like the Amateur Lambda at the moment, this article inspires you to upgrade your dance and go Pro!

我希望目前您的Lambda函数看起来更像是业余Lambda，这篇文章可以激发您升级舞蹈并升级为Pro！

Before I let you go, I should warn that the downside to replacing print statements with proper logging is that you lose any terminal output generated from local executions of your Lambda.

在我放手之前，我应该警告说，用正确的日志记录替换打印语句的弊端是，您会丢失Lambda的本地执行所生成的任何终端输出。

There are clever ways around this involving either environment variables or some setup code in a lambda_invoke_local.py type of file. If interested, let me know and I’ll be happy to go over the details in a future article.

有许多解决方法，其中包括环境变量或lambda_invoke_local.py类型的文件中的某些设置代码。 如果有兴趣，请告诉我，我将很乐意在以后的文章中详细介绍。

Lastly, as a final bit of inspiration, instead of needing to run Cloudwatch Insights queries to debug yourself, it should be possible to set up an Alarm against the Lambda Errors metric that notifies an SNS topic when in state “In Alarm”. Another Lambda could then trigger off that SNS topic to run the same debugging Insights queries as the Pro automatically, and return the relevant logs in Slack or something.

最后，作为最后的启发，无需运行Cloudwatch Insights查询来调试自己，应该可以针对Lambda错误度量标准设置警报，该警报在处于“ In Alarm”状态时通知SNS主题。 然后，另一个Lambda可以触发该SNS主题，以自动运行与Pro相同的调试Insights查询，并以Slack或其他形式返回相关日志。

Would be cool, no?

会很酷，不是吗？