结构化日志记录
当我学习使用 AWS Lambda 和 Java 编写无服务器函数时，我遇到了结构化日志记录的概念。这让我对结构化日志的概念很好奇，所以我决定进一步探索它。
什么是结构化日志记录？
通常，应用程序生成的任何日志都是以某种方式格式化的纯文本。
例如，这是来自 Java 应用程序的典型日志格式：
[Sun Apr 02 09:29:16 GMT] 域名herEventLambda INFO: [locationName: London, UK temperature: 22 action: record timestamp: 1564428928]
虽然这个日志是格式化的，但它不是结构化的。
我们可以看到它被格式化为以下组件：
时间戳（发生时）
完全合格的类名（从它出现的地方）
记录级别（事件类型）
消息（这部分通常是非标准化的，因此从某种结构中获益最多，正如我们将看到的那样）
结构化日志不使用纯文本格式，而是使用更正式的结构，例如 XML 或更常见的 JSON。
如果它是结构化的，那么之前显示的日志会像这样：
请注意，message日志的这一部分是您通常感兴趣的内容。但是，消息周围有一大堆元数据，这些元数据在您尝试执行的操作的上下文中可能有用，也可能没有用。
根据您使用的日志记录框架，您可以自定义显示的元数据。上面显示的示例是通过Log4J2日志框架从AWS Lambda函数（用 Java 编写）生成的。
配置如下所示：
<?xml version="1.0" encoding="UTF-8"?> <Configuration packages="域名域名域名j2"> <Appenders> <Lambda name="Lambda"> <JsonLayout compact="true" eventEol="true" objectMessageAsJsonObject="true" properties="true"/> </Lambda> </Appenders> <Loggers> <Root level="info"> <AppenderRef ref="Lambda"/> </Root> </Loggers> </Configuration>
在这种情况下，标签JsonLayout告诉记录器使用结构化格式（即）JSON。
请注意，我们将其用作 INFO 级别日志的附加程序，这意味着其他级别的日志（例如ERROR或DEBUG）将不会被结构化。在我看来，这种灵活性是有益的，因为您可能不想构建所有日志，而只想构建您认为需要参与监控或分析的部分。
以下是生成日志的 AWS Lambda 函数的片段。它读取一个天气事件，用要记录的值填充一个地图，然后将该地图传递给记录器。
final WeatherEvent weatherEvent = 域名Value(域名ody(), 域名s);
HashMap<Object, Object> message = new HashMap<>();
域名("action", "record");
域名("locationName", 域名tionName);
域名("temperature", 域名erature);
域名("timestamp", 域名stamp);
域名(new ObjectMessage(message));有不同的方法可以实现这一点。您可以编写自己的类来实现 Log4J2 的接口，然后填充此类实例的字段并将该实例传递给记录器。
那么，这一切的意义何在？
为什么要构建日志？
要回答这个问题，请假设您有一堆原木（例如实际的原木）：
如果我对您说，“检查左下角顶部的日志”，您将不得不猜测我指的是哪一个。
现在考虑将这些日志构造成一个舱室。
现在，如果我对你说，“检查构成前门的原木”，那么你就知道该看哪里了。
这就是结构好的原因。它使查找内容变得更加容易。
查询您的日志
可以通过AWS CloudWatch、Kibana和Splunk等监控工具有效地为结构化日志建立索引。这意味着找到您想要的日志变得更加容易。这些工具提供了查询日志的复杂方法，使故障排除或执行分析变得更加容易。
例如，此屏幕截图显示了如何在 AWS CloudWatch Insights 中搜索发生牛津天气事件的日志。我们指的是日志组件locationName下的属性。message
您可以通过过滤和排序进行更复杂的查询。例如，您可以说，“显示温度高于 20 度的前 10 个天气事件”（在英国很少见）。
从日志中触发事件
能够查询日志的另一个好处是您可以开始衡量事物。然后可以使用这些测量（在 AWS CloudWatch 中称为指标 ）来触发事件，例如发送通知。
在 AWS 中，这将通过创建一个表示您要测量的指标，然后根据该指标的条件设置CloudWatch 警报并使用该警报触发通知（例如，SNS）来实现。
例如，如果您想在伦敦温度超过 20 度时发送一封电子邮件，您可以为伦敦在一段时间内（比如 5 小时）的平均温度读数创建一个指标，然后创建一个将激活的警报当这个指标超过 20 度时。然后可以使用此警报触发对 SNS 主题的通知。然后将通知 SNS 主题的订户，以便他们知道不要穿暖和的衣服。
结构化日志有缺点吗？
关于是否使用结构化日志的决定应该由您为系统设想的整体监控和分析策略驱动。例如，如果您有一个无服务器应用程序，它是与其他服务相关的更广泛系统的一部分，那么集中这些不同服务的日志是有意义的，这样您就有一个统一的系统视图。在这种情况下，将日志结构化将极大地帮助监控和分析。
另一方面，如果您有一个非常简单的应用程序，它只提供来自单个数据源的数据并且不链接到其他服务，则您可能不需要构建日志。我们不要忘记那句古老的格言：保持简单，愚蠢。
因此，要回答“结构化日志有缺点吗？”这个问题 - 仅当您在不需要的地方使用它时。当使用简单的日志就可以正常工作时，您不想花时间进行额外的配置并且不必考虑结构。
结论
结构化日志记录不仅可以帮助您更有效地分析日志，还可以帮助您在系统中构建更好的监控功能。除此之外，还可以通过相关查询和设置指标和通知来增强业务分析，这些指标和通知可以表明系统中的趋势。
简而言之，结构化日志记录不仅仅是日志记录。它是一种驱动架构模式的工具，可增强监控和分析。
