Hi Yuki, I am sorry for the late reply. It would be good to include a perf test as a part of the test plan. At least a basic regression test to ensure that when the feature is disabled do we not have a degradation from CPU and allocation point of view for hot paths (read/write prepared statement flows). The feature is cross-cutting for existing logic, so it is quite easy to introduce some impact here. If needed, I can help with it. What do you think?
Another topic is the amount of 3rd party dependencies which we introduce, do we have a full list (including *transitive* ones) of JAR files which we plan to add to Cassandra distribution? What is the total size of them compared to the current Cassandra dist? I am wondering because some time ago I saw an explosion of JMX Exporter distribution size once they added OpenTelemetry support... Thank you, Dmitry On Sat, 27 Sept 2025 at 06:06, Yuki Morishita <[email protected]> wrote: > Hi, > > Thanks for the comment. > Yes, the idea is to follow semantic conventions already defined in the > OpenTelemetry project for both Cassandra client and DB conventions [1]. > Initial Resource and Span attributes to implement are listed in the CEP, > please let me know if the naming of the attribute is off. > > 1: https://opentelemetry.io/docs/specs/semconv/database/ > > On Fri, Sep 26, 2025 at 11:59 PM Jane He via dev <[email protected]> > wrote: > >> It’s always good if our attributes/semantic conventions align with >> existing C# driver OpenTelemetry support: >> https://docs.datastax.com/en/developer/csharp-driver/3.22/features/opentelemetry/index.html#attributes >> >> And of course the OpenTelemetry official Cassandra semantic conventions: >> https://opentelemetry.io/docs/specs/semconv/database/cassandra/ >> >> >> >> We are developing OpenTelemetry support on the Java driver side, aiming >> to release in v4.20.0. We would love to align with your work, too. >> >> >> >> *From: *Yuki Morishita <[email protected]> >> *Date: *Monday, September 22, 2025 at 7:49 AM >> *To: *[email protected] <[email protected]> >> *Subject: *[EXTERNAL] Re: [DISCUSS] CEP-32 OpenTelemetry tracing >> integration >> >> One of the goal of the CEP is to define how drivers can send the tracing >> context to Apache Cassandra through native protocol. Implementation in >> driver side is out of scope for now, but once CEP is accepted, any driver >> can implement it according >> >> One of the goal of the CEP is to define how drivers can send the tracing >> context to Apache Cassandra through native protocol. >> >> Implementation in driver side is out of scope for now, but once CEP is >> accepted, any driver can implement it according to the standard defined. >> >> On Mon, Sep 22, 2025, 8:43 PM Johnny Miller <[email protected]> >> wrote: >> >> One question would be around the support for this in the other drivers, >> not just Java. It would be good to understand the plan for those as part of >> this CEP? >> >> >> >> On Mon, 22 Sept 2025 at 07:36, Yuki Morishita <[email protected]> wrote: >> >> Hi, >> >> >> >> I'd like to propose CEP-32 OpenTelemetry tracing integration (1) so >> Apache Cassandra can export its tracing telemetry in OpenTelemetry standard. >> >> >> >> The original draft of the proposal was integrating not only tracing but >> also metrics and logs, however, the latest proposal reduced the scope so we >> can get started in integrating OpenTelemetry standard. >> >> >> >> I'd like the opinion in 4 topics below: >> >> >> >> * How to configure OpenTelemetry >> >> * The way of propagating Context >> >> * Resource definition to describe Apache Cassandra node as a >> telemetry source >> >> * Span creation and its attributes >> >> >> >> Regards, >> >> Yuki >> >> >> >> 1: >> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-32%3A+OpenTelemetry+tracing+integration >> >> -- Dmitry Konstantinov
