Metrics names are not following OpenTelemetry conventions

[chameleon82]

I know it is currently short list of agreed metrics names https://opentelemetry.io/docs/reference/specification/metrics/semantic_conventions/http-metrics/#http-client

So open this for discussion of possible span name standardization

sttp_request_latency          -> http.client.duration
sttp_requests_in_progress     -> http.client.active_requests
sttp_requests_success_count   -> http.client.success_count ?
sttp_requests_error_count     -> http.client.error_count ?
sttp_requests_failure_count   -> http.client.failure_count ?
sttp_request_size_bytes       -> http.client.request.size
sttp_response_size_bytes      -> http.client.response.size

ref: https://github.com/softwaremill/sttp/blob/a87da572ba66ee3e9016322cf021e21ffd1ea06f/observability/opentelemetry-metrics-backend/src/main/scala/sttp/client3/opentelemetry/OpenTelemetryMetricsBackend.scala#L12

Also one of the ways those metrics can be collected and visualized with grafana: https://grafana.com/grafana/plugins/novatec-sdg-panel/ where particullary important to have next information in the metrics attributes:

• service.name
• peer.name

[adamw]

Good point, let's adjust the metric names we use to these conventions. Probably would be good to include an OpenTelemetryMetricsBackend.legacy constructor, which would use the old names.

As for the service name / peer name, these would be effectively constant, right? Or are they set per-request? How do you set these so that they are sent to OT?

Maybe we'd need some kind of customisation method so that these can be properly computed depending on the Request

[chameleon82]

Yes, service.name and peer.name are constant per client. But additional constant attributes may also be provided, for example for rpc services rpc.name is expected.

There are also cases where attributes can be additionally defined by request - for example, service mesh can add attribute http.resend_count on retries (https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/http/#http-client), but those tracing specific. For metrics, probably, that doesn't make sense to have attributes per request as attributes will be applied to aggregators.

[adamw]

Thanks - would you maybe be willing to work on a PR to introduce these changes?

[chameleon82]

I would postpone it due semantic convention updates https://docs.google.com/presentation/d/1QUeV4v9tlCRB9X3G2wrbjAKmCLaFN5qDKAa9wS9jx0s/edit?usp=drivesdk

[adamw]

@chameleon82 thanks for the heads-up :) I think it would make even more sense then to introduce a number of different metric name sets, maybe not even designating a default one, as to leave the space open for future changes (as the one above)