— name: arthas-eagleeye-traceid description: Use Arthas's watch/trace to obtain the EagleEye traceId / get the traceId of a request. — # Obtaining the EagleEye traceId (Arthas) When to use: you need to grab the current thread's EagleEye `traceId` from an online request path without changing any code, in order to correlate logs / do trace analysis / reproduce an issue. Core idea: – EagleEye's traceId can be obtained inside a business thread via `EagleEye.getTraceId()`. – Arthas's `watch` supports OGNL, so you can call the static method directly: `@com.taobao.eagleeye.EagleEye@getTraceId()` – Arthas's `trace` output usually includes `trace_id=…` automatically (if the environment has EagleEye integrated). ## Pre-checks (recommended) 1) Confirm whether the EagleEye class exists: “`bash sc -d com.taobao.eagleeye.EagleEye “` If it isn't found: – EagleEye may not be integrated, or the class may have been relocated/shaded (ask the user to provide the actual class name / dependency info). 2) Pick a method that "is definitely called by the request thread" as your observation point: – Common ones: Controller entry methods, RPC Provider methods, a Filter/Interceptor's doFilter/preHandle, etc. – Avoid: high-frequency hot methods (they flood the screen and add overhead). ## Approach A: print the traceId directly with watch (most intuitive) ### A1) Print only the traceId (minimal output) “`bash watch <fully-qualified class> <method name> '@com.taobao.eagleeye.EagleEye@getTraceId()' -n 5 “` Notes: – `@ClassName@staticMethod()` 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 together (better for correlation) “`bash watch <fully-qualified class> <method name> '{params, @com.taobao.eagleeye.EagleEye@getTraceId()}' -n 5 -x 2 “` Notes: – `{…}` outputs multiple fields as an array/list. – `params` is one of Arthas watch's built-in variables; `-x 2` controls the object-expansion depth (raise/lower as needed). Common variation (as needed): – Take it after the method returns (after is the default, can be omitted): – If you suspect the traceId is only set during method execution, try `-b` (before) for comparison; rely on the actual online result. ## Approach B: let trace surface the traceId automatically (better for viewing the call chain) “`bash trace <fully-qualified class> <method name> -n 5 “` What to expect: – The header of the `trace` output shows a field like `trace_id=<xxxx>`. – You also see the method call chain and the time spent in each segment, so you can "grab the traceId + see where it's slow" in one go. ## Interpreting and reporting results (suggested template) The final conclusion/evidence you give the user should include: – Observation point (class/method): `<fully-qualified class>#<method name>` – How obtained: `watch` / `trace` – Key evidence: – `traceId=<…>` (plus a params summary when necessary) – Next-step suggestion: – Use that traceId to look up the corresponding request in the log/trace system – Or narrow the observation point to a more downstream method (e.g. a DAO/RPC call) and continue trace/watch ## Extensions – The traceId of other distributed-tracing systems, or values held in a ThreadLocal, can be read in the `watch` OGNL expression in a similar way.