java 分布式日志_详解spring cloud分布式日志链路跟踪

本文详细介绍了在微服务架构中,如何利用Spring Cloud Sleuth进行日志链路跟踪,以便于定位错误和服务责任划分。通过配置不同服务的日志路径,展示了在controller中使用日志记录调用过程。在遇到错误时,通过链路追踪可以在大量调用中快速定位问题所在,提高问题解决效率。最后提到,将结合zipkin进一步探讨分布式服务的链路跟踪。
摘要由CSDN通过智能技术生成

首先要明白一点,为什么要使用链路跟踪?

当我们微服务之间调用的时候可能会出错,但是我们不知道是哪个服务的问题,这时候就可以通过日志链路跟踪发现哪个服务出错。

它还有一个好处:当我们在企业中,可能每个人都负责一个服务,我们可以通过日志来检查自己所负责的服务不会出错,当调用其它服务时,这时候出现错误,那么就可以判定出不是自己的服务出错,从而也可以发现责任不是自己的。

41b4f61f4c921cb9275c154664b912e9.png

首先,我们先在project-solr和project-shopping-mall里加配置:

project-solr中的application.yml:

logging:

path: D:\work\logs\project-solr #打印存放日志的路径

level:

com.gaofei: info #包名下日志的级别

project-shopping-mall中的application.yml:

logging:

path: D:\work\logs\project-shopping-mall #打印存放日志的路径

level:

com.gaofei: info #包下面日志级别

大家可以看出我两个服务里的日志存放的路径不一样,这样也便于区分

在project-solr里的constroller里:

@RestController//这里使此Constroller中所有的方法返回的不是页面

public class SolrSearchConstroller {

public static Logger logger=LoggerFactory.getLogger(SolrSearchConstroller.class);

@RequestMapping("/SolrSearch")

public String SolrSearch(){

logger.info("Solr被调用");

return "这里是Solr";

}

}

在project-shopping-mall里的constroller:

@Controller

public class PageController {

public static Logger logger=LoggerFactory.getLogger(PageController.class);

@Autowired

private RestTemplate restTemplate;

@RequestMapping("/toIndex")

public String toIndex(Model model){

logger.info("执行调用");

String msg=restTemplate.getForEntity("http://project-solr/SolrSearch",String.class).getBody();//project-solr是调用注册中心里的名字

logger.info("调用结束");

model.addAttribute("msg",msg);

return "/index";

}

}

接下来执行:

6bdac478e5bce0f5980a3bbea18d8e3c.png

在这里如果没有logs后面的目录它会自动创建

点开两个日志文件:

79ad52c919bbf2108727e8c2c9aba749.png

这里因为我运行刷新了3次,所以执行了3次,而两个日志里也对应了三次

如果其中一条报错那么也很快可以找到答案,并且知道哪个日志里报错,也就对应了哪个服务报错

那么问题来了,如果我们在开发中,一天可能会运行n次,那么其中某次运行报错,我们就要在n次调用时来找对应的服务,那么怎么办,我们不可能一一对应查找

这时候我们可以进行链路追踪,只需要在对应的服务器build.gradle加上Spring Cloud Sleuth依赖

//分布式链路依赖

compile group: 'org.springframework.cloud', name: 'spring-cloud-starter-sleuth'

这里我只用到了两个服务project-solr和project-shopping-mall,所以这里就在这两个服务build.gradle中添加

之后执行,打开存放的日志:

eba168f5bf27087e487e5e3c0332b531.png

这里我运行刷新了n次,那么怎么在另一个服务找到对应的调用呢?大家仔细看一下红块中的链路是不是对应相应的服务

我随便拿一个进行查找

49c0b761f78358d009bf39a276aeee01.png

通过查找可以发现,可以找到对应的链路,那么也就是每次运行都会出现一个链路,可以来查找相应服务的操作是否执行成功,那么这也就是链路追踪

下一篇我会写分布式服务整合zipkin的链路跟踪

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持脚本之家。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值