Sumit6307 commented on issue #7999: URL: https://github.com/apache/incubator-seata/issues/7999#issuecomment-3916647866
> ### Check Ahead > * [x] > [x] I have searched the [issues](https://github.com/seata/seata/issues) of this repository and believe that this is not a duplicate. > [x] > [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. @funky-eyes -- 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]
