grpc-swift
grpc-swift copied to clipboard
grpc
Provide connection pool metrics
As a developer using grpc-swift, I would love to instrument my outgoing grpc connections with swift-metrics. Since connections are mostly handled by grpc-swift, grpc-swift should expose those metrics.
Metrics I would like to export:
- How many open connections in a given pool
- How many streams on a given connection
- Connect failures and types for a pool
- Connect latency for a pool
Describe the solution you'd like
grpc-swift should accept a MetricsDelegate on grpc connection pool creation. If the pool state changes the delegate should be informed. The protocol could look something like this. First raw draft.
protocol GRPCChannelPoolMetricsDelegate {
func connectionCreated(connectionID: Int, latency: Int)
func connectionUtilizationChanged(connectionID: Int, available: Int, used: Int)
func connectionClosed(connectionID: Int, error: Error?)
func connectFailure(error: Error)
}
Describe alternatives you've considered
GRPC could export metrics directly to swift-metrics. However this would add a new dependency, that some adopters might not want. Further adopters may want to report the metrics differently and we want to give them options. Offering the connection metrics through a protocol should give adopters the most flexibility.
Wondering if there are any other purposes these delegates could be used for - nothing springs immediately to mind but I could imagine there might be something else which users try and trigger off connection creation.
I guess this is more flexible than direct call to metrics but a bit harder for users to use.
I think we could probably offer a default solution in a separate target. That doesn't prevent us having the dependency but users who don't want it can at least avoid linking it in.
I guess this is more flexible than direct call to metrics but a bit harder for users to use.
Flexibility is a good thing here, no doubt people will want to label metrics in their own way.
I think we could probably offer a default solution in a separate target. That doesn't prevent us having the dependency but users who don't want it can at least avoid linking it in.
A "GRPCExtras" module is something I've thought about for a while. There are other general purpose things like interceptors which could be included.
