Системный журнал для Кафки: самый эффективный рабочий процесс в NIFI? - PullRequest
Новая
       7

Системный журнал для Кафки: самый эффективный рабочий процесс в NIFI?

0 голосов
/ 18 января 2019

Я на самом деле работаю в большой компании во Франции, и мы стремимся принимать журналы системного журнала (формат rfc5424) всех наших серверов (почти 1400 серверов) в Кафке через NIFI. Мы выбираем NIFI, потому что хотим перенаправлять журналы на связанные темы в зависимости от найденного имени приложения.

Так что у нас будет много маленьких потоковых файлов.

На самом деле, мы сталкиваемся с ограничениями производительности: мы не можем принимать больше 5k мсг / с, и мы хотим принимать больше 50k мсг / с. Конечно, если возможно, мы хотим обрабатывать как можно больше.

У нас есть: listenSyslog (размер пакета 1 + синтаксический анализ включен) => RouteOnAttribute (поиск для получения целевой темы из appname) => PublishKafka.

Не могли бы вы дать мне несколько советов, пожалуйста?

Я думаю об этом рабочем процессе: ListenSyslog (пакетный размер 1000 + разбор отключен) => PartitionRecord (grokreader для получения имени приложения и преобразования в avro, группировка по имени приложения) => RouteRecord (со встроенным поиском, для маршрутизации пустого имени приложения или темы не найден) => PublishKafkaRecord (я понял, что он разбивает потоковый файл с несколькими записями на 1 сообщение на запись).

Спасибо за вашу помощь.

С новым годом всех!

Ответы [ 2 ]

0 голосов
/ 18 января 2019

Поток, который вы предложили в конце своих вопросов, находится на правильном пути, в основном вы хотите объединить множество сообщений в один файл потока.

В зависимости от того, какую версию NiFi вы используете, более новые версии имеют Syslog5424Reader:

https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-record-serialization-services-nar/1.8.0/org.apache.nifi.syslog.Syslog5424Reader/index.html

Это, вероятно, будет проще в использовании, чем GrokReader, щелкните ссылку дополнительной информации, чтобы увидеть схему, которую он создает.

Также есть ListenTCPRecord и ListenUDPRecord, с которыми вы могли бы поэкспериментировать вместо ListenSyslog. Таким образом, вы можете использовать ListenTCPRecord / ListenUDPRecord с Syslog5424Reader и AvroWriter, а затем продолжить предложенный поток. Вам нужно будет провести некоторое тестирование, чтобы увидеть, лучше ли просто использовать ListenSyslog или использовать варианты записи.

Другие вещи, которые необходимо учитывать при настройке ListenSyslog / ListenTCP / ListenUDP:

https://bryanbende.com/development/2016/05/09/optimizing-performance-of-apache-nifis-network-listening-processors

0 голосов
/ 18 января 2019

Для быстрого сравнения сравните ваши характеристики с этим справочным заданием:

https://docs.hortonworks.com/HDPDocuments/HDF3/HDF-3.1.1/bk_planning-your-deployment/content/ch_hardware-sizing.html

Если ваша емкость кажется достаточной на этом основании, я бы рекомендовал проанализировать проблему следующим образом и устранить вероятных подозреваемых один за другим:

  1. Сколько узлов NIFI глотает?
  2. Имеет ли значение добавление / уменьшение?
  3. Какой процессор является узким местом (загрузка или один из последующих шагов)?
  4. Может ли ваш источник / сеть стать узким местом?
...