Как читать экспорт метрик Flink, и какие цифры реально важны?

Flink отдаёт метрики через REST API (или JMX, или любой репортер на выбор) в виде плоского JSON: одна запись на имя метрики на таск/оператор/задачу, без встроенной приоритизации того, что важно.

Форма экспорта метрик

Запрос к /jobs/<id>/vertices/<vertex-id>/metrics возвращает массив объектов {"id": "...", "value": "..."} — плоский, без вложенности и без указания, какие из них стоит смотреть в первую очередь. Это нужно знать заранее самому, поскольку сам API считает счётчик пауз GC и реальный счётчик пропускной способности одинаково важными.

Небольшой набор, важный для первого прохода

busyTimeMsPerSecond — сколько времени в каждой секунде таск реально занимался работой, ближайший аналог метрики утилизации во Flink. numRecordsInPerSecond / numRecordsOutPerSecond — реальная пропускная способность, а растущий разрыв между «in» и «out» по всему пайплайну — формирующийся бэклог. Длительность checkpoint (из REST-эндпоинта чекпоинтинга, а не из метрик по тасков) — медленная или растущая длительность checkpoint часто становится самым ранним сигналом проблемы, задолго до того, как заметно упадёт throughput.

Что технически доступно, но обычно шум

Метрики JVM heap и GC реальны и иногда действительно являются ответом, но это инструмент второго прохода — проверяйте их, когда busyTimeMsPerSecond или длительность checkpoint уже что-то сказали, а не как первый шаг. Начинать с них при каждом расследовании означает перебирать десятки счётчиков JVM, прежде чем добраться до тех двух-трёх, что обычно и объясняют происходящее.