Skip to main content

End-to-End Call Log Tracing

Introduction​

The framework supports distributed systems. A request initiated by a client (user) may pass through multiple logic servers before producing the final result.

Problems this creates

  • Each request may form a complex distributed call chain, making troubleshooting harder.
  • When many users are active, logs from other threads are interleaved, making it difficult to filter all logs for a specific request.

To solve this, we trace request chains and use MDC by adding a traceId marker in log patterns. When a request reaches the server, we assign it a unique identifier. When logs are printed, traceId appears in the logs, allowing full-chain tracking of that request.

An

The highlighted area in the figure shows logs printed by the same request. Previously, we often used userId to identify requests, which is only suitable for small to medium volumes. It does not work well under high volume because:

  1. When many users are active, logs from other threads are interleaved, making it difficult to isolate all logs for one request.
  2. The same user may issue multiple requests in a short time, so it is hard to tell which logs belong to which request.

End-to-end call log tracing solves this by assigning a unique identifier to each request and recording it in logs. With that unique identifier, you can quickly filter logs for a specific request.

The framework's tracing feature is powerful and supports cross-machine and cross-process tracing. Simply put, from request entry to completion, no matter how many logic servers are involved, it can be tracked accurately.


The figure below shows a cross-server call screenshot

End-to-end call log tracing is very practical for cross-server calls.

An

logback.xml​

code 4: In this configuration, ionetTraceId means printing traceId.

logback.xml
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <property name="log.pattern"
              value="%d{HH:mm:ss.SSS} %green([%thread]) [%X{ionetTraceId}] %highlight(%-5level) %cyan(%logger{5}).%M\(%F:%L\) %m%n"/>

    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
            <pattern>${log.pattern}</pattern>
            <charset>utf8</charset>
        </encoder>
    </appender>

    <root level="INFO">
        <appender-ref ref="STDOUT"/>
    </root>
</configuration>

traceId Generation Strategy​

For traceId generation, the framework provides a default implementation (suitable only for a single external server).

If you start multiple external servers, it is recommended to re-implement this part of traceId generation logic or use a third-party library.

Mongo ObjectId Generation Strategy​

see https://mvnrepository.com/artifact/org.mongodb/bson

Use MongoDB ObjectId as the generation strategy.

public void config() {
    TraceKit.setDefaultTraceIdSupplier(() -> new ObjectId().toString());
}

Notes and Considerations​

warning

Custom traceId length must not exceed 24.

Summary​

End-to-end call log tracing effectively solves the issues described at the beginning and is easy to use in the framework.

Enterprise Features​

warning

This is an enterprise feature.