Hi Yuki, I am the one from AWS that Maxwell is referring to. 😊 I agree that narrowing the scope of CEP-32 to focus on tracing makes sense. The summary you shared yesterday aligns with my understanding as well. In my case, I’ve been able to emit Cassandra process metrics to Kinesis using OTEL collectors without requiring deep Cassandra integration. That makes me think a tight coupling for metrics may not be necessary at this stage. Tracing, however, is a strong use case where direct Cassandra support would provide real value. I’d recommend updating CEP-32 with a tighter focus on tracing. We could also consider adding a “Future Work” section to capture other areas in Cassandra where OTEL integration might help, while keeping the current implementation scoped to tracing. Thanks, Himanshu
From: guo Maxwell <cclive1...@gmail.com> Date: Friday, September 12, 2025 at 11:08 PM To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: RE: [EXTERNAL] Question on CEP-32 and OpenTelemetry Integration CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. just overwrite the exist cep is ok. But I remember that someone from AWS was planning to do this CEP. Yuki Morishita <yu...@apache.org<mailto:yu...@apache.org>>于2025年9月13日 周六13:48写道： Hi, Sorry for the late reply. I started working on CEP-32 again, but I'd like to narrow the scope to exporting tracing only. The reason for the change are: * Metrics and logs can be exported through OpenTelemetry without change in Cassandra * For example, Prometheus JMX exporter supports OLTP export * To focus on the important part for the initial adoption of OpenTelemetry - configuration, context propagation and basic semantic conventions. My question is, should I override the current CEP with the new proposal (CEP-32 is still in DRAFT state anyway), or create the new CEP? If no objections are posted, I will override the existing one when my draft is ready for discussion. On Tue, Jul 22, 2025 at 11:49 PM Patrick McFadin <pmcfa...@gmail.com<mailto:pmcfa...@gmail.com>> wrote: I don't think archiving CEP-32 is the right move, as Josh's point suggests that it should serve as a placeholder for OTEL in the Cassandra project. This isn't a topic that will go away. What needs to happen in the current version of CEP-32 is an update and revision to the areas Dinish mentioned. Yuki was the originator of the CEP, so I think it would be good to hear from him on whether he wants to take up the revision or hand it off. Patrick On Mon, Jul 21, 2025 at 6:57 PM guo Maxwell <cclive1...@gmail.com<mailto:cclive1...@gmail.com>> wrote: I think integrating OpenTelemetry is a great idea. HBase has already do this thing , see https://issues.apache.org/jira/browse/HBASE-25373 . Josh McKenzie <jmcken...@apache.org<mailto:jmcken...@apache.org>> 于2025年7月22日周二 03:46写道： I would like to propose extending the scope of the CEP to include C* Sidecar, Analytics, and Java Driver (at a minimum). To clarify (my position, not put words in your mouth Dinesh) - the CEP I think should cover them all, but implementation we could definitely do piece-meal. On Mon, Jul 21, 2025, at 2:52 PM, Dinesh Joshi wrote: My preference would be to archive it unless there is someone who is interested in actively interested in picking it up. If anybody is interested in picking it up, I would like to propose extending the scope of the CEP to include C* Sidecar, Analytics, and Java Driver (at a minimum). But that is just my 2c. Thanks, Dinesh On Mon, Jul 21, 2025 at 11:17 AM Jindal, Himanshu <himan...@amazon.com<mailto:himan...@amazon.com>> wrote: Hi all, I've been exploring ideas around improving native support for OpenTelemetry in Cassandra and came across CEP-32<https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-32>. After reviewing the associated dev mailing list discussions<https://lists.apache.org/thread/oo1kt8s2nyznk5hyfb4kkdmvlgr03ys5>, my understanding is that there isn’t currently a clear path forward for direct OTEL integration. It seems the primary concerns are: 1. The implications of introducing a third-party library into Cassandra, and 2. Potential performance impact on nodes. Is that a fair summary of the current consensus? If so, would it make sense—purely from a CEP hygiene and clarity perspective—to mark CEP-32 as deferred or close it out to reflect the current state? Thanks, Himanshu
