Admaing commented on PR #1226:
URL:
https://github.com/apache/flink-kubernetes-operator/pull/1226#issuecomment-6399198867
Thanks @Dennis-Mircea for the review. Both points are fair — let me answer
them separately.
Breaking change: agreed, and it's worse than my PR description says.
`JobVertexDetailsInfo#getName()`
is always populated for a running job (it comes from
`ExecutionJobVertex#getName()`), so the
"name not reported -> old identifiers" fallback I documented basically never
triggers in practice:
every existing
`AutoScaler.jobVertexID.<id>.<ScalingMetric>.{Current,Average}` series would be
renamed and users' dashboards/alerts would break. That's too much for a
minor improvement.
Label: I looked into it, and Flink's metrics API has no label support for
regular metrics.
`MetricGroup#addGroup(key, value)` creates two *named* child groups, so both
land in the logical
scope; labeling reporters (Prometheus/Datadog/Influx) fold the logical scope
into the metric *name*,
and only scope *variables* become labels -- those are contributed by the
operator's own metric-group
classes (`KubernetesOperatorMetricGroup#putVariables`, etc.). The autoscaler
registers on a generic
`MetricGroup`, so `jobVertexID.<id>` is already part of the name rather than
a label, and making
`jobVertexName` a real label would mean a vertex-scoped metric group in the
operator plus a way for
the autoscaler context to hand it out -- considerably bigger than this
ticket.
So I see two ways forward:
1. keep the identifiers unchanged by default and gate the extra scope behind
`kubernetes.operator.autoscaler.metrics.vertex-name.enabled` (default
`false`, documented,
resolved value logged at INFO) -- no breakage, readable metrics for
whoever opts in;
2. drop the metric rename and just log the vertex name at registration
(`Registering scaling metrics for vertex <name> (<id>)`), and follow up
separately with the
label-based exposure.
I lean towards (1).
--
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]
