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