Como ler uma exportação de métricas do Flink, e quais números realmente importam?

O Flink expõe métricas por uma API REST (ou JMX, ou um reporter à sua escolha) como JSON plano: uma entrada por nome de métrica por tarefa/operador/job, sem priorização embutida do que importa.

A forma de uma exportação de métricas

Uma consulta a /jobs/<id>/vertices/<vertex-id>/metrics retorna um array de objetos {"id": "...", "value": "..."} - plano, sem aninhamento, sem indicação de quais vale a pena olhar primeiro. Isso fica por sua conta saber de antemão, já que a própria API trata um contador de pausa de GC e seu contador real de throughput como igualmente importantes.

O punhado que importa numa primeira passada

busyTimeMsPerSecond - quanto de cada segundo uma tarefa realmente passou trabalhando, o mais próximo que o Flink tem de uma métrica de utilização. numRecordsInPerSecond / numRecordsOutPerSecond - throughput real, e um gap crescente entre «in» e «out» ao longo do pipeline é um backlog se formando. Duração do checkpoint (do endpoint REST de checkpointing, não das métricas por tarefa) - uma duração de checkpoint lenta ou crescente costuma ser o sinal de alerta mais precoce de um problema, bem antes do throughput cair visivelmente.

O que está tecnicamente disponível mas geralmente é ruído

Métricas de heap da JVM e GC são reais e às vezes são de fato a resposta, mas são uma ferramenta de segunda passada - confira quando busyTimeMsPerSecond ou a duração do checkpoint já tiverem dito algo, não como primeiro passo. Começar por aí em toda investigação significa vasculhar dezenas de contadores de JVM antes de chegar aos dois ou três que costumam explicar o que está acontecendo.