arthas-eagleeye-traceid

Get the EagleEye traceId (Arthas)

Applicable scenario: you need to obtain the EagleEye of the current thread in an online request chain without changing code traceId, for correlating logs/chain analysis/problem reproduction.

Core idea:

• EagleEye's traceId can be obtained in a business thread via EagleEye.getTraceId() .
• Arthas's watch supports OGNL and can directly call static methods:@com.taobao.eagleeye.EagleEye@getTraceId()
• Arthas's trace output usually automatically includes trace_id=...(if the environment has EagleEye integrated).

Pre-checks (recommended)

1. Confirm whether the EagleEye class exists:

sc -d com.taobao.eagleeye.EagleEye

If not found:

• EagleEye may not be integrated, or the class may be relocated/shaded (ask the user to provide the actual class name/dependency information).

1. Choose a method that is "certain to be called by the request thread" as the observation point:

• Common: Controller entry methods, RPC Provider methods, Filter/Interceptor doFilter/preHandle, etc.
• Avoid: high-frequency hot methods (easy to flood the screen, increases overhead).

Option A: Use watch to directly print the traceId (most intuitive)

A1) Print only the traceId (minimal output)

watch <类全名> <方法名> '@com.taobao.eagleeye.EagleEye@getTraceId()' -n 5

Notes:

• @类名@静态方法() is the OGNL static method call syntax.
• -n 5 limits the number of executions to avoid flooding the screen online (be sure to keep/adjust it).

A2) Print parameters + traceId at the same time (better for correlation)

watch <类全名> <方法名> '{params, @com.taobao.eagleeye.EagleEye@getTraceId()}' -n 5 -x 2

Notes:

• {...} will output multiple fields as an array/list.
• params is one of Arthas watch's built-in variables;-x 2 controls the object expansion depth (can be increased/decreased as needed).

Common variants (as needed):

• Capture after the method returns (the default is after, so it can be omitted):
  • If you suspect the traceId is only set during method execution, you can try -b(before) for comparison; the actual online behavior should be the reference.

Option B: Use trace to automatically bring out the traceId (better for viewing the call chain)

trace <类全名> <方法名> -n 5

Expected behavior:

• trace In the header information output by trace_id=<xxxx> , a field similar to
• appears. At the same time, you can also see the method call chain and the time consumed by each segment, making it convenient to "get the traceId + see where the slowness is" all at once.

Result interpretation and output (suggested template)

The final conclusion/evidence given to the user is suggested to include:

• Observation point (class/method):<类全名>#<方法名>
• Acquisition method:watch / trace
• Key evidence:
  • traceId=<...>(and a params summary if necessary)
• Next-step suggestions:
  • Use this traceId to query the corresponding request in the log/chain system
  • , or narrow the observation point to a more downstream method (such as a certain DAO/RPC call) and continue trace/watch

Extensions

• The traceId of other distributed tracing systems, or values in ThreadLocal, can also be read in a similar way in watch 's OGNL expressions.