mas-chen commented on code in PR #24564: URL: https://github.com/apache/flink/pull/24564#discussion_r1570041925
########## 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: Yes, introducing the operator id would make it difficult for the UI to integrate since metrics APIs rely on the vertexid at the lowest level of granularity. >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? Ah yes, thanks for the suggestion! It would be possible if we formatted the metric by `<operator-name>.<metric-name>`, which I already do in the PR! ########## 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: Yes, introducing the operator id would make it difficult for the UI to integrate since metrics APIs rely on the vertexid at the lowest level of granularity. >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? Ah yes, thanks for the suggestion! It would be possible if we formatted the metric by `<operator-name>.<metric-name>`, which I already do in the PR! -- 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