还有一个目标就是，如何将链路跟我们实际的日志记录进行绑定，这样方便在某个链路出现问题时，我们可以针对这个具体的链路去查看具体问题原因。

在demo中，我们通过logback记录日志，添加依赖

目前很多的链路追踪组件都已经实现了与日志组件的集成，只需要引入依赖，即可完成将链路traceid对应写入到日志中。

在代码中加入写日志的代码

增加配置信息，以及logback－spring．xml文件

可以看到控制台日志中，记录的日志前面都加上了TID信息，也就是traceid。

4．普元微服务平台的链路追踪应用

上面的demo只是简单的验证了如何快速通过第三方组件实现微服务架构下的链路追踪功能，对于在实际项目应用中我们需要进行优化和整合，这章节中介绍我们普元微服务平台在链路追踪中的相关应用场景：

1． 系统拓扑结构

2． 应用运行时

3． 业务链路

4． 跟踪日志

5． 服务统计

在链路追踪下，系统可以根据请求调用关系绘制去系统拓扑结构，通过系统拓扑结构你可以清楚知道当前系统下有多少微服务应用，微服务应用间是否有调用关系，每个服务的具体概况。

由于微服务架构下，一个系统的微服务相对比较多，如果没有这个系统拓扑结构，后期对系统的情况，尤其是系统间的调用依赖关系跟踪也很困难。

应用运行时，通过收集统计相关调用请求信息，计算相关性能指标，帮助系统管理员运维人员快速了解系统的相关情况，主要是微服务应用实例的能力指标，比如平均响应时间、平均响应成功率等指标。

由于普元微服务平台的架构特性，每一个服务对应多个应用实例组，因此在查看时可以选择具体实例组下的实例节点。帮助我们了解应用节点的性能，以及慢节点情况。

业务链路，快速查看某个应用、甚至应用下某个具体的操作的完整链路调用情况，链路中每个过程处理的时间信息，每个链路上显示traceid信息，并提供快速复制功能，方便用户在跟踪日志中快速查看此次链路对应的日志信息。

根据请求中的时间信息，在请求响应慢的时候追溯具体慢的操作。

链路调用的时序情况，通过不同颜色区分应用系统，可以查看具体调用的详细信息（组件、url、请求方式、异常信息等）。

链路日志，前面我们已经完成了请求完整链路的还原，不过这些信息还不能查出根本原因，对应异常发生的根本原因，我们有时还需要通过系统记录的日志文件进行查看，通过日志文件记录的错误信息进行排查根本原因。我们在查看日志文件时，也不是直接显示日志文件所有内容，而是通过以与链路对应的方式，显示每个链路环节中记录的日志信息，查看异常详细原因。

另外，在跟踪日志模块，我们针对性的过滤筛选错误日志、事务日志等信息。

平台通过链路组件采集的请求处理信息，对这些信息进行统计，从多个维度提供统计数据供运维人员进行参考分析

统计某个应用、某个请求路径的总请求数、正常响应数、错误响应数、最长处理时间、最少处理时间、平均处理时间以及各类异常处理的统计

在平台正常运行一段时间后，运维人员普遍关注平台的运行情况，尤其是哪些请求比较频繁、哪些请求比较耗时、哪些请求错误率比较高、哪些错误数多，而这些信息对于运维人员比较敏感，因此平台中提供直接显示统计数据的方式供参考。

本文主要介绍微服务架构下的链路追踪的应用场景，主要解决哪些问题，对于一个刚接触链路追踪的新人来说，如何快速上手将链路追踪引入到项目中，也将我们普元微服务平台下的链路追踪的应用简单介绍了一下，便于大家在项目中进行实际的应用参考。文中没有对目前市场上开源的链路追踪的组件做过多介绍以及之间的比较，也没有对skywalking这个组件的使用配置做详细介绍，相关的这些知识我们有专栏介绍，大家可以查看历史文章进行了解。