The first thing to understand is, why use link tracking?
There may be errors when we call between microservices, but we do not know which service is the problem, and we can trace the error of which service through the log link.
It also has a benefit: when we are in the enterprise, maybe everyone is responsible for a service, we can log to check that their own services are not error, when the other services, when the error occurs, then can be determined that not their own service error, and can also find that the responsibility is not their own.
Based on the call between MicroServices, if you don't understand the small partners, please refer to my previous blog: Spring Cloud in the call between MicroServices and Eureka self-protection mechanism
First, we'll start with the PROJECT-SOLR and Project-shopping-mall Riga:
PROJECT-SOLR in the APPLICATION.YML:
Logging: path:d:\work\logs\project-SOLR #打印存放日志的路径 level : com.gaofei:info #包名下日志的级别
Project-shopping-mall in the APPLICATION.YML:
Logging: path:d:\work\logs\project-shopping-Mall #打印存放日志的路径 level : com.gaofei:info #包下面日志级别
You can see that my two service log storage path is not the same, so it is easy to distinguish
In the Constroller of PROJECT-SOLR:
@RestController//This makes all the methods in this Constroller return not the page public class Solrsearchconstroller {public static Logger Logger=loggerfactory.getlogger (Solrsearchconstroller.class); @RequestMapping ("/solrsearch") public String Solrsearch () { logger.info ("SOLR is called"); Return "Here is Solr";}}
Constroller in the Project-shopping-mall:
@Controllerpublic class Pagecontroller {public static Logger Logger=loggerfactory.getlogger ( Pagecontroller.class); @Autowired private resttemplate resttemplate; @RequestMapping ("/toindex") public String Toindex (model model) {Logger.info ("Execute call"); String msg=resttemplate.getforentity ("Http://project-solr/SolrSearch", String.class). GetBody ();// PROJECT-SOLR is the name Logger.info ("End of Call") in the Call Registry,Model.addattribute ("msg", msg); return "/index";}}
Next Execute:
Here if there is no logs behind the directory it will automatically create
Click to open two log files:
This is because I have run the Refresh 3 times, so executed 3 times, and two logs also corresponds three times
If one of the errors so also quickly can find the answer, and know which log error, also corresponds to which service error
Then the problem comes, if we are in development, a day may run N times, then one of the running error, we have to call in N times to find the corresponding service, then how to do, we can not one by one corresponding to find
At this point we can do the link tracking, just need to add spring Cloud sleuth dependency on the corresponding server Build.gradle
Distributed Link dependent compile group: ' Org.springframework.cloud ', Name: ' Spring-cloud-starter-sleuth '
Here I only use two services PROJECT-SOLR and Project-shopping-mall, so here are the two service Build.gradle added
After execution, open the stored log:
Here I run a refresh of n times, then how to find the corresponding call in another service? Let's take a closer look at the link in the red block is not the corresponding service
I'll just grab one and find out.
Through the find can find that the corresponding link, so that each run will appear a link, you can find the operation of the corresponding service is successful, then this is the link tracking
Next I'll write the link Tracking for distributed service consolidation Zipkin
Spring Cloud Distributed usage log link Tracking