afedulov commented on code in PR #24564:
URL: https://github.com/apache/flink/pull/24564#discussion_r1568653505
##########
docs/static/generated/rest_v1_dispatcher.yml:
##########
@@ -1089,6 +1089,37 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/JobVertexBackPressureInfo'
+ /jobs/{jobid}/vertices/{vertexid}/coordinator-metrics:
+ get:
+ description: Provides access to job manager operator metrics
Review Comment:
I see, thanks for the clarification. I believe the main issue with the
original proposal was that it also implied that the user would need to supply
operator ID (as reflected in the FLIP's rejected approaches
`/jobs/<jobid>/vertices/<vertexid>/operators/<operatorid>/metrics`). This would
necessitate an additional step to identify which operator serves as the
coordinator.
It seems the challenge of distinguishing between the coordinator's metrics
and other types of JobManager operators that may emerge in the future remains.
Suppose we consolidate everything under the `/jm-operator-metrics` endpoint.
When focusing on the coordinator's metrics for autoscaling purposes, how will
API users distinguish these from other metrics retrieved from
`/jm-operator-metrics`? Can be sure that the metrics of interest are always
uniquely identified by their names, preventing any overlap with those emitted
by other operators?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@flink.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
