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
