Sumit6307 opened a new issue, #7999:
URL: https://github.com/apache/incubator-seata/issues/7999

   ### Check Ahead
   
   - [x] I have searched the [issues](https://github.com/seata/seata/issues) of 
this repository and believe that this is not a duplicate.
   
   - [x] I am willing to try to implement this feature myself.
   
   
   ### Why you need it?
   
   Currently, Apache Seata provides metrics via the seata-metrics module 
(Prometheus, etc.), but it lacks native distributed tracing support.
   
   In a microservices architecture, a single global transaction involves 
interactions between:
   
   1) TM (Transaction Manager - Business Service A)
   2) TC (Seata Server)
   3) RM (Resource Manager - Database/Service B)
   Without unified tracing, debugging issues like "why did this global 
transaction rollback?" or "where is the latency bottleneck in the 2PC commit 
phase?" is extremely difficult. Developers have to manually correlate logs from 
different services and the Seata Server using the XID, which is disjointed and 
inefficient.
   
   Integrating OpenTelemetry (OTel) would allow Seata to propagate trace 
contexts (e.g., W3C Trace Context) across RPC calls, creating a complete 
"End-to-End" view of a distributed transaction, compatible with modern 
observability stacks (Jaeger, Zipkin, SkyWalking).
   
   ### How it could be?
   
   This feature would likely introduce a new module (e.g., 
seata-plugins/seata-opentelemetry or enhancing seata-core) to handle context 
propagation and span generation.
   
   1. Context Propagation (The Core Challenge)
   
   The core challenge is propagating the OTel Context (TraceId, SpanId) through 
Seata's custom RPC protocol.
   
   Current State: RpcContext and AbstractMessage manage metadata but don't have 
a flexible header mechanism for arbitrary baggage.
   
   Proposed Mechanism: Extend the RPC protocol headers or RpcContext to carry 
Tracing Headers (e.g., traceparent).
   >TM Side: Inject the current active span context into the GlobalBeginRequest.
   >TC Side: Extract the context from the request and create a child span for 
the coordinator logic.
   > RM Side: Propagate context to branch registration calls.
   
   2. Instrumentation Points (Spans)
   We need to generate Spans at key lifecycle events:
   
   >TM Side:
   GlobalTransaction.begin() -> Start Span GlobalTransaction/Begin
   GlobalTransaction.commit() -> Start Span GlobalTransaction/Commit
   >TC Side:
   DefaultCoordinator.doGlobalBegin -> span TC/HandleGlobalBegin
   DefaultCoordinator.doGlobalCommit -> span TC/HandleGlobalCommit
   DefaultCoordinator.branchRegister -> span TC/RegisterBranch
   >RM Side:
   ConnectionProxy.commit() -> span RM/PhaseOneCommit
   UndoLogManager.flushUndoLogs -> span RM/FlushUndoLog
   
   3. Deliverables
   A drop-in seata-opentelemetry integration.
   Support for standard W3C Trace Context propagation.
   Validation with a demo app (e.g., seata-samples) showing a full trace in a 
UI like Jaeger.
   
   
   ### Other related information
   
   Reference: [OpenTelemetry Java 
Instrumentation](https://opentelemetry.io/docs/instrumentation/java/)
   Relevant Code Locations:
   
   > org.apache.seata.core.rpc.RpcContext: Needs to hold/transmit 
io.opentelemetry.context.Context.
   > org.apache.seata.server.coordinator.DefaultCoordinator: The main entry 
point for server-side spans.
   > org.apache.seata.rm.datasource.ConnectionProxy: Key interception point for 
RM-side spans.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to