You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Richard Zowalla <rz...@apache.org> on 2024/11/19 08:27:41 UTC
Would appreciate some additional eyes on OpenTelemetry 1.0
Hi all,
On [1] you can find an experiment to replace OpenTracing 3 with OpenTelemetry 1.0 for MicroProfile 6+
The current status of the (super small TCK for it) is, that we have a few failures due to different expectations between span names in the test assumption (although the actual path looks fine).
[ERROR] BaggageTest>Arquillian.run:138->baggage:81 » ConditionTimeout Assertion condition defined as a org.eclipse.microprofile.telemetry.tracing.tck.exporter.InMemorySpanExporter expected [2] but found [1] within 10 seconds.
[ERROR] RestSpanTest>Arquillian.run:138->span:107 expected [/4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span] but found [GET /4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span]
[ERROR] RestSpanTest>Arquillian.run:138->spanName:128 expected [/4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span/{name}] but found [GET /4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span/{name}]
[ERROR] RestSpanTest>Arquillian.run:138->spanNameWithoutQueryString:140 expected [/4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span/{name}] but found [GET /4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span/{name}]
I didn’t find any clarification in the spec [2] what the span name should be (http route vs http method + http route). Does anyone has a glue for it?
Regardless of that, it seems, that the MP people have rewritten the test suite for OpenTelemetry 2.0 (MP7) completely and this assertions aren’t present anymore (maybe because they were just vendor specific?!).
So I don’t know, how we want to proceed here.
On the one hand, it might be good to drop OpenTracing in favor of the OpenTelemetry 1.0 integration although we do not pass the TCK for it but would be a step towards MP6+ (and to upgrade from 1.0 to 2.0 might be easier).
On the other hand, the OpenTracing implementation brings in a lot of crappy dependencies (imho) with some of them being in alpha state bloating our distribution.
Questions:
- (1) Does anyone has a glue regarding the span naming? Maybe someone wants to do some digging on this too?
- (2) How do we want to proceed?
Gruß
Richard
[1] https://github.com/apache/tomee/tree/TOMEE-4343
[2] https://download.eclipse.org/microprofile/microprofile-telemetry-1.0/tracing/microprofile-telemetry-tracing-spec-1.0.html
Re: Would appreciate some additional eyes on OpenTelemetry 1.0
Posted by Richard Zowalla <rz...@apache.org>.
TCK for OpenTelemetry 1.0 is green now. Thanks to Markus for digging
into it and donating some time :)
With that in our pocket, we now have a valid baseline to start on
upgrading our micro profile version.
Gruß
Richard
Am Samstag, dem 23.11.2024 um 15:28 +0100 schrieb Richard Zowalla:
> Thanks Markus!
>
> The MP spec world is acutally pretty confusing, imho (also with a lot
> of breakage in betweeen).
>
> To bring our current progress on the list:
>
> Markus and myself are still looking into OpenTelemetry 1.0 to fix the
> remaining TCK test. Looks like it requires a specific OpenTelemetry
> ClientRequest|ResponseFilter to be registered on the JAX-RS client.
>
> Gruß
> Richard
>
>
>
>
> Am Freitag, dem 22.11.2024 um 10:42 +0100 schrieb Markus Jung:
> > Hey Richard,
> >
> >
> > I did some digging now and it seems like the format for the span
> > names
> > comes from the opentelemetry (not to be confused with microprofile
> > telemetry) specification:
> > https://opentelemetry.io/docs/specs/semconv/http/http-spans/#name
> > This appears to have been changed some time ago
> > https://github.com/open-telemetry/opentelemetry-specification/issues/2998
> >
> > and landed in opentelemetry 1.23.0, so anything >= 1.23.0 will fail
> > the
> > microprofile telemetry 1.0 TCK.
> >
> > Running the TCK against smallrye-opentelemetry 2.3.2 (which uses
> > opentelemetry 1.20.2):
> >
> > [INFO] Results:
> > [INFO]
> > [ERROR] Failures:
> > [ERROR] BaggageTest>Arquillian.run:138->baggage:81 »
> > ConditionTimeout
> > Assertion condition defined as a
> > org.eclipse.microprofile.telemetry.tracing.tck.exporter.InMemorySpa
> > nE
> > xporter
> > expected [2] but found [1] within 10 seconds.
> > [INFO]
> > [ERROR] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0
> >
> >
> > I pushed the correct version of smallrye-opentelemetry to your
> > branch
> > :)
> >
> >
> > Thanks
> >
> > Markus
> >
> >
> > On 19.11.24 09:27, Richard Zowalla wrote:
> > > Hi all,
> > >
> > > On [1] you can find an experiment to replace OpenTracing 3 with
> > > OpenTelemetry 1.0 for MicroProfile 6+
> > >
> > > The current status of the (super small TCK for it) is, that we
> > > have
> > > a few failures due to different expectations between span names
> > > in
> > > the test assumption (although the actual path looks fine).
> > >
> > > [ERROR] BaggageTest>Arquillian.run:138->baggage:81 »
> > > ConditionTimeout Assertion condition defined as a
> > > org.eclipse.microprofile.telemetry.tracing.tck.exporter.InMemoryS
> > > pa
> > > nExporter expected [2] but found [1] within 10 seconds.
> > > [ERROR] RestSpanTest>Arquillian.run:138->span:107 expected
> > > [/4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span] but found [GET
> > > /4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span]
> > > [ERROR] RestSpanTest>Arquillian.run:138->spanName:128 expected
> > > [/4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span/{name}] but found
> > > [GET
> > > /4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span/{name}]
> > > [ERROR] RestSpanTest>Arquillian.run:138-
> > > > spanNameWithoutQueryString:140 expected [/4ceb08bf-e548-4e5d-
> > > > aa26-
> > > e64d2f5b4e89/span/{name}] but found [GET /4ceb08bf-e548-4e5d-
> > > aa26-
> > > e64d2f5b4e89/span/{name}]
> > >
> > > I didn’t find any clarification in the spec [2] what the span
> > > name
> > > should be (http route vs http method + http route). Does anyone
> > > has
> > > a glue for it?
> > >
> > > Regardless of that, it seems, that the MP people have rewritten
> > > the
> > > test suite for OpenTelemetry 2.0 (MP7) completely and this
> > > assertions aren’t present anymore (maybe because they were just
> > > vendor specific?!).
> > >
> > > So I don’t know, how we want to proceed here.
> > >
> > > On the one hand, it might be good to drop OpenTracing in favor of
> > > the OpenTelemetry 1.0 integration although we do not pass the TCK
> > > for it but would be a step towards MP6+ (and to upgrade from 1.0
> > > to
> > > 2.0 might be easier).
> > > On the other hand, the OpenTracing implementation brings in a lot
> > > of crappy dependencies (imho) with some of them being in alpha
> > > state bloating our distribution.
> > >
> > > Questions:
> > >
> > > - (1) Does anyone has a glue regarding the span naming? Maybe
> > > someone wants to do some digging on this too?
> > > - (2) How do we want to proceed?
> > >
> > > Gruß
> > > Richard
> > >
> > > [1] https://github.com/apache/tomee/tree/TOMEE-4343
> > > [2]
> > > https://download.eclipse.org/microprofile/microprofile-telemetry-1.0/tracing/microprofile-telemetry-tracing-spec-1.0.html
> > >
> > >
>
Re: Would appreciate some additional eyes on OpenTelemetry 1.0
Posted by Richard Zowalla <rz...@apache.org>.
Thanks Markus!
The MP spec world is acutally pretty confusing, imho (also with a lot
of breakage in betweeen).
To bring our current progress on the list:
Markus and myself are still looking into OpenTelemetry 1.0 to fix the
remaining TCK test. Looks like it requires a specific OpenTelemetry
ClientRequest|ResponseFilter to be registered on the JAX-RS client.
Gruß
Richard
Am Freitag, dem 22.11.2024 um 10:42 +0100 schrieb Markus Jung:
> Hey Richard,
>
>
> I did some digging now and it seems like the format for the span
> names
> comes from the opentelemetry (not to be confused with microprofile
> telemetry) specification:
> https://opentelemetry.io/docs/specs/semconv/http/http-spans/#name
> This appears to have been changed some time ago
> https://github.com/open-telemetry/opentelemetry-specification/issues/2998
>
> and landed in opentelemetry 1.23.0, so anything >= 1.23.0 will fail
> the
> microprofile telemetry 1.0 TCK.
>
> Running the TCK against smallrye-opentelemetry 2.3.2 (which uses
> opentelemetry 1.20.2):
>
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BaggageTest>Arquillian.run:138->baggage:81 »
> ConditionTimeout
> Assertion condition defined as a
> org.eclipse.microprofile.telemetry.tracing.tck.exporter.InMemorySpanE
> xporter
> expected [2] but found [1] within 10 seconds.
> [INFO]
> [ERROR] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0
>
>
> I pushed the correct version of smallrye-opentelemetry to your branch
> :)
>
>
> Thanks
>
> Markus
>
>
> On 19.11.24 09:27, Richard Zowalla wrote:
> > Hi all,
> >
> > On [1] you can find an experiment to replace OpenTracing 3 with
> > OpenTelemetry 1.0 for MicroProfile 6+
> >
> > The current status of the (super small TCK for it) is, that we have
> > a few failures due to different expectations between span names in
> > the test assumption (although the actual path looks fine).
> >
> > [ERROR] BaggageTest>Arquillian.run:138->baggage:81 »
> > ConditionTimeout Assertion condition defined as a
> > org.eclipse.microprofile.telemetry.tracing.tck.exporter.InMemorySpa
> > nExporter expected [2] but found [1] within 10 seconds.
> > [ERROR] RestSpanTest>Arquillian.run:138->span:107 expected
> > [/4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span] but found [GET
> > /4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span]
> > [ERROR] RestSpanTest>Arquillian.run:138->spanName:128 expected
> > [/4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span/{name}] but found [GET
> > /4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span/{name}]
> > [ERROR] RestSpanTest>Arquillian.run:138-
> > >spanNameWithoutQueryString:140 expected [/4ceb08bf-e548-4e5d-aa26-
> > e64d2f5b4e89/span/{name}] but found [GET /4ceb08bf-e548-4e5d-aa26-
> > e64d2f5b4e89/span/{name}]
> >
> > I didn’t find any clarification in the spec [2] what the span name
> > should be (http route vs http method + http route). Does anyone has
> > a glue for it?
> >
> > Regardless of that, it seems, that the MP people have rewritten the
> > test suite for OpenTelemetry 2.0 (MP7) completely and this
> > assertions aren’t present anymore (maybe because they were just
> > vendor specific?!).
> >
> > So I don’t know, how we want to proceed here.
> >
> > On the one hand, it might be good to drop OpenTracing in favor of
> > the OpenTelemetry 1.0 integration although we do not pass the TCK
> > for it but would be a step towards MP6+ (and to upgrade from 1.0 to
> > 2.0 might be easier).
> > On the other hand, the OpenTracing implementation brings in a lot
> > of crappy dependencies (imho) with some of them being in alpha
> > state bloating our distribution.
> >
> > Questions:
> >
> > - (1) Does anyone has a glue regarding the span naming? Maybe
> > someone wants to do some digging on this too?
> > - (2) How do we want to proceed?
> >
> > Gruß
> > Richard
> >
> > [1] https://github.com/apache/tomee/tree/TOMEE-4343
> > [2]
> > https://download.eclipse.org/microprofile/microprofile-telemetry-1.0/tracing/microprofile-telemetry-tracing-spec-1.0.html
> >
> >
Re: Would appreciate some additional eyes on OpenTelemetry 1.0
Posted by Markus Jung <ju...@apache.org>.
Hey Richard,
I did some digging now and it seems like the format for the span names
comes from the opentelemetry (not to be confused with microprofile
telemetry) specification:
https://opentelemetry.io/docs/specs/semconv/http/http-spans/#name
This appears to have been changed some time ago
https://github.com/open-telemetry/opentelemetry-specification/issues/2998
and landed in opentelemetry 1.23.0, so anything >= 1.23.0 will fail the
microprofile telemetry 1.0 TCK.
Running the TCK against smallrye-opentelemetry 2.3.2 (which uses
opentelemetry 1.20.2):
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BaggageTest>Arquillian.run:138->baggage:81 » ConditionTimeout
Assertion condition defined as a
org.eclipse.microprofile.telemetry.tracing.tck.exporter.InMemorySpanExporter
expected [2] but found [1] within 10 seconds.
[INFO]
[ERROR] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0
I pushed the correct version of smallrye-opentelemetry to your branch :)
Thanks
Markus
On 19.11.24 09:27, Richard Zowalla wrote:
> Hi all,
>
> On [1] you can find an experiment to replace OpenTracing 3 with OpenTelemetry 1.0 for MicroProfile 6+
>
> The current status of the (super small TCK for it) is, that we have a few failures due to different expectations between span names in the test assumption (although the actual path looks fine).
>
> [ERROR] BaggageTest>Arquillian.run:138->baggage:81 » ConditionTimeout Assertion condition defined as a org.eclipse.microprofile.telemetry.tracing.tck.exporter.InMemorySpanExporter expected [2] but found [1] within 10 seconds.
> [ERROR] RestSpanTest>Arquillian.run:138->span:107 expected [/4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span] but found [GET /4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span]
> [ERROR] RestSpanTest>Arquillian.run:138->spanName:128 expected [/4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span/{name}] but found [GET /4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span/{name}]
> [ERROR] RestSpanTest>Arquillian.run:138->spanNameWithoutQueryString:140 expected [/4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span/{name}] but found [GET /4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span/{name}]
>
> I didn’t find any clarification in the spec [2] what the span name should be (http route vs http method + http route). Does anyone has a glue for it?
>
> Regardless of that, it seems, that the MP people have rewritten the test suite for OpenTelemetry 2.0 (MP7) completely and this assertions aren’t present anymore (maybe because they were just vendor specific?!).
>
> So I don’t know, how we want to proceed here.
>
> On the one hand, it might be good to drop OpenTracing in favor of the OpenTelemetry 1.0 integration although we do not pass the TCK for it but would be a step towards MP6+ (and to upgrade from 1.0 to 2.0 might be easier).
> On the other hand, the OpenTracing implementation brings in a lot of crappy dependencies (imho) with some of them being in alpha state bloating our distribution.
>
> Questions:
>
> - (1) Does anyone has a glue regarding the span naming? Maybe someone wants to do some digging on this too?
> - (2) How do we want to proceed?
>
> Gruß
> Richard
>
> [1] https://github.com/apache/tomee/tree/TOMEE-4343
> [2] https://download.eclipse.org/microprofile/microprofile-telemetry-1.0/tracing/microprofile-telemetry-tracing-spec-1.0.html
>
>