Непостоянные значения задержки раздела при использовании потребителя высокого уровня для чтения журналов Kafka

Все наши 30 тем созданы с 10 разделами в нашей кафке. Мы отслеживаем отставание по разделам для всех идентификаторов тем / групп.

Мы используем плагин Fluentd для чтения и маршрутизации журналов из kafka. Плагин реализован с использованием потребителя высокого уровня. Мы настроили некоторых потребителей для отдельных тем, а некоторых - для нескольких тем для плагина. В целом, данные проходят без проблем, за исключением трех тем.

Проблема в том, что для 3 из 30 обрабатываемых тем мы видим, что значения запаздывания раздела несовместимы, т.е. если посмотреть на значения задержки для определенной темы / идентификатора группы, то задержка для некоторых разделов намного выше, чем для других разделов, иногда на целых 30 КБ. Однако для остальных 27 тем числа лагов для всех разделов остаются одинаковыми, все разделы одной темы / идентификатора группы остаются в пределах близкого расстояния друг от друга (например, все между 12 и 18).

Почти каждый раз, когда мы перезапускаем агент Fluentd (который перезапускает высокоуровневых потребителей), мы видим, что лаг начинает сглаживаться для этих трех тем, и иногда они остаются постоянными в течение некоторого времени, а затем снова цифры лага начинают становиться зигзагообразными. Это происходит только для трех тем. Но когда мы проверяем распределение по этим трем темам, все выглядит нормально.

Мы не понимаем, в чем причина этого. Потребители высокого уровня не используют код для управления извлечением данных из разделов. Это библиотека kafka, которая обрабатывает эту часть. Все, что указывает потребительский код, - это количество потоков. Мы пробовали 10, 5 и во всех случаях (особенно 10 и 5 потоков) несоответствие задержек продолжает проявляться для этих 3 тем. Объем данных не превышает 30 КБ в час по каждой из этих тем.

Любые предложения относительно того, в чем может быть причина? Что с этим можно сделать?

Заранее благодарю за вашу помощь.


person FZF    schedule 13.02.2016    source источник


Ответы (1)


Основываясь на предоставленных деталях, я бы начал с рассмотрения пунктов ниже, я думаю, что вы бы уже рассмотрели их.

  1. Сравните тенденцию создания сообщений по трем темам по сравнению с остальными темами. Также проверьте размеры сообщений, публикуемых в этих темах, по сравнению с другими темами.
  2. Просто переместите 3 проблемные темы в другой экземпляр fluentd, чтобы проверить поведение лагов.

Пожалуйста, дайте мне знать, если вы найдете что-то еще или решите проблему с помощью некоторых тонких настроек

person Mehul    schedule 14.02.2016
comment
Спасибо за ваш ответ. Да, это сделал я. Ничего особенного в потоке этих тем или размере сообщения. У нас есть и другие темы с меньшим и большим потоком. Размеры сообщений вроде небольшие. Я запустил еще один fluentd-сервер только с этими тремя темами и такими же несистематическими / зигзагообразными значениями лага. Я протестировал 6 других тем на новых серверах, и, как и на исходном сервере, все вело себя так, как ожидалось: согласованные / плавные значения задержки для всех разделов. Я предполагаю, что эти 3 темы имеют какое-то отношение к Kafka. Но не могу угадать, что это может быть. - person FZF; 15.02.2016
comment
Забыл упомянуть, что те же 3 темы обрабатываются другим потребителем высокого уровня с использованием 1 потока, и все задержки плавные. - person FZF; 15.02.2016
comment
Понятно. Есть ли что-то другое, например, по количеству разделов или репликации по этим трем темам? Есть ли какой-либо конкретный процесс, который выполняется после того, как fluentd использует сообщение (имеется в виду любое обновление базы данных или любое другое) для трех тем по сравнению с другими? Как работает сборка мусора на fluentd? Выглядит нормально? - person Mehul; 15.02.2016
comment
Все темы реализованы одинаково, поэтому нет ничего особенного в их разделении. Сборка мусора - это то, на что мы еще не обращали внимания. Тем не менее, по-прежнему трудно думать, что какая-то проблема в fluentd влияет только на эти 3 темы, а не на другие 27 тем. Когда мы запускаем эти 3 с 1 потоком с помощью fluentd, а также от другого потребителя HL, мы не видим никаких зигзагообразных проблем с числами запаздывания для этих 3 тем. Таким образом, кажется, что использование только более чем 1 потока и только для этих 3 тем создает значения зигзагообразного запаздывания. - person FZF; 16.02.2016
comment
Понял вашу точку зрения. Не могли бы вы поделиться картиной лагов? - person Mehul; 16.02.2016
comment
есть 10 разделов, и в одном случае для одной из тем, например, задержки разделов были: раздел 0: 15,1: 15,2: 16, 3: 1355, 4:17, 5:14, 6:15, 7:13, 8: 1368, 9:14. Нет никакой закономерности в том, как лаги проявляются для одной темы в тестах diff или между темами в какой-то момент. Это повсюду и очень радужно. - person FZF; 16.02.2016