skywalking日志收集

简介: 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的日志收集我们就介绍完了。




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

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

相关实践学习
通过日志服务实现云资源OSS的安全审计
本实验介绍如何通过日志服务实现云资源OSS的安全审计。
相关文章
|
消息中间件 监控 Java
skywalking06 - skywalking也可以作为日志中心收集日志了!
skywalking06 - skywalking也可以作为日志中心收集日志了!
1365 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 声明:原创博客请在转载时保留原文链接或者在文章开头加上本人博客地址,如发现错误,欢迎批评指正。
3736 0
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
4551 31
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
|
监控 安全 Apache
什么是Apache日志?为什么Apache日志分析很重要?
Apache是全球广泛使用的Web服务器软件,支持超过30%的活跃网站。它通过接收和处理HTTP请求,与后端服务器通信,返回响应并记录日志,确保网页请求的快速准确处理。Apache日志分为访问日志和错误日志,对提升用户体验、保障安全及优化性能至关重要。EventLog Analyzer等工具可有效管理和分析这些日志,增强Web服务的安全性和可靠性。
503 9
|
10月前
|
监控 容灾 算法
阿里云 SLS 多云日志接入最佳实践:链路、成本与高可用性优化
本文探讨了如何高效、经济且可靠地将海外应用与基础设施日志统一采集至阿里云日志服务(SLS),解决全球化业务扩展中的关键挑战。重点介绍了高性能日志采集Agent(iLogtail/LoongCollector)在海外场景的应用,推荐使用LoongCollector以获得更优的稳定性和网络容错能力。同时分析了多种网络接入方案,包括公网直连、全球加速优化、阿里云内网及专线/CEN/VPN接入等,并提供了成本优化策略和多目标发送配置指导,帮助企业构建稳定、低成本、高可用的全球日志系统。
1029 54
|
XML JSON Java
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
1506 3
|
存储 SQL 关系型数据库
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
1034 35
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
|
存储 缓存 关系型数据库
图解MySQL【日志】——Redo Log
Redo Log(重做日志)是数据库中用于记录数据页修改的物理日志,确保事务的持久性和一致性。其主要作用包括崩溃恢复、提高性能和保证事务一致性。Redo Log 通过先写日志的方式,在内存中缓存修改操作,并在适当时候刷入磁盘,减少随机写入带来的性能损耗。WAL(Write-Ahead Logging)技术的核心思想是先将修改操作记录到日志文件中,再择机写入磁盘,从而实现高效且安全的数据持久化。Redo Log 的持久化过程涉及 Redo Log Buffer 和不同刷盘时机的控制参数(如 `innodb_flush_log_at_trx_commit`),以平衡性能与数据安全性。
758 5
图解MySQL【日志】——Redo Log