精通springcloud：分布式日志记录和跟踪

Posted 2021-06-04 jinggege795

分布式日志记录和跟踪

在将一体化应用程序分解为微服务时，开发人员通常会花费大量的时间考虑业务边界或应用程序逻辑的分区，却忘记了日志。根据笔者自己作为开发人员和软件架构师的经验，一方面，可以说很多开发人员通常都不太关注日志记录:而另一方面，负责应用程序维护的操作团队却主要依赖于日志。无论开发人员所关注的领域如何，也无论他们基于的是一体化应用程序还是微服务架构，所有应用程序都必须执行日志记录，这是无可争辩的。

但是，微服务强制为应用程序日志的设计和排列添加了一个全新的维度，因为会有许多小型、独立、水平扩展的互相通信的服务在多台机器上运行：同时，通常会有大量的请求由多个服务处理。开发人员必须将这些请求关联在一起， 并将所有日志存储在一个中心位置，以便更容易查看它们。Spring Cloud引入了一个专用库，实现了分布式跟踪解决方案Spring Cloud Sleuth.

 

这里还有一件事需要讨论。日志记录(Logging) 与跟踪(Tracing)不一样，开发人员有必要了解一下它们之间的差异。跟踪是指跟踪程序的数据流。技术支持团队通常使用它来诊断问题发生的位置。对于开发人员来说，只有在出现错误时才必须跟踪系统流以发现性能“瓶颈”或时间。日志记录用于错误报告和检测。与跟踪相反，它应该始终启用。当设计一个大型系统并希望跨机器进行良好而灵活的错误报告时，一定要考虑以集中方式收集日志数据。推荐和最流行的解决方案是ELK ( Elasticsearch + Logstash +Kibana)堆栈。Spring Cloud中没有用于此堆栈的专用库，但可以使用Java日志框架(如Logback或Log4j)实现集成。Zipkin 将在本章中讨论另一种工具。它是一种典型的跟踪工具，可帮助收集可用于解决微服务架构中的延迟问题的时序数据。

本章将要讨论的主题包括:

口基于微服务的系统中日志记录的最佳实践。

口使用 Spring Cloud Sleuth将跟踪信息附加到消息并关联到事件。

口集成Spring Boot应用程序和Logstash.

口使用 Kibana显示和过滤日志条目。

口使用 Zipkin作为分布式跟踪工具，并通过Spring Cloud Sleuth将其与应用程序集成。

 微服务的最佳日志记录实践

处理日志记录最重要的最佳实践之一是跟踪所有 传入请求和传出响应。也许这对于本章将要讨论的主题包括：

口基于微服务的系统中日志记录的最佳实践。

口使用 Spring Cloud Sleuth将跟踪信息附加到消息并关联到事件。

口集成Spring Boot应用程序和Logstash.

口使用 Kibana显示和过滤日志条目。

口使用 Zipkin作为分布式跟踪工具，并通过Spring Cloud Sleuth将其与应用程序集成。

 微服务的最佳日志记录实践

处理日志记录最重要的最佳实践之一是跟踪所有传入请求和传出响应。也许这对于部分开发人员来说是显而易见的，但我们也曾经看到过一些不符合该要求的应用程序。如果满足此需求，则基于微服务的架构将会产生一个后果，即与没有消息传递的单一应用程序相比，该系统中的日志总数会有所增加。这反过来也会要求开发人员比以前更加关注日志。我们应该尽可能地生成尽可能少的信息，即使这些信息可以告诉我们很多情况。

如何实现这一目标?  首先，在所有微服务中使用相同的日志消息格式就不失为一个良策。例如，可以考虑如何在应用程序日志中打印变量。鉴于通常在微服务之间交换的消息会使用JSON进行格式化，所以建议开发人员使用JSON表示法。此格式具有非常简单的标准，使日志易于阅读和解析。以下就是一个日志的片段。

17:11:53. 712 INFO Order received:

("id":1, "customerId":5, "productId":10 }

上面的格式显然比以下格式更容易分析。

17:11:53.712 INFO Order received with id 1, customerId 5 and productId 10.

但是一般来说，最重要的是标准化。无论选择哪一种格式， 在什么地方使用它才至关重要。开发人员还应该小心确保日志有意义，尽量避免不包含任何信息的句子。例如，从以下格式中完全看不出来正在处理哪个订单。

17:11:53.712 INFO Processing order

但是，如果确实需要这种日志条目格式，则可以尝试将其分配给不同的日志级别。使用相同级别的INFO记录所有内容确实是一种不好的做法。某些类型的信息比其他信息更重要，因而这里的一个难点是确定应记录日志条目的级别。以下是一些建议。

口跟踪(TRACE) : 这是非常详细的信息，仅用于开发模式。可以在部署到生产环境之后将其保留一小段时间，并将其视为临时文件。

口调试(DEBUG) : 在此级别将记录程序中发生的任何事情。这主要用于开发人员的调试或故障排除。DEBUG 和TRACE之间的区别可能是最困难的。

口信息(INFO) : 在此级别应记录操作期间最重要的信息。这些消息必须易于理解，不仅适用于开发人员，也适用于管理员或高级用户，以便让他们快速了解应用程序正在执行的操作。

口警告(WARN): 在此级别将记录可能会出错的所有事件。这样的过程可能会继续，但开发人员应该格外小心。

口错误(ERROR)：通常会在此级别打印异常。这里重要的是不要在所有地方抛出异常，例如，如果只有一个业务逻辑执行没有成功，则不应该影响整个程序。

口致命(FATAL)： 此Java日志记录级别指定可能导致应用程序终止的非常严重的错误事件。

虽然可能还有其他一些很好的日志记录实践，但我们已经提到的都是在基于微服务的系统中使用的最重要的日志实践。关于日志记录，还有一个方面值得一提，那就是规范化。如果开发人员希望轻松理解和解释自己的日志，则应该清楚地了解它们的收集方式和时间、它们包含的内容以及它们释出的原因。应该在所有微服务中规范化一些特别重要的特征，如Time (发生的时间)、Hostname (发生的主机名)和AppName (发生的程序名)。正如9.2 节所示，当在系统中实现集中收集日志的方法时，这种规范化非常有用。

使用Spring Boot记录日志

Spring Boot将使用Apache Commons Logging进行内部日志记录，但是，如果要包含启动器的依赖项，则默认情况下将在应用程序中使用Logback.它不会抑制以任何方式使用其他日志框架的可能性。还为Java Util Logging. Log4J2和SLF4J提供了默认配置。可以在application.yml文件中使用logging.* 属性配置日志记录设置。默认日志输出包含以毫秒为单位的日期和时间、日志级别、进程ID、线程名称、已发出条目的类的全名以及消息。可以通过分别对控制台和文件追加程序使用lgigattem.console 和logging.pttrm.fle属性来覆盖它。

 

默认情况下，Spring Boot仅记录到控制台。除了控制台输出之外，要允许写入日志文件，则应该设置logging file或logging.path属性。如果指定loggfile属性，则日志将在相对于当前目录的确切位置写入文件。如果设置loggingpath, 则会在指定目录中创建spring.log 文件。达到10MB后，日志文件将被轮换(Rotate) 。

application.yml设置文件中可以自定义的最后一件事是日志级别。默认情况下，SpringBoot会使用ERROR、WARN和INFO级别写入消息。我们可以使用logging.level.*属性为每个包或类覆盖此设置。

 

也可以使用logging Jevel.root配置根日志记录器(Root Logger)。以下是application.yml文件中的示例配置，它更改了默认模式格式以及一些日志级别，并设置了日志文件的位置。

logging:

file: logs/order.1og

level :

com.netflix: DEBUG

org。springframework .web. filter . 
CommonsRequestLoggingFilter: DEBUG

pattern:

console: "%d{HH :mm:ss.55S % -5level %msg%n"

file: "%d{HH:mm:88.SSS1 %-51evel %msg%n"

正如上例所示，这样的配置非常简单，但在某些情况下，这还不够。如果要定义其他追加器(Appender) 或过滤器，则应明确包括其中一个可用日志记录系统的配置。这样的日志系统如Logback (logback spring.xml)、Log4j2 ( log4j2-spring.xml)或Java UtilLogging (logging properties)。如前文所述，默认情况下，Spring Boot 将使用Logback作为应用程序日志。如果在类路径的根目录中提供logback-spring.xml 文件，它将覆盖application.yml 中定义的所有设置。例如，开发人员可以创建每天轮换日志的文件追加器，并保留最多10 天的历史记录。

此功能在应用程序中非常实用。9.3 节将会介绍到，在将微服务与Logstash集成时，便需要一个自定义的追加器。以下是Logback 配置文件的示例片段，该片段为logs/order.log文件设置了每日滚动策略。

<configuration>

<appender name="FILE"

class="ch.gos.logback.core. rolling .RollingFileAppender">

<file>1ogs/order.1og</file>

<rollingPolicy

class-"ch.gos. . logback，core . rolling .TimeBasedRollingPolicy">

<fileNamePattern>order.8d{yYyy-MM-dd)。1og</fi1eNamePattern>

<maxHistory>10</maxHistory>

<totalsizeCap>1GB</totalSizeCap>

</rollingPolicy>

<encoder>

<pattern>id(HH:mm:5s.SSS} 8-5leve1 msg8n</pattern>

</encoder>

</appender>

<root level= "DEBUG" >

<appender-ref ref-"FILE" />

</root>

</configuration>

值得一提的是，Spring 建议为Logback 使用logback-spring.xml 而不是默认的logback.xml. Spring Boot包含一些Logback扩展，可能对高级配置有所帮助。它们不能在标准logback.xml中使用，而只能在logback-springxml中使用。我们列出了一些扩展，允许开发人员从Spring环境定义特定于配置文件的配置或接口属性。

<springProperty scope="context" name- ”springAppName"

source=spring。application. name" />

<property name="LOG_FILE" value="S{BUILD FOLDER: -build}/$ (springAppName)"/>

<springProfile name="development">

...

</springProfile>

<springProfile name="production">

<appender name- "flatfile"

class-"ch.qos. logback.core. rolling。RollingFileAppender">

<file>S{L0G_ FILE}</file>

<rollingPolicy

class-"ch。qos. logback. core. rolling。T imeBasedRollingPolicy">

<fileNamePattern>$ (LOG FILE). 8dyyy-M-dd}.gz</fileNamePattern>

<maxHistory>7</maxHistory>

</rolingPolicy>

<encoder>

<pattern>$ (CONSOLE LOG PATTERN}</pattern>

<charset>utf8</charset>

</encoder>

</appender>

...

</ springProfile>

总结

还有很多资料就不一一分享出来了，有需要的朋友可以下方扫码来获取！