Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

FLIP-274: Introduce metric group for OperatorCoordinator introduced a new metric group for source enumerators to emit metrics. However, there is no way from the Flink REST API to fetch these metrics.

The current metric related REST APIs are the following:

/jobmanager/metrics
/taskmanagers/<taskmanagerid>/metrics
/jobs/<jobid>/metrics
/jobs/<jobid>/vertices/<vertexid>/subtasks/<subtaskindex>
Request metrics aggregated across all entities of the respective type:

/taskmanagers/metrics
/jobs/metrics
/jobs/<jobid>/vertices/<vertexid>/subtasks/metrics

These APIs allow external services to fetch, for example, subtask metrics to do analysis. The coordinator metrics are also an essential set of metrics for jobs that expose how a job is behaving. Currently, the main clients of these REST APIs are the Web UI and the Kubernetes Operator.

Public Interfaces

The REST API needs to add an endpoint and add a new field to an existing response body.

Proposed Changes

Thus, I propose a new REST API

/jobs/<jobid>/vertices/<vertexid>/operators/<operatorid>/metrics

with the query parameter get  that accepts comma separated metric names, like the other APIs. This path is based on https://github.com/apache/flink/blob/7bebd2d9fac517c28afc24c0c034d77cfe2b43a6/flink-runtime/src/main/java/org/apache/flink/runtime/metrics/dump/QueryScopeInfo.java#L234.

In addition, this needs to expose way for users to discover all the operator ids for the path parameter. Following the convention of vertex id and subtask index, the way to discover such information is the job graph that is returned by `/jobs/<jobid>/plan`.

Thus, I propose to add a new field in the response of the form

/jobs/<jobid>/plan Response
{
	...
	"operators": [
		{
			"id": "1"
		},
		{
			"id": "2"
		},
		...
	]
}

In addition, the internal JobManagerOperatorQueryScopeInfo  will need to support indexing by operator id, instead of operator name. The operator id uniquely identifies an operator and on the contrary, the operator name does not (it may be empty or repeated between operators by the user).

Compatibility, Deprecation, and Migration Plan

No compatibility concerns as this is introducing a new API without modifying older APIs. The code modifications are otherwise to internal code.

The change to the QueryScopeInfo is internal and is not expected to be breaking because we don't expose a method to query these metrics yet. The corresponding metric group for job manager operator metrics will not change either because it already attaches both operator name and operator id labels.

Test Plan

Unit tests.

Rejected Alternatives

None.