What should instrumenters be doing?

pauldraper commented 2 years ago

What should instrumenters be doing?

For example, I'm instrumenting an RPC library:

I write metrics for how long the exchange takes, how large the request was, and how large the response was, tagged by RPC operation.
I write logs for each RPC operation including how long the exchange takes, how large the request was, how large the response was, and the destination.
I write traces named by the RPC operation, with attributes how large the request was, how large the response was, and the destination.

Does this seem....extremely duplicative to anyone else?

Should I just write to one of these and tell users "well, if you want something else for your SDK/backend, ha ha good luck, you're write a bunch of code to translate from my stuff to your SDK/backend."

This issue really deserves some attention; the entire premise of OTel is that instrumentations and backends can be developed in isolation. This is a very large practical concern for anyone who has actually tried to write a portable, useful instrumentation. (I suspect perhaps many people have not tried this.)

Related: #381, with focus on SDK additions.

pellared commented 1 year ago

I propose to follow (and contribute to) https://opentelemetry.io/docs/specs/semconv.

The semantic conventions should also provide guidelines e.g. https://opentelemetry.io/docs/specs/semconv/general/metrics-general/#general-guidelines

I hope that my comment gives at least some tiny value.

pauldraper commented 1 year ago

Thank you, those semantic conventions strongly imply that signals are written to idependently.

For example, for a HTTP request:

a span is named <method> and the attribute http.request.body.size
a metric is named http.client.duration with the duration
a metric is named http.client.request.size with the body size

The duration of the span and value of http.client.duration is the same. The value of http.request.body.size and http.client.request.size is the same. There is no expected de-duplication of those signals for the implementer.

pellared commented 1 year ago

This is valuable feedback. Can you create an issue for that in https://github.com/open-telemetry/semantic-conventions (especially that the SIG wants to stabilize the HTTP semantic conventions)?

If you have no other concerns/question than you can consider closing this issue afterwards.

pellared commented 1 year ago

CC @open-telemetry/semconv-http-approvers

trask commented 10 months ago

@pauldraper what you say above is correct. HTTP instrumentation should emit both spans and metrics. Some languages (e.g. Java instrumentation) have built a layer on top of the trace and metric APIs which unify them a bit. Maybe https://github.com/open-telemetry/oteps/pull/165 is what you're looking for?

pauldraper commented 10 months ago

Some languages (e.g. Java instrumentation) have built a layer on top of the trace and metric APIs which unify them a bit.

Maybe https://github.com/open-telemetry/oteps/pull/165 is what you're looking for?

Yes.

austinlparker commented 3 months ago

This would be something good for the convenience/devex SIG to think about cc @tsloughter

open-telemetry / opentelemetry-specification

What should instrumenters be doing? #2107