Hi all,
Alex (cc'ed) and I discussed offline about the endpoint path and making it
easier to use. Focusing on the main clients of the Flink Metrics REST API,
the Flink UI and Flink Kubernetes Operator, we determined that exposing the
operator id is unnecessary. There are few considerations:
1. In
Hi all,
I hope that everyone has had sufficient time to review the discussion and
the updates on the FLIP doc. If there are no objections, I'll start a
voting thread in 2 days.
Best,
Mason
On Thu, Jan 18, 2024 at 2:39 PM Mason Chen wrote:
> Hi Lijie,
>
> That's also a possibility but I would p
Hi Lijie,
That's also a possibility but I would prefer to keep it consistent with how
the existing metric APIs are used.
For example, in the current metric APIs [1], there is no way to figure out
the vertexid and subtaskindex without getting the job graph from
`/jobs//plan` and correspondingly th
Hi Mason,
Thanks for driving the discussion. +1 for the proposal.
How about we return all operator metrics in a vertex? (the response is a
map of operatorId/operatorName -> operator-metrics). Correspondingly, the
url may be changed to /jobs//vertices//operator-metrics
In this way, users can skip
Hi, Mason.
The field `operatorName` in JobManagerOperatorQueryScopeInfo refers to the
fields in OperatorQueryScopeInfo and chooses the operatorName instead of
OperatorID.
It is fine by my side to change from opertorName to operatorID in this
FLIP.
Best,
Hang
Mason Chen 于2024年1月17日周三 09:39写道：
>
Hi Xuyang and Hang,
Thanks for your support and feedback! See my responses below:
1. IIRC, in a sense, operator ID and vertex ID are the same thing. The
> operator ID can
> be converted from the vertex ID[1]. Therefore, it is somewhat strange to
> have both vertex
> ID and operator ID in a single
Hi, Mason.
Thanks for driving this FLIP.
The JobManagerOperatorQueryScopeInfo has three fields: jobID, vertexID and
operatorName. So we should use the operator name in the API.
If you think we should use the operator id, there need be more changes
about it.
About the Xuyang's questions, we add b
Hi, Mason.
Thanks for driving this Flip. I think it's important for external system to be
able to
perceive the metric of the operator coordinator. +1 for it.
I just have the following minor questions and am looking forward to your reply.
Please forgive
me if I have some misunderstandings.
1.
Hi Devs,
I'm opening this thread to discuss a short FLIP for exposing
JobManagerOperatorMetrics via REST API [1].
The current set of REST APIs make it impossible to query coordinator
metrics. This FLIP proposes a new REST API to query the
JobManagerOperatorMetrics.
[1]
https://cwiki.apache.org/c
