Sleuth + Zipkin

In the application.yml for each environment, we have a config for Sleuth.

sleuth:  
  enable: true  
  sampler:  
    probability: 1  
    rate: 500  
  trace-id128: true

Sleuth will help generate the traceId and uses a sampler to decide whether some traces will be shipped to zipkin or not.

When the service receives a request from a client, it will go through multiple filters. One of the filters that it goes through is the Sleuth filter, which adds in a traceId for that request. Currently, in the implementation of portal, we have a custom filter which will then add the traceId to the header X-Trace-Id, this is only added in for server client response. Not for service to service. For service to service, we use X-B3-TraceId

When the service processes the request and if it requires to contact other services, it will send a request to other services and include the following information in the request headers.

• X-B3-TraceId: <same-trace-id>
• X-B3-SpanId: <client-span-id>
• X-B3-ParentSpanId: <server-span-id-or-parent>
• X-B3-Sampled: 0 This allows other services to also use the same trace id and relevant information.

Also in the application.yml, we also have a config for Zipkin.

  zipkin:
    discoveryClientEnabled: false
    service:
      name: dataservice-portal
    enabled: true
    sender:
      type: web
    base-url: https://zipkin.data-infra.shopee.io/

This basically means that we will send the trace information to zipkin via the http. There are other options available as well, such as via kafka and rabbitmq.