码农架构 | 微服务分布式架构中,如何实现日志链路跟踪?

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 微服务分布式架构中,如何实现日志链路跟踪?

Logback 背景


Logback是由log4j创始人设计的另一个开源日志组件,官方网站: http://logback.qos.ch。它当前分为下面下个模块:

  • logback-core:其它两个模块的基础模块
  • logback-classic:它是log4j的一个改良版本,同时它完整实现了slf4j API使你可以很方便地更换成其它日志系统如log4j或JDK14 Logging
  • logback-access:访问模块与Servlet容器集成提供通过Http来访问日志的功能

普通debug日志


SQL执行日志

Logback 配置案例


日志级别排序为: TRACE < DEBUG < INFO < WARN < ERROR

  • %d:表示日期
  • %n:换行
  • %thread:表示线程名
  • %level:日志级别
  • %msg:日志消息
  • %file:表示文件名
  • %class: 表示文件名
  • %logger:Java类名(含包名,这里设定了36位,若超过36位,包名会精简为类似a.b.c.JavaBean)
  • %line:Java类的行号

注意:

%-4relative %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread][%X{TRACE_ID}] %-5level %logger{100}.%M\(%line\) - %msg%n

在logback中,%relative表示自应用程序启动以来打印相对时间戳(以毫秒为单位). %-4只是元素的对齐方式.

案例

34524872021-08-0315:19:36.940 [thread-monitor-daemon][] WARNcom.xxxx.common.util.MonitorLogger.warn(27) -发现超时线程notify-replay-consumer...

由于案例中是守护线程thread-monitor-daemon,所以不记录链路ID。

对在系统设计的时候对于线程的命名规范也是有约束的

这里就不做详细展开后续有机会会分享。

回归正题比如下面的例子中记录了请求的链路ID

190069892021-08-0422:35:25.776 [http-nio-0.0.0.0-8010-exec-10][1fc8pebmgwukw863w2p342rp2936a3r157w0:0:] INFOcom.xxx.framework.eureka.core.listener.EurekaStateChangeListener.listen(58) -

服务实例[XX-PAAS]注册成功,当前服务器已注册服务实例数量[3]

对于上图中显示的系统启动时间、当前时间、当前线程、对应路径按照logback官方配置就可以逐步完善对于的日志信息,但是对于链路ID的生成写入就需要特殊处理。

链路ID设计


对于链路追踪设计我个人比较喜欢两种方案

第一种

在每一次请求中链路编号(traceId)、单元编号(spanId)都是通过HttpHeader的方式进行传递,日志的起始位置会主动生成traceId、spanId,而起始位置的Parent SpanId则是不存在的,值为null。

这样每次通过restTemplate、Openfeign的形式访问其他服务的接口时,就会携带起始位置生成的traceId、spanId到下一个服务单元。


第二种

在每一次请求中链路编号(traceId),没经过一次微服务对于深度(Deep)加1

publicstaticclassThreadTraceListenerimplementsThreadListener {
@OverridepublicvoidonThreadBegin(HttpServletRequestrequest) {
StringtraceToken=ThreadLocalUtil.getTranVar(TRACE_ID);
StringfromServer=ThreadLocalUtil.getTranVar(FROM_SERVER);
intdeep;
StringtraceId;
if (StringUtils.isBlank(traceToken)) {
traceId=IDGenerator.generateID();
deep=0;
traceToken=StringHelper.join(traceId, ":0");
            } else {
intindex=traceToken.lastIndexOf(':');
traceId=traceToken.substring(0, index);
deep=Integer.valueOf(traceToken.substring(index+1));
            }
ThreadLocalUtil.setLocalVar(TRACE_ID, traceId);
ThreadLocalUtil.setLocalVar(TRACE_DEEP, deep);
ThreadLocalUtil.setTranVar(TRACE_ID, StringHelper.join(traceId, ":", deep+1));
ThreadLocalUtil.setLocalVar(FROM_SERVER, fromServer);
ThreadLocalUtil.setTranVar(FROM_SERVER, getCurrentServer());
MDC.put(TRACE_ID, StringHelper.join(traceToken, ":", fromServer));
        }
@OverridepublicvoidonThreadEnd(HttpServletRequestrequest) {
MDC.remove(TRACE_ID);
        }
    }

针对请求拦截

protectedvoiddoFilterInternal(HttpServletRequestrequest,
HttpServletResponseresponse,
FilterChainchain) throwsServletException, IOException {
longstartTime=System.currentTimeMillis();
// 从Header中装载传递过来的变量Map<String, Object>tranVar=newHashMap<String, Object>();
Enumeration<String>headers=request.getHeaderNames();
while (headers.hasMoreElements()) {
Stringkey=headers.nextElement();
if (!StringUtils.isEmpty(key)
&&key.startsWith(ThreadLocalUtil.TRAN_PREFIX)) {
tranVar.put(key.substring(ThreadLocalUtil.TRAN_PREFIX.length()),
request.getHeader(key));
            }
        }
ThreadLocalHolder.begin(tranVar, request);
try {
if (isGateway) {
response.addHeader("X-TRACE-ID", TraceUtil.getTraceId());
            }
// 检查RPC调用深度checkRpcDeep(request, response);
// 业务处理chain.doFilter(request, response);
// 记录RPC调用次数logRpcCount(request, response);
        } catch (Throwableex) {
// 错误处理Response<?>result=ExceptionUtil.toResponse(ex);
Determinedetermine=ExceptionUtil.determineType(ex);
ExceptionUtil.doLog(result, determine.getStatus(), ex);
response.setStatus(determine.getStatus().value());
response.setCharacterEncoding("UTF-8");
response.setContentType(MediaType.APPLICATION_JSON_UTF8_VALUE);
response.getWriter().write(JsonUtil.toJsonString(result));
        } finally {
try {
doMonitor(request, response, startTime);
if (TraceUtil.isTraceLoggerOn()) {
log.warn(StringHelper.join(
"TRACE-HTTP-", request.getMethod(),
" URI:", request.getRequestURI(),
", dt:", System.currentTimeMillis() -startTime,
", rpc:", TraceUtil.getRpcCount(),
", status:", response.getStatus()));
                } elseif (log.isTraceEnabled()) {
log.trace(StringHelper.join(request.getMethod(),
" URI:", request.getRequestURI(),
", dt:", System.currentTimeMillis() -startTime,
", rpc:", TraceUtil.getRpcCount(),
", status:", response.getStatus()));
                }
            } finally {
ThreadLocalHolder.end(request);
            }
        }
}

若有收获,就点个赞吧


更多技术分享可关注微信公众号:码农架构

专注于系统架构、高可用、高性能、高并发类技术分享

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
3天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
2天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
11 1
服务架构的演进:从单体到微服务的探索之旅
|
1天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
15 5
|
4天前
|
监控 API 微服务
后端技术演进:从单体架构到微服务的转变
随着互联网应用的快速增长和用户需求的不断演化,传统单体架构已难以满足现代软件开发的需求。本文深入探讨了后端技术在面对复杂系统挑战时的演进路径,重点分析了从单体架构向微服务架构转变的过程、原因及优势。通过对比分析,揭示了微服务架构如何提高系统的可扩展性、灵活性和维护效率,同时指出了实施微服务时面临的挑战和最佳实践。
17 7
|
2天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
14 5
|
2天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####
|
2天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
3天前
|
监控 持续交付 Docker
Docker 容器化部署在微服务架构中的应用有哪些?
Docker 容器化部署在微服务架构中的应用有哪些?
|
3天前
|
监控 持续交付 Docker
Docker容器化部署在微服务架构中的应用
Docker容器化部署在微服务架构中的应用
|
3天前
|
安全 持续交付 Docker
微服务架构和 Docker 容器化部署的优点是什么?
微服务架构和 Docker 容器化部署的优点是什么?