Conversation
|
|
be-hase
force-pushed
the
micrometer-tracing
branch
2 times, most recently
from
ae599b1 to
71e0393
Compare
|
typo in commit/title : micromater -> micrometer |
be-hase
force-pushed
the
micrometer-tracing
branch
from
71e0393 to
639f5e4
Compare
be-hase
force-pushed
the
micrometer-tracing
branch
from
639f5e4 to
5de5950
Compare
|
Added integration test code. |
ocadaruma
left a comment
ocadaruma
left a comment
There was a problem hiding this comment.
Thanks for your PR!
I haven't known micrometer provides a tracing facade.
Almost looks good. Left few comments and questions.
| // Since the context of parent is injected in Callback of `producer.send`, create the span manually. | ||
| // ref: https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/8a15975dcacda48375cae62e98fe7551fb192d1f/instrumentation/kafka/kafka-clients/kafka-clients-2.6/library/src/main/java/io/opentelemetry/instrumentation/kafkaclients/v2_6/KafkaTelemetry.java#L262-L264 | ||
| @Override | ||
| public Future<RecordMetadata> send(ProducerRecord<K, V> record, Callback callback) { |
There was a problem hiding this comment.
Is my understanding below correct?
- As you mentioned, otel KafkaTelemetry executes producer callback inside the parent context, which no traceId is associated unless we explicitly provide some
- ProcessingGuarantee's onProduce is executed in producer callback. Hence, we need to create a span manually to supply some traceId
| .run(); | ||
| } | ||
|
|
||
| private static class WithParentSpanProducer<K, V> implements Producer<K, V> { |
There was a problem hiding this comment.
There's a convenient abstract class com.linecorp.decaton.testing.processor.ProducerAdaptor for avoiding implementing all producer methods with just delegating to the underlying producer.
Let's make it public and use it?
| import io.opentelemetry.instrumentation.kafkaclients.v2_6.KafkaTelemetry; | ||
| import io.opentelemetry.sdk.OpenTelemetrySdk; | ||
|
|
||
| public class MicrometerTracingOtelBridgeTest { |
There was a problem hiding this comment.
By the way do we need to add separate integration tests for each tracer impls?
I think testing with just one tracer impl (to assert the facade usage) is sufficient from Decaton's point of view, because Decaton's responsibility is just using micrometer's tracing facade correctly, so I don't think checking if traces are actually propagated in each tracer is meaningful.
There was a problem hiding this comment.
As you say, from decaton's point of view, it may be enough to test with one tracer.
(It is the responsibility of micrometer-tracing to verify operation with multiple tracers.)
So, shall I delete MicrometerTracingBraveBridgeTest ?
Because it is similar to the decaton-brave module.
There was a problem hiding this comment.
shall I delete MicrometerTracingBraveBridgeTest
Sounds good.
|
thanks :) |
4 participants
micrometer-tracing is now available.
https://micrometer.io/docs/tracing
It may be a minor library at present, but with the support of micrometer-tracing from spring boot3, demand may increase in the future.
micrometer-tracing is a facade of brave and opentelemetry-java.
Therefore, if decaton supports micrometer-tracing, opentelemetry-java can also be supported.
(I think opentelemetry-java users will be happy)