Distributed tracking system microservice monitoring based on SkyWalking

In the last article, we built a SkyWalking based distributed tracking environment. Today, we talk about using SkyWalking to monitor our microservices (DUBBO)

Service case

Suppose you have an order microservice that contains the following components

  • MySQL database sub table sub database (2 sets)
  • Producer (2 sets) Dubbo provider
  • Consumer Dubbo consumer

The network topology is as follows

Producer's key code

public class OrderServiceImpl implements OrderService {

    protected OrderMapper orderMapper;

    public OrderVO getById(long id) {
        OrderVO orderVO = new OrderVO();
        Order order = orderMapper.selectById(id);
        return orderVO;

Consumer key code

public class OrderController {

    @Reference(retries = 0)
    private OrderService orderService;

    public OrderVO getOrder(@PathVariable long id){
        return orderService.getById(id);


Monitoring startup

  • Starting producers with javaagent

    -javaagent:E:\IFLYTEK development tools\skywalking\agent\skywalking-agent.jar -Dskywalking.agent.service_name=dubbo-provider -Dskywalking.collector.backend_service=

    -javaagent:E:\IFLYTEK development tools\skywalking\agent\skywalking-agent.jar -Dskywalking.agent.service_name=dubbo-provider2 -Dskywalking.collector.backend_service=

  • Launch consumer
    -javaagent:E: \ iFLYTEK development tool \ skywalking \ agent \ skywalking-agent.jar - dskywalking. Agent. Service_name = Dubbo consumer - dskywalking. Collector. Backend_service =
  • Simulation request

Visit http://localhost:9090/order/1184489161562816511 in the browser, and make multiple calls to make the load effective; modify the order id parameter to make the call cover different databases

  • Effect view

Visit skywalking monitoring address to view the monitoring effect


Network topology

Error log

Trace query

Log integration

In this part, we first look at the principle of the down chain:

  • When a request arrives, a global TraceID is generated. Through TraceID, the entire call chain can be concatenated. A TraceID represents a request.
  • In addition to TraceID, SpanID is required for recording calls to parent-child relationships. Each service records the Parent id and Span id, through which the parent-child relationship of a complete call chain can be organized.
  • To view a complete call, just find out all the call records according to TraceID, and then organize the whole call parent-child relationship through Parent id and Span id.

Because TraceID is so important, we hope that TraceID of this call chain can be output in the log file. Once abnormal calls are observed, we can directly search TraceID in the log analysis platform to retrieve all the associated logs, greatly improving our efficiency in solving the problem.

Integration process (log4j2)

  • Introducing log package log4j2

  • Introduction of SW Kit

     <!--SW trace Track-->
  • Modify the log display format log4j2.xml

%d [%traceId] %-5p %c{1}:%L - %m%n

  • Launch app, watch console

When you just start, you can't get TraceID, so the TID is displayed as N/A. After the completion of the startup, the request is called again to observe the console, and it is found that all logs on the link are TraceID.

In a few simple steps, you can add call chain monitoring to your microservice. Would you like to try it now?

Related articles:
SkyWalking based distributed tracking system environment building

Spring boot 2.1.9 + Dubbo 2.7.3 + Nacos 1.1.4 build your microservice system

Welcome to my personal public address: JAVA RI Zhi Lu.

Tags: Java Dubbo Spring Database MySQL

Posted on Wed, 06 Nov 2019 20:02:56 -0500 by TANK