编程 AWS Lambda

第 7 章 日志、指标和跟踪

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在本章中，我们将探讨如何通过日志、度量和跟踪来增强 Lambda 函数的可观察性。通过 日志，您将了解如何从 Lambda 函数执行过程中发生的特定事件中获取信息。平台 和业务度量将让您深入了解无服务器应用程序的运行健康状况。最后，分布式 跟踪将让您了解请求是如何流向构成我们架构的不同托管服务和组件的。

我们将使用第 5 章中的 Weather API 来探索 AWS 上无服务器应用程序可用的各种日志、度量和跟踪选项。 与我们在第 6 章中所做的数据管道更改类似，您会注意到 Weather API Lambda 函数已重构为使用aws-lambda-java-events 库。

记录

给定 以下日志信息，我们可以推断出生成该日志信息的应用程序的状态如何？

Recorded a temperature of 78 F from Brooklyn, NY

我们知道一些数据的值（温度测量值和位置），但其他的就不知道了。 这些数据是什么时候接收或处理的？ 在我们应用程序的大背景下，是什么请求产生了这些数据？ 是哪个 Java 类和方法产生了这条日志信息？ 我们如何将其与其他可能相关的日志信息联系起来？

从根本上说，这是一条无用的日志信息。 它缺乏上下文和具体内容。 如果这样的信息重复出现成百上千次（可能使用不同的温度或位置值），它就会失去意义。 当我们的日志信息是散文（例如，一个句子或短语）时，如果不使用正则表达式或模式匹配，它们就更难解析。

在我们探索 Lambda 函数中的日志记录时，请牢记高价值日志信息的几个属性：

数据丰富

我们希望在可行和符合成本效益的情况下获取尽可能多的数据。我们掌握的数据越多，就能提出越多的问题，而不必事后再去增加记录。

卡片数量多

使特定日志信息具有唯一性的数据值尤为重要。 例如，请求 ID 这样的字段会有大量唯一值，而线程优先级这样的字段可能没有（尤其是在单线程的 Lambda 函数中）。

机器可读

使用 JSON 或其他易于机器读取的标准化格式（无需自定义解析逻辑），将便于下游工具进行分析。

CloudWatch 日志

CloudWatch Logs 顾名思义，是 AWS 的日志收集、汇总和处理服务。它通过各种机制接收来自应用程序和其他 AWS 服务的日志数据，并通过 Web 控制台以及 API 访问这些数据。

CloudWatch 日志的两个主要组织组件是日志组和日志流。 日志组是一组相关日志流的顶层分组。 日志流是日志消息列表，通常源自单个应用程序或功能实例。

Lambda 和 CloudWatch 日志

在 无服务器应用程序中，默认情况下每个 Lambda 函数有一个日志组，其中包含许多日志流。每个日志流包含特定函数实例的所有函数调用的日志信息。 回顾第 3 章，Lambda 运行时会捕获写入标准输出（Java 中为System.out ）或标准错误（System.err ）的任何内容，并将这些信息转发到 CloudWatch Logs。

Lambda 函数的日志输出看起来像这样：

START RequestId: 6127fe67-a406-11e8-9030-69649c02a345 Version: $LATEST Recorded a temperature of 78 F from Brooklyn, NY END RequestId: 6127fe67-a406-11e8-9030-69649c02a345 ...