afedulov commented on code in PR #24564:
URL: https://github.com/apache/flink/pull/24564#discussion_r1543334446


##########
flink-core/src/main/java/org/apache/flink/configuration/MetricOptions.java:
##########
@@ -277,11 +277,12 @@ public static Configuration forReporter(Configuration 
configuration, String repo
      * JobManager of an operator.
      */
     public static final ConfigOption<String> SCOPE_NAMING_JM_OPERATOR =
-            key("metrics.scope.jm-operator")
+            key("metrics.scope.coordinator")

Review Comment:
   +1. The question is - do we expect any other types of "JM operators" to ever 
exist. If we do, in my opinion, we should keep the scope and treat the whole 
`/coodinator-metrics` request code path as a convenience filter on top, not a 
substitution to the broader category.



##########
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:
   There is currently some discrepancy between the endpoint name 
`coordinator-metrics` and the operation name `getJobManagerOperatorMetrics`.  
Should we maybe add some short description about the nature of the coordinator 
(what is is and why it is a JM operator)? We could also consider naming the 
operation in sync with the endpoint. What if some other JM operator type (not a 
coordinator) gets introduced?



##########
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:
   Looking further into the implementation, it seems that it would make sense 
to have a broader `getJobManagerOperatorMetrics` method in case we expect other 
kind of JM operators to exist (not just the coordinators), and add a 
`getCoordinatorMetrics` wrapper to filter the scope of the former.



-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to