Re: Question on CEP-32 and OpenTelemetry Integration

[Jindal, Himanshu]

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 
Date: Friday, September 12, 2025 at 11:08 PM
To: 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 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 
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 
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 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 
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. After 
reviewing the associated dev mailing list 
discussions, 
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

Re: Question on CEP-32 and OpenTelemetry Integration

[Yuki Morishita]

 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  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  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  于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 
>>> wrote:
>>>
>>> Hi all,
>>>
>>> I've been exploring ideas around improving native support for
>>> OpenTelemetry in Cassandra and came across CEP-32
>>> . After
>>> reviewing the associated dev mailing list discussions
>>> , 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
>>>
>>>
>>>

Re: Question on CEP-32 and OpenTelemetry Integration

[guo Maxwell]

just overwrite the exist cep is ok.
But I remember that someone from AWS was planning to do this CEP.

Yuki Morishita 于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 
> 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  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  于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 
 wrote:

 Hi all,

 I've been exploring ideas around improving native support for
 OpenTelemetry in Cassandra and came across CEP-32
 . After
 reviewing the associated dev mailing list discussions
 , 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

Re: Question on CEP-32 and OpenTelemetry Integration

[Jane He]

Hi all,

I want to share the integration plan for OpenTelemetry on the Java Driver
side.

In the upcoming patch release (4.19.1), the Java Driver will allow users to
inject a request ID into the custom payload of each CQL request (PR
). This feature
represents a significant step toward implementing the context propagation
protocol outlined in CEP-32.

In the subsequent minor release (4.20.0), the Java Driver will introduce
native support for OpenTelemetry (please see the ticket
, PR
 for proposal, PR
 for
implementation).

These changes will boost the observability of applications using Cassandra,
and will pave the way to CEP-32, so I believe we should not archive the
proposal.

Best,
Jane


Jane He

c. +1 949 991 8403

w. www.datastax.com

  
  




On Tue, Jul 22, 2025 at 7:49 AM Patrick McFadin  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  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  于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 
>>> wrote:
>>>
>>> Hi all,
>>>
>>> I've been exploring ideas around improving native support for
>>> OpenTelemetry in Cassandra and came across CEP-32
>>> . After
>>> reviewing the associated dev mailing list discussions
>>> , 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
>>>
>>>
>>>

Re: Question on CEP-32 and OpenTelemetry Integration

[Patrick McFadin]

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  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  于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 
>> wrote:
>>
>> Hi all,
>>
>> I've been exploring ideas around improving native support for
>> OpenTelemetry in Cassandra and came across CEP-32
>> . After
>> reviewing the associated dev mailing list discussions
>> , 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
>>
>>
>>

Re: Question on CEP-32 and OpenTelemetry Integration

[guo Maxwell]

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  于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 
> wrote:
>
> Hi all,
>
> I've been exploring ideas around improving native support for
> OpenTelemetry in Cassandra and came across CEP-32
> . After
> reviewing the associated dev mailing list discussions
> , 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
>
>
>

Re: Question on CEP-32 and OpenTelemetry Integration

[Josh McKenzie]

> 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  wrote:
>> Hi all,
>> 
>> I've been exploring ideas around improving native support for OpenTelemetry 
>> in Cassandra and came across CEP-32 
>> . After 
>> reviewing the associated dev mailing list discussions 
>> , 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
>> 

Re: Question on CEP-32 and OpenTelemetry Integration

[Dinesh Joshi]

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 
wrote:

> Hi all,
>
> I've been exploring ideas around improving native support for
> OpenTelemetry in Cassandra and came across CEP-32
> . After
> reviewing the associated dev mailing list discussions
> , 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
>