Full support for gRPC server metrics

[ncabanis]

Description

Quarkus is currently exposing grpc_server_processing_duration_seconds_count, grpc_server_processing_duration_seconds_sum and grpc_server_processing_duration_seconds_max metrics for measuring latency.

I would expect the grpc.server.call.duration Histogram as specified here: https://grpc.io/docs/guides/opentelemetry-metrics/#server-instruments

The histogram allows in much more detail to understand the latency.

Implementation ideas

No response

[quarkus-bot]

/cc @alesj (grpc), @cescoffier (grpc), @ebullient (metrics), @jmartisk (metrics)

[cescoffier]

@brunobat aren't _count, _sum... how histograms are mapped?

[brunobat]

@ncabanis Quarkus is not following OpenTelemetry semantic convention metrics for gRPC because they are experimental and can still change.
The mentioned metric is produced by Micrometer and follow the prometheus format.

[ncabanis]

I'm not speaking about the format (Prometheus via Micrometer is fine), its about the missing histogram.

[cescoffier]

Just looked at io.micrometer.core.instrument.binder.grpc.MetricCollectingServerInterceptor, and yes, it does not use Gauge, just timer and counter.

[cescoffier]

@brunobat shouldn't the timer be a TimeGauge or a Gauge?

\CC @alesj

[brunobat]

Micrometer Timers can produce histograms but they need to be configured.
What I see is that we are only setting the registry:

quarkus/extensions/micrometer/runtime/src/main/java/io/quarkus/micrometer/runtime/binder/grpc/GrpcMetricsServerInterceptor.java

Line 18 in ebee0a4

super(registry);

We should be setting the Timer.Builder to get that data.

Saying this, this should probably be done as an option, and disabled by default because it can impact memory consumption in current deployments,

See: ...io/micrometer/micrometer-core/1.14.3/micrometer-core-1.14.3-sources.jar!/io/micrometer/core/instrument/binder/grpc/MetricCollectingServerInterceptor.java:88

and

io.micrometer.core.instrument.Timer.Builder