What should instrumenters be doing?

[pauldraper]

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]

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]

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]

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]

CC @open-telemetry/semconv-http-approvers

[trask]

@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 open-telemetry/oteps#165 is what you're looking for?

[pauldraper]

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

Maybe open-telemetry/oteps#165 is what you're looking for?

Yes.

[austinlparker]

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