Hi Xavier, I last volunteered to do this and didn't get to it. I _just_ opened the project again and wanted to update the mailing list but if you've already started I'll happily let you finish this work. I already had done a bit of work on this last year but then we had the big spotless merge which I was waiting for and that caused all kinds of issues with my patch. I just looked at it again and it'd be painful to bring it up-to-date.
Long story short: Happy for you to give it a shot and I see you have a WIP PR up so I won't even try to salvage my branches. Good luck and thanks for picking this up! Cheers, Lars On Wed, Mar 11, 2026 at 12:18 AM Tanuj Khurana <[email protected]> wrote: > > Hi Xavier, > > Thank you for volunteering to work on this project. This is a long standing > gap in Phoenix and will greatly improve our observability story. > > Regards, > Tanuj > > On Mon, 9 Mar 2026 at 01:07, Xavier Fernandis <[email protected]> > wrote: > > > Hi Phoenix Community, > > > > Following up on the earlier discussion around HTrace removal ( > > https://lists.apache.org/thread/6y61s9j8yk1gpznwj0g4ptgv6l1h8jyz), HTrace > > has been abandoned for years and HBase has already completed its own > > migration to OpenTelemetry (HBASE-22120). Phoenix still carries HTrace as a > > dependency, and its tracing infrastructure is effectively non-functional. > > > > I would like to volunteer to work on PHOENIX-5215 : migrating Phoenix's > > distributed tracing from the deprecated HTrace library to OpenTelemetry. ( > > https://issues.apache.org/jira/browse/PHOENIX-5215) > > > > *High-level architecture:* > > Phoenix will depend only on opentelemetry-api at compile time (no SDK > > bundled). A single new facade class *PhoenixTracing.java* modeled after > > HBase's TraceUtil, will centralize all tracing calls (createSpan, trace, > > wrap, withTracing, etc. At runtime, the OpenTelemetry Java Agent shipped by > > HBase provides the SDK implementation. When the agent is not attached, all > > OTel API calls are no-ops with zero overhead. Since Phoenix runs inside > > HBase's JVM as coprocessors, Phoenix spans automatically join HBase's trace > > pipeline, giving operators unified end-to-end traces (Phoenix query → HBase > > RPC → region scan) in any OTLP-compatible backend (Jaeger, Grafana Tempo, > > Zipkin, etc.) with no Phoenix-specific configuration required. > > > > *Proposed approach:* > > > > 1. Remove HTrace Maven dependency : Drop HTrace from all POMs and ban it > > via maven-enforcer-plugin. > > 2. Add stub classes : Introduce lightweight no-op stub implementations > > for the removed HTrace types so existing code continues to compile > > without > > build failures during the transition. > > 3. Add OpenTelemetry API dependency : Add > > opentelemetry-api compile-time only, no SDK to the root and module > > POMs. > > 4. Create PhoenixTracing.java facade : A thin wrapper over the OTel API > > following HBase's TraceUtil pattern, providing createSpan(), trace(), > > wrap(), withTracing(), isRecording(), etc. > > 5. Migrate client & server code : Replace all HTrace stub usage across ~ > > files (PhoenixConnection, MutationState, BaseQueryPlan, TracingIterator, > > IndexRegionObserver, Indexer, etc.) with PhoenixTracing calls using > > proper > > span lifecycle (create → makeCurrent → end). > > 6. Delete old trace infrastructure : Remove the stub classes, old > > Tracing.java/NullSpan.java/TracingUtils.java utilities, TraceWriter, > > TraceSpanReceiver, TraceReader, PhoenixMetricsSink, and related test > > classes. > > 7. Update tests & docs : Rewrite tracing tests for OTel's > > InMemorySpanExporter and update operator documentation. > > > > I would like to volunteer on this migration and would greatly appreciate > > any feedback or suggestions you may have. > > > > Thanks, > > Xavier Fernandis > >
