skywalking日志收集

本文涉及的产品
应用实时监控服务ARMS - 应用监控,每月50GB免费额度
日志服务 SLS,月写入数据量 50GB 1个月
简介: skywalking日志收集

一、介绍

在上一篇文章skywalking全链路追踪中我们介绍了在微服务项目中使用skywalking进行服务调用链路的追踪。

本文在全链路追踪的基础上,我们介绍如何使用skywalking对一次调用链路上进行日志收集

skywalking日志收集方式有两种:

  • 日志文件中收集

    在微服务项目中,每一个微服务所产生的日志均会保存到本地日志文件远程文件服务器中,skywalking提供FilebeatFluentdFluent-bit三种方式通过kafkahttp读取日志文件并将其按照调用链路进行收集。

    • Filebeat

      此方式应用于本地日志文件场景。由使用kafka进行日志收集,需要在skywalking客户端的配置文件agent.conf和服务端的配置文件application.yml中对kafka-fetcher进行配置,并在skywalking客户端添加配置文件filebeat.yml

    • Fluentd

      此方式应用于本地日志文件场景。使用kafka进行日志收集,需要在skywalking客户端的配置文件agent.conf和服务端的配置文件application.yml中对kafka-fetcher进行配置,并在skywalking客户端添加配置文件fluentd.conf

    • Fluent-bit

      此方式应用于远程文件服务器场景。使用http进行日志收集,需要在skywalking服务端的配置文件application.yml中对corereceiver-sharing-serverrestHost:restPort项进行配置。并添加配置文件fluent-bit.conf

  • skywalking客户端收集

    在微服务项目中,每一个微服务都会有一个日志配置文件用于规范日志的输出格式。skywalking客户端提供了工具将输出的日志通过消息队列(如kafka)http发送到skywalking服务端。此方式只需要对日志配置文件进行修改。

    skywalking支持的日志框架有:log4jlog4j2logback

我们本次的日志收集演示采用从skywalking客户端收集的方式,并使用springboot推荐的日志框架logback

二、添加依赖

在各个微服务的pom.xml中添加以下依赖

<dependency>
    <groupId>org.apache.skywalking</groupId>
    <artifactId>apm-toolkit-logback-1.x</artifactId>
    <version>8.9.0</version>
</dependency>

三、修改日志配置

在我们添加的依赖apm-toolkit-logback-1.x中,包含了大量适配于logback与skywalking的AppenderEncoder以及Layout实现类。下面我们需要对日志配置文件进行修改。

在微服务系统的一次请求调用链中,可能出现多个服务之间相互调用的场景(如商品服务调用订单服务,订单服务调用支付服务)。而这些服务显然处于不同的进程甚至不同的服务器,如何确定一个请求的调用链路中调用了哪些服务呢?

1. 添加链路表示traceId

skywalking使用traceId对调用链路进行标识,traceId的格式为随机字符,如果没有请求链路,则输出日志中的traceIdN/A。如果以羊肉串类比,多个羊肉被同一个棍子串起来,羊肉就类比为链路上的多个服务,棍子就类比为traceId

修改logback.xml日志配置文件

  • 在日志的输出格式定义中添加%tid,并修改对应的Layout实现类为TraceIdPatternLogbackLayout

    <?xml version="1.0" encoding="UTF-8"?>
    <configuration>
    
        <!-- 日志输出格式 -->
        <property name="log.pattern"
                  value="%black(%contextName-) %red(%d{yyyy-MM-dd HH:mm:ss}) %green([%thread]) %boldMagenta([%tid]) %highlight(%-5level) %boldMagenta(%logger{36}) - %gray(%msg%n)"/>
    
        <!-- 控制台输出 -->
        <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
            <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
                <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayout">
                    <Pattern>${log.pattern}</Pattern>
                </layout>
            </encoder>
        </appender>
    
        <root level="info">
            <appender-ref ref="console"/>
        </root>
    </configuration>
    
  • 没有请求链路的系统日志

    traceId为空的日志.png

  • 当我们向接口发送请求时

    请求如下:

    商品id为1的请求.png

日志如下,从输出的日志可以看到,该请求的调用链为8012端口的商品服务调用8021端口的订单服务8021端口的订单服务调用8032端口的支付服务,在该调用链上各个服务的traceId相同。

traceId不为空的日志.png

进入skywalking服务端的页面,我们查看该调用链路,该链路的traceId与日志中打印的traceId一致。

traceId不为空的调用链路页面.png

2. 添加链路上下文

由于traceId仅表示为随机字符,可读性较差。幸运的是,skywalking也认识到这一点,于是又引入了一个新的概念:链路上下文SW_CTX,所谓链路上下文,其实与traceId的作用相同,但他的好处是可读性强,其格式为SW_CTX:[服务名, 实例名, traceId, traceSegmentId, spanId]

同样的,如果没有请求链路,则输出日志中的链路上下文SW_CTX:[服务名, 实例名, N/A, N/A, -1]

修改logback.xml日志配置文件

  • 将日志的输出格式定义中表示traceId%tid修改为%sw_ctx即可

    <?xml version="1.0" encoding="UTF-8"?>
    <configuration>
    
        <!-- 日志输出格式 -->
        <property name="log.pattern"
                  value="%black(%contextName-) %red(%d{yyyy-MM-dd HH:mm:ss}) %green([%thread]) %boldMagenta([%sw_ctx]) %highlight(%-5level) %boldMagenta(%logger{36}) - %gray(%msg%n)"/>
    
        <!-- 控制台输出 -->
        <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
            <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
                <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayout">
                    <Pattern>${log.pattern}</Pattern>
                </layout>
            </encoder>
        </appender>
    
        <root level="info">
            <appender-ref ref="console"/>
        </root>
    </configuration>
    
  • 重启项目,查看没有请求链路的系统日志

    上下文为空的日志.png

  • 当我们向接口发送请求时

    请求如下

    商品id为2的请求.png

日志如下,由于打印出的上下文日志包含信息量过长,只截取其部分日志。

上下文不为空的日志.png

进入skywalking服务端的页面,我们查看该调用链路,该调用链路同样是商品服务的8011端口服务调用订单服务的8022端口服务,且该调用链的traceId与日志中打印的traceId一致。

上下文不为空的调用链路页面.png

3. 异步日志

skywalking客户端还支持日志的异步打印,就是说业务代码与日志打印采用不同的线程执行,提高接口响应速度。

修改logback.xml日志配置文件

<?xml version="1.0" encoding="UTF-8"?>
<configuration>

    <!-- 日志输出格式 -->
    <property name="log.pattern"
              value="%black(%contextName-) %red(%d{yyyy-MM-dd HH:mm:ss}) %green([%thread]) %boldMagenta([%tid]) %highlight(%-5level) %boldMagenta(%logger{36}) - %gray(%msg%n)"/>

    <!-- 控制台输出 -->
    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
            <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayout">
                <Pattern>${log.pattern}</Pattern>
            </layout>
        </encoder>
    </appender>

    <!-- 异步输出 -->
    <appender name="console-async" class="ch.qos.logback.classic.AsyncAppender">
        <discardingThreshold>0</discardingThreshold>
        <queueSize>1024</queueSize>
        <neverBlock>true</neverBlock>
        <appender-ref ref="console"/>
    </appender>

    <root level="info">
        <appender-ref ref="console-async"/>
    </root>
</configuration>

四、收集链路日志

skywalking客户端通过gRpc将输出的日志发送给skywalking服务端,skywalking服务端根据traceId去分析日志,然后通过skywalking服务端页面可以查看指定调用链路中所有服务所输出的日志。

  • 修改logback.xml日志配置文件,只需要添加GRPCLogClientAppender即可

    <?xml version="1.0" encoding="UTF-8"?>
    <configuration>
    
        <!-- 日志输出格式 -->
        <property name="log.pattern"
                  value="%black(%contextName-) %red(%d{yyyy-MM-dd HH:mm:ss}) %green([%thread]) %boldMagenta([%tid]) %highlight(%-5level) %boldMagenta(%logger{36}) - %gray(%msg%n)"/>
    
        <!-- 控制台输出 -->
        <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
            <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
                <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayout">
                    <Pattern>${log.pattern}</Pattern>
                </layout>
            </encoder>
        </appender>
        <!-- 异步输出 -->
        <appender name="console-async" class="ch.qos.logback.classic.AsyncAppender">
            <discardingThreshold>0</discardingThreshold>
            <queueSize>1024</queueSize>
            <neverBlock>true</neverBlock>
            <appender-ref ref="console"/>
        </appender>
        <!-- 使用gRpc将日志发送到skywalking服务端 -->
        <appender name="grpc-log" class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.log.GRPCLogClientAppender">
            <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
                <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayout">
                    <Pattern>${log.pattern}</Pattern>
                </layout>
            </encoder>
        </appender>
    
        <root level="info">
            <appender-ref ref="console-async"/>
            <appender-ref ref="grpc-log"/>
        </root>
    </configuration>
    
  • 重启项目,并向接口发送请求

    商品id为1的请求.png

  • 查看输出的日志

    日志收集-1.png

  • 进入skywalking页面查看

    日志收集-2.png

  • 查看该调用链路上各服务的日志,我们以商品服务的日志为例,在调用链路中电击商品服务,可查看对应的实例详情,再点击相关的日志,即可查看商品服务该实例所产生的日志列表,该列表中每一行即为代码中打印的一行日志,点击可查看该行完整的日志信息。

    日志收集-3.png


到这里,skywalking的日志收集我们就介绍完了。




纸上得来终觉浅,绝知此事要躬行。

————————我是万万岁,我们下期再见————————

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
消息中间件 监控 Java
skywalking06 - skywalking也可以作为日志中心收集日志了!
skywalking06 - skywalking也可以作为日志中心收集日志了!
773 0
|
监控 开发者
血泪经验:使用SkyWalking 和 Envoy 访问日志服务对 istio 进行观察(一)
经过华为和 skywalking 核心开发者的确认,版本对应关系如下: istio 1.3 不支持生产 skywalking 使用 istio 1.7以上 skywalking 链路拓扑可以商用 istio 1.8 skywalking 日志商用 istio 1.11 trace 商用
|
监控 微服务
微服务监控zipkin、skywalking以及日志ELK监控系列
0、整体架构 整体架构目录:ASP.NET Core分布式项目实战-目录 一、目录 1、zipkin监控 2、skywalking监控 3、ELK日志监控   asp.net Core 交流群:787464275 欢迎加群交流如果您认为这篇文章还不错或者有所收获,您可以点击右下角的【推荐】按钮精神支持,因为这种支持是我继续写作,分享的最大动力! 作者:LouieGuo 声明:原创博客请在转载时保留原文链接或者在文章开头加上本人博客地址,如发现错误,欢迎批评指正。
3512 0
|
4天前
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
85 30
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
|
30天前
|
XML JSON Java
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
188 3
|
3月前
|
Kubernetes Ubuntu Windows
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
129 3
|
1月前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1611 14
|
26天前
|
Python
log日志学习
【10月更文挑战第9天】 python处理log打印模块log的使用和介绍
25 0
|
28天前
|
数据可视化
Tensorboard可视化学习笔记(一):如何可视化通过网页查看log日志
关于如何使用TensorBoard进行数据可视化的教程,包括TensorBoard的安装、配置环境变量、将数据写入TensorBoard、启动TensorBoard以及如何通过网页查看日志文件。
155 0
|
1月前
|
存储 分布式计算 NoSQL
大数据-136 - ClickHouse 集群 表引擎详解1 - 日志、Log、Memory、Merge
大数据-136 - ClickHouse 集群 表引擎详解1 - 日志、Log、Memory、Merge
35 0