New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GrpcMeterIdPrefixFunction
?
#2762
Comments
To make static MeterIdPrefixFunction ofDefault(
String name,
BiConsumer<MeterRegistry, ? super RequestOnlyLog> consumer
) {
...
} or default MeterIdPrefixFunction andThen(
Function3<MeterRegistry, ? super RequestOnlyLog, MeterIdPrefix, MeterIdPrefix> consumer
) {
...
} |
That's a good idea. I like the latter. What do you think, @line/dx? |
I also prefer the |
…questLog (#2839) Preparation for #2762. Motivations: Currently, `MeterIdPrefixFunction` can be customized with [`andThen`](https://github.com/line/armeria/blob/armeria-0.99.7/core/src/main/java/com/linecorp/armeria/common/metric/MeterIdPrefixFunction.java#L179-L193) which takes a function of type `(MeterRegistry, MeterIdPrefix) -> MeterIdPrefix`. But, without taking `RequestLog`, we cannot append header values to `MeterIdPrefix`. Modifications: - Add `andThen: (MeterRegistry, RequestOnlyLog, MeterIdPrefix) -> MeterIdPrefix` - Deprecate the original version `andThen(BiFunction<MeterRegistry, MeterIdPrefix, MeterIdPrefix>)` Results: Users can customize `MeterIdPrefixFunction` easily like ```java MeterIdPrefixFunction .ofDefault("hoge") .andThen((registry, log, id) -> { if (log instanceof RequestLog) { return id.withTags("grpc-status", log.responseHeaders().get("grpc-status")); } else { return id; } }); ```
Now, we can set BTW, is it better to offer |
That's a good question. I think it will be useful to provide one out of the box. It'd be nice if we have an optimized version, but we will have to refactor a little bit to de-duplicate the common logic from the default prefix function. Alternatively, we could duplicate a little bit and just write some tight test cases. |
I prefer
|
How could we get the |
Probably worth getting this done before 1.0 to solve the gRPC-Web trailer handling problem.. |
Let me work on this after finishing #2911 |
Motivation: It'd be nice to have a dedicated `MeterIdPrefixFunction` implementation for gRPC, so that the tag for grpc-status is added automatically. Modifications: - Add `GrpcMeterIdPrefixFunction`. - Insert `GrpcWebTrailersExtrator` before `HttpClientDelegate` when the gRPC-web client is created. - Remove `GrpcWebUtil.parseTrailers()` which was used to extract web trailers from RetringClient. - Could use `GrpcWebUtil.trailers(ctx)` to get gRPC web trailers instead. - Add `DefaultMeterIdPrefixFunction` which `GrpcMeterIdPrefixFunction` and `RetrofitMeterIdPrefixFunction` extend. Result: - Close line#2762 - You can now use `GrpcMeterIdPrefixFunction` to add `grpc.status` tag to the metric easily. To-do: - The marking of successes and failures is not working well when `MetricCollectingClient` is between `RetryingClient` and `HttpClientDelegate`.
Motivation: It'd be nice to have a dedicated `MeterIdPrefixFunction` implementation for gRPC, so that the tag for grpc-status is added automatically. Modifications: - Add `GrpcMeterIdPrefixFunction`. - Insert `GrpcWebTrailersExtrator` before `HttpClientDelegate` when the gRPC-web client is created. - Remove `GrpcWebUtil.parseTrailers()` which was used to extract web trailers from RetringClient. - Could use `GrpcWebUtil.trailers(ctx)` to get gRPC web trailers instead. - Add `DefaultMeterIdPrefixFunction` which `GrpcMeterIdPrefixFunction` and `RetrofitMeterIdPrefixFunction` extend. - Add `AbstractClientOptionsBuilder.clearDecorator()` to remove decorators set. - Add meter tags in the Alphabet order. Result: - Close line#2762 - You can now use `GrpcMeterIdPrefixFunction` to add `grpc.status` tag to the metric easily. To-do: - The marking of successes and failures is not working well when `MetricCollectingClient` is between `RetryingClient` and `HttpClientDelegate`.
Motivation: It'd be nice to have a dedicated `MeterIdPrefixFunction` implementation for gRPC, so that the tag for grpc-status is added automatically. Modifications: - Add `GrpcMeterIdPrefixFunction`. - Insert `GrpcWebTrailersExtrator` before `HttpClientDelegate` when the gRPC-web client is created. - Remove `GrpcWebUtil.parseTrailers()` which was used to extract web trailers from RetringClient. - Could use `GrpcWebUtil.trailers(ctx)` to get gRPC web trailers instead. - Add `DefaultMeterIdPrefixFunction` which `GrpcMeterIdPrefixFunction` and `RetrofitMeterIdPrefixFunction` extend. - Add `AbstractClientOptionsBuilder.clearDecorator()` to remove decorators set. - Add meter tags in the Alphabet order. - Add grpc-status header to the unframed grpc service response headers. Result: - Close line#2762 - You can now use `GrpcMeterIdPrefixFunction` to add `grpc.status` tag to the metric easily. To-do: - The marking of successes and failures is not working well when `MetricCollectingClient` is between `RetryingClient` and `HttpClientDelegate`.
Motivation: It'd be nice to have a dedicated `MeterIdPrefixFunction` implementation for gRPC, so that the tag for grpc-status is added automatically. Modifications: - Add `GrpcMeterIdPrefixFunction`. - Insert `GrpcWebTrailersExtrator` before `HttpClientDelegate` when the gRPC-web client is created. - Remove `GrpcWebUtil.parseTrailers()` which was used to extract web trailers from RetringClient. - Could use `GrpcWebUtil.trailers(ctx)` to get gRPC web trailers instead. - Add `DefaultMeterIdPrefixFunction` which `GrpcMeterIdPrefixFunction` and `RetrofitMeterIdPrefixFunction` extend. - Add `AbstractClientOptionsBuilder.clearDecorator()` to remove decorators set. - Add meter tags in the Alphabet order. - Add grpc-status header to the unframed grpc service response headers. Result: - Close line#2762 - You can now use `GrpcMeterIdPrefixFunction` to add `grpc.status` tag to the metric easily. To-do: - The marking of successes and failures is not working well when `MetricCollectingClient` is between `RetryingClient` and `HttpClientDelegate`.
Motivation: It'd be nice to have a dedicated `MeterIdPrefixFunction` implementation for gRPC, so that the tag for grpc-status is added automatically. Modifications: - Add `GrpcMeterIdPrefixFunction`. - Insert `GrpcWebTrailersExtrator` before `HttpClientDelegate` when the gRPC-web client is created. - Remove `GrpcWebUtil.parseTrailers()` which was used to extract web trailers from RetringClient. - Could use `GrpcWebTrailers.get(ctx)` to get gRPC web trailers instead. - Add `DefaultMeterIdPrefixFunction` which `GrpcMeterIdPrefixFunction` and `RetrofitMeterIdPrefixFunction` extend. - Add `AbstractClientOptionsBuilder.clearDecorator()` to remove decorators set. - Add meter tags in the Alphabet order. - Add grpc-status header to the unframed grpc service response headers. Result: - Close #2762 - You can now use `GrpcMeterIdPrefixFunction` to add `grpc.status` tag to the metric easily. To-do: - The marking of successes and failures is not working well when `MetricCollectingClient` is between `RetryingClient` and `HttpClientDelegate`.
When using gRPC with |
Motivation: Armeria Spring Integration always uses `MeterIdPrefixFunction.ofDefault` when `enable-metrics` is set to true. It'd be good if users can configure the `MeterIdPrefixFunction` Armeria uses. and #2762 (comment) Modifications: - Add an argument `Optional<MeterIdPrefixFunction>` to `ArmeriaAutoConfiguration.armeriaServer` - Add an argument `MeterIdPrefixFunction` to `ArmeriaConfigurationUtil.configureServerWithArmeriaSettings` Result: The `MeterIdPrefixFunction` bean which users register will be used. If the bean is not present, `MeterIdPrefixFunction.ofDefault` will be used.
…questLog (line#2839) Preparation for line#2762. Motivations: Currently, `MeterIdPrefixFunction` can be customized with [`andThen`](https://github.com/line/armeria/blob/armeria-0.99.7/core/src/main/java/com/linecorp/armeria/common/metric/MeterIdPrefixFunction.java#L179-L193) which takes a function of type `(MeterRegistry, MeterIdPrefix) -> MeterIdPrefix`. But, without taking `RequestLog`, we cannot append header values to `MeterIdPrefix`. Modifications: - Add `andThen: (MeterRegistry, RequestOnlyLog, MeterIdPrefix) -> MeterIdPrefix` - Deprecate the original version `andThen(BiFunction<MeterRegistry, MeterIdPrefix, MeterIdPrefix>)` Results: Users can customize `MeterIdPrefixFunction` easily like ```java MeterIdPrefixFunction .ofDefault("hoge") .andThen((registry, log, id) -> { if (log instanceof RequestLog) { return id.withTags("grpc-status", log.responseHeaders().get("grpc-status")); } else { return id; } }); ```
Motivation: It'd be nice to have a dedicated `MeterIdPrefixFunction` implementation for gRPC, so that the tag for grpc-status is added automatically. Modifications: - Add `GrpcMeterIdPrefixFunction`. - Insert `GrpcWebTrailersExtrator` before `HttpClientDelegate` when the gRPC-web client is created. - Remove `GrpcWebUtil.parseTrailers()` which was used to extract web trailers from RetringClient. - Could use `GrpcWebTrailers.get(ctx)` to get gRPC web trailers instead. - Add `DefaultMeterIdPrefixFunction` which `GrpcMeterIdPrefixFunction` and `RetrofitMeterIdPrefixFunction` extend. - Add `AbstractClientOptionsBuilder.clearDecorator()` to remove decorators set. - Add meter tags in the Alphabet order. - Add grpc-status header to the unframed grpc service response headers. Result: - Close line#2762 - You can now use `GrpcMeterIdPrefixFunction` to add `grpc.status` tag to the metric easily. To-do: - The marking of successes and failures is not working well when `MetricCollectingClient` is between `RetryingClient` and `HttpClientDelegate`.
Originally suggested by @okue
It'd be nice to have a dedicated
MeterIdPrefixFunction
implementation for gRPC, so that the tag forgrpc-status
is added automatically.The text was updated successfully, but these errors were encountered: