Мониторинг задержки в приложении Flink

Question

Мне нужна помощь по мониторингу задержки (миг 1.8.0).

Допустим, у меня есть простой поток потоковых данных со следующими операторами: FlinkKafkaConsumer -> Карта -> печать.

Если я захочу измерить задержку обработки записей в моем потоке данных, что будет лучшей возможностью? Я хочу получить продолжительность обработки входных данных, полученных в источнике, до тех пор, пока они не будут получены операцией приемки / завершения приемника.

Я добавил свой код: env.getConfig (). SetLatencyTrackingInterval (100);

А затем доступны следующие метрики задержки:

Но я не понимаю, что именно они измеряют? Также, как мне кажется, средние значения задержки не связаны с задержкой.

Я также пытался использовать метрики codahale для получения длительности некоторых методов, но это не помогает мне получить задержку записи, обработанной во всем моем конвейере.

Связано ли решение с LatencyMarker? Если да, как я могу достать его в моей работе с приемником, чтобы получить его?

Спасибо, Roey.

Answer 1

- копирование моего ответа из списка рассылки для дальнейшего использования

Привет, Роуи,

с отслеживанием задержки вы получите распределение времени, которое потребовалось LatencyMarkers для перемещения от каждого оператора источника к каждому оператору ниже по течению (по умолчанию одна гистограмма на оператора источника в каждом операторе не источника, см. Metrics.latency.granularity) ,

LatencyMarkers периодически вводятся в источники и проходят через топологию. Они не могут обогнать обычные записи. LatencyMarkers проходят через функцию (код пользователя) без каких-либо задержек. Это означает, что задержки, измеренные отслеживанием задержек, будут отражать только часть сквозной задержки, особенно в сценариях без противодавления. В сценариях с обратным давлением маркеры задержки будут поставлены в очередь перед самым медленным оператором (поскольку они не могут перегнать записи), и задержка будет лучше отражать реальную задержку в конвейере. По моему мнению, маркеры задержки не являются подходящим инструментом для измерения «задержки на уровне пользователя / сквозного соединения» в приложении Flink. Для меня это инструмент отладки, позволяющий найти источники задержек или перегруженных каналов.

Я полагаю, что вместо использования отслеживания задержек вы сами добавляете метрику гистограммы в операторе приемника, которая отображает разницу между текущим временем обработки и временем события, чтобы получить распределение задержки времени события в источнике. Если вы сделаете то же самое в источнике (и в любых других точках интереса), вы получите хорошее представление о том, как изменяется временная задержка во времени.

Надеюсь, это поможет.

Приветствия,

Константин