You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Our segmentation-consumer custom metric is fairly complicated. The metric tries to strike a balance between consumers and tf=serving pods in order to throttle the number of requests sent to any given tf-serving pod. If any tf-serving pod gets too much traffic, it can go down, which we want to avoid. If we could directly measure the number of requests-per-second the tf-serving pods are getting, the metric could become much more simplified, and more directly reflect the scaling goal.
Describe the solution you'd like
I would like to refactor our custom metrics to utilize gRPC API requests to the tf-serving, instead of the pod ratio. Istio is a tool which is supposed to be able to measure gRPC API requests. Istio should be installed and integrated with prometheus in order to get a better more responsive.
Describe alternatives you've considered
The root cause is that the prometheus-adapter does not measure grpc requests over the network. The goal is to have a prometheus metric that measures the number (and size) of gRPC requests to the tf-serving pods. https://github.com/ynqa/tf_serving_exporter looks promising.
Additional context
This issue was looked into previously, but there was an issue having requests get routed over the Istio service mesh. Perhaps newer releases of Istio have resolved this issue.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Our segmentation-consumer custom metric is fairly complicated. The metric tries to strike a balance between consumers and tf=serving pods in order to throttle the number of requests sent to any given tf-serving pod. If any tf-serving pod gets too much traffic, it can go down, which we want to avoid. If we could directly measure the number of requests-per-second the tf-serving pods are getting, the metric could become much more simplified, and more directly reflect the scaling goal.
Describe the solution you'd like
I would like to refactor our custom metrics to utilize gRPC API requests to the tf-serving, instead of the pod ratio. Istio is a tool which is supposed to be able to measure gRPC API requests. Istio should be installed and integrated with prometheus in order to get a better more responsive.
Describe alternatives you've considered
The root cause is that the
prometheus-adapter
does not measure grpc requests over the network. The goal is to have aprometheus
metric that measures the number (and size) of gRPC requests to the tf-serving pods. https://github.com/ynqa/tf_serving_exporter looks promising.Additional context
This issue was looked into previously, but there was an issue having requests get routed over the Istio service mesh. Perhaps newer releases of Istio have resolved this issue.
The text was updated successfully, but these errors were encountered: