Как читать сообщения, если никто из брокеров не предоставил удобный интерфейс17.03.2025 17:16

Уверен, вам не нужно рассказывать, как прочитать весточку от друга в Telegram, VK, WhatsApp и любом другом мессенджере, но что делать, когда речь заходит о брокерах сообщений?

Скажем, пишите вы себе EDA на основе Apache Kafka, и вы очень ответственный: ваши сервисы тщательно логируют все свои действия, процесс отлажен и работает годами. Вдруг один из сервисов отчитался в логах, что отправил событие в брокер, но другой по какой-то его не прочитал. Как понять, кто виноват?

Как правило, брокер сообщений между сервисами — черная коробка, которая работает, что называется «As Is». Разработчики ответственно подключают зависимости того же Apache, вешают аннотации консюмеров и продюсеров, оно заводится и все рады. Но тестировщикам, например, часто приходится доверять логам сервисов, а это не их естество.

Так давайте же посмотрим, как мы можем открыть этот чёрный ящик на примере наиболее популярных брокеров сообщений.

Apache Kafka

Брокер от Apache я привёл в пример не просто так. Дело в том, что ASF не представили в месте с решением никакого интерфейса для чтения и отправки сообщений, кроме как CLI. Об этом вам, кстати, расскажут сразу же в инструкции по установке и первичному запуску брокера.

Читаем сообщения стандартными средствами Apache Kafka

Например, чтобы считать сообщения из брокерам, нам потребуется утилита kafka-console-consumer.sh (-bat). Для запуска консольного консюмера необходимо провалиться терминалом в папку bin из корня пакета установленной Kafka и выполнить команду примерно следующего вида:

kafka-console-consumer.bat --bootstrap-server localhost:9092 --topic my-topic

Этой командой вы подпишитесь на обновление топика my-topic и будете получать новые сообщения. Если вы передадите дополнительно параметр --from-beginning, то ещё и получите всю историю сообщений. Выглядеть консоль у вас будет примерно так:

В рамках знакомства с брокером, конечно, такой информации может и хватить, но для больших проектов нужно намного больше. Важно знать оффсет, партицию, видеть заголовки и ключ сообщения. У консольного консюмера есть множество параметров, их можно прочитать, воспользовавшись --help. А у меня получилась вот такая команда:

kafka-console-consumer.bat --bootstrap-server localhost:9092 --topic demo-topic --from-beginning --property print.key=true --property print.value=true --property print.timestamp=true --property print.headers=true --property print.offset=true

И вывод, соответственно:

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

Отправляем сообщения в CLI Apache Kafka

А как отправлять сообщения? Скажем, я хочу нагрузить свой сервис, наплодить множество ивентов и посмотреть, как поведёт себя система. Конечно, я могу это сделать через сервис-поставщик, но тогда тест будет не чистым: мы будем ждать обработки поставщика и тратить транспортные расходы на межсервисное общение и наше — клиентское.

Для отправки сообщений нужно составить команду примерно следующего вида:

kafka-console-producer.bat --bootstrap-server kafka-dev-javax.ru-central1.internal:9092 --topic demo-topic --property parse.key=true --property key.separator=: --property parse.headers=true --property headers.delimiter=\t

Тут я сразу указал параметры: parse.key, key.separator, parse.headers и headers.delimiter, чтобы мы могли отправлять наиболее полноценные сообщения, как это делал бы за нас сервис. Консоль отобразит вам > и предложит построчно вводить каждое новое сообщение. Например, так:

Сообщение, конечно, отправлено, но что, если мы хотим сделать это несколько раз? А если тысячу? У консольного продюсера есть возможность передать сообщения из txt-файла. Тогда каждая новая строчка в файле будет восприниматься как новое сообщение, но в таком случае нам нужно будет уже готовить файл.

А если у вас Kafka с SSL, ACL, SASL и ещё множеством обёрток безопасности? Вам придётся каждый раз при подключении к брокеру указывать эти параметры в команде, расширяя её до невероятных значений.

Разумеется, никто в крупных проектах с этими CLI не работает, и многие из читателей вообще впервые могут услышать, что у Apache такое есть. Очевиден вопрос того, что для чтения-отправки сообщений нужен какой-то мало-мальски дружелюбный интерфейс. И такие решения есть. Существует три основных: OffsetExplorer, Сondutor и Kafka UI.

Offset Explorer

Утилита решает описанные проблемы, позволяет достаточно удобно читать и отправлять сообщения, облегчает работу с соединением, конфигурацией и прочим.

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

Читаем сообщения в Offset Explorer

Чтобы увидеть сообщения нам нужно найти целевой топик в списке и, если вы, конечно, не воспринимаете байты на глаз, изменить стандартное отображение содержимого сообщений с ByteArray на String.

Когда настройка завершена, переходим в одну из партиций (или все зразу, нажав на partitions) и вычитываем её содержимое:

Уже лучше, тут сразу видим офсет, полное содержимое с заголовками и метаданными вроде времени отправки, размером на диске и CORELATION_ID в заголовках.

Отправляем сообщения в Offset Explorer

Тут же можем и отправить сообщение, кликнув на зелёный плюс.

В OE можно отправить как одно сообщение, так и несколько или же вовсе загрузить из файла.

Обзор

Кажется, что проблема решена и вопрос можно закрывать. Действительно, если брокер у вас не пользуется популярностью, над ним работает маленькая команда или он отвечает за незначительные задачи, которые редко обновляются, то этой тулзой можно ограничиться в качестве бесплатного варианта и очевидно лучшей альтернативе kafka-console-consumer.

Но если вопрос стоит в комфорте, автоматизации и регулярной работе с брокером, то OE не лучший вариант.

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

Отправка сообщений остаётся низкоуровневой, пользователь должен следить за разделителями key и value, их порядком, отображением, кодировкой и прочим. Множественная отправка предполагает банальное дублирование информации по аналогии с > в kafka-console-producer.

Кроме того, визуал утилиты лампово, но не очень практично, отсылает к Windows XP. Нужно идти дальше и искать, что есть лучше.

Conductor

Коммерческий инструмент, распространяемый одноимённой стартап-компанией с англо-американскими корнями, для чтения сообщений, который обладает крайне широким функционалом, в сравнении с вышеупомянутым OE. Тут и Schema Registry и AVRO или Protobuf поддержка, Kafka Connect, KSQL DB и прочее. Казалось бы сказка, но это всё недоступно, пока вы в индивидуальном порядке не купите лицензию, забронировав себе демо-сессию с менеджерами Conductor. У приложения нет странички для оплаты, нет реквизитов для перевода, оно не открыто для рынка физлиц и распространяется только корпоративными пакетами для сотрудников юрлиц.

Об этом предлагаю позже, потому как основной функционал — чтение и отправка сообщений в десктопной версии всё же доступен. Кстати, от десктопной версии сейчас почему-то активно отказываются и пересаживают на подход с поставкой докер-образов. Вероятнее всего, так легче лицензировать продукт, но из-за этого десктопная версия перестала получать обновления.

Читаем сообщения в Conductor

Итак, прочитать сообщения в бесплатном «кондукторе» всё же можно. Для этого подключаем брокера по аналогии с OE, и перед нами предстаёт такой интерфейс:

Симпатично, но сразу видим, что лицензия ограничила нас в работе только с первыми 10 топиками из списка, в число которых не попал наш demo-topic, но это не беда, нас так просто не остановить, поэтому посмотрим функционал на другом.  

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

Чтение сообщений представляет из себя создание и настройка консюмера по аналогии с kafka-console-consumer, но с визуалом. Можно достаточно тонко настроить потребителя от банальных конфигураций, какую партицию (-и) читать, до максимального размера потребляемых сообщений.

После настройки потребителя можно приступить к чтению сообщений:

В этом же окне можно удобно выгрузить сообщения в JSON или CVS, отфильтровать их, скопировать в буфер обмена каждое отдельное и так далее.

Отправляем сообщения в Conductor

По аналогии с чтением сообщений мы можем и отправить новые. Для этого, соответственно, необходимо создать продюсера, настроить содержимое сообщения, тип его сжатия, ACS, выбрать партицию к отправке. Удобно, что продюсера можно сохранить, чтобы не настраивать его каждый раз.

Кроме того, в кондукторе впервые появляется возможность множественной отправки и шаблонизации сообщений. Шаблоны позволят не заполнять каждый раз сообщение, а множественная отправка лишит необходимости ручного клика по кнопке «Отправить». В настройках достаточно указать кол-во итераций отправки и запустить процесс:

Во вкладке Data настраиваем содержимое шаблона сообщения, в остальных — параметры его отправки: Заголовки, колличество, прочие опции для продюсера.

При множественной отправке можно указать только кол-во повторений — содержимое сообщений не будет отличаться друг-от-друга.

Обзор

Резюмируя, Conductor очень богат функционалом, но из-за строгости и дороговизны лицензий ваш пользовательский опыт, скорее всего, сведётся к тому же функционалу, что есть в OE, но с более приятной картинкой.

Говоря о дорогих лицензиях на Conductor, я имею ввиду действительно дорогих. Поставить это ПО для команды разработки на какой-либо коммерческий проект может обойтись вам в миллионы рублей. Не говоря уже, о проблемах с оплатой на зарубежный счёт в наших реалиях.

Kafka UI

Это решение с открытым исходным кодом от украинской организации Provectus со штаб-квартирой в Одессе, которая сейчас нацелена на развитие ИИ.

Достаточно популярный продукт поставляется в качестве докер-образа, который предполагается разворачивать в контуре проекта и настраивать через ENV. Также при определённой настройке приложения он даст возможность конфигурировать брокеров в рантайме. При старте java-приложение kafka-ui подключится ко всем брокерам из настроек, и любой пользователь сможет с ними работать. Можно навесить авторизацию через LDAP или Keycloak, раздать роли и прочее.

В общем, продукт рассчитан скорее на команды разработки, есть ролевая модель, подразумевается разворачивание в облаке, но образ можно развернуть и локально.

Разворачиваем приложение

Итак, наша цель — прочитать сообщения. Для этого нам нужно получить докер образ и развернуть его в своём контейнере. Разумеется, если вы не умеете работать с докером, то вам будет сложнее. Получить образ можно двумя способами: собрать командой из корня форкнутого репозитория или взять готовый, как сделал я.

Образ достаточно спулить и запустить командой запуска:

docker run -it -p 8080:8080 -e DYNAMIC_CONFIG_ENABLED=true provectuslabs/kafka-ui

Именно DYNAMIC_CONFIG_ENABLED=true позволяет конфигурировать брокеров не через переменные окружения, а полями интерфейса.

После запуска на указанном порту станет доступен WEB-интерфейс приложения с возможностью добавить брокер к подключению.

Так как ПО бесплатное, у него нет никаких функциональных ограничений и, в отличии от Conductor, заявленные KSQL, Kafka Connect, Schema Registry фактически доступны.

Работаем с сообщениями в Kafka UI

Повторяем наш пользовательский сценарий и пытаемся прочитать и отправить сообщения. Для этого проваливаемся в список топиков брокера и выбираем интересующий нас demo-topic.

Проваливаемся в него и сразу же можем видеть его сообщения по стандартным фильтрам поиска:

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

Тут же в углу можно и отправить сообщение, кликнув на кнопку «Produce Message»:

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

Обзор

В отличии от Conductor, в UI For Apache Kafka не поддерживаются шаблоны и множественная отправка, поэтому провести нагрузочное тестирование этим инструментом не удастся.

Последний коммит в репозитории проекта был сделан в апреле 2024, в нём просто подняли версию одной из зависимостей, тогда же собрали последний релиз. Кроме этого за вот уже 10 месяцев не было ни одного коммита, обновление функционала приложения явно замедлилось, в сравнении с 2023 годом. Вероятнее всего, это связано с уходом компании в сферу ИИ.

Кроме Kafka UI, Offset Explorer и Conductor есть ещё ряд решений для чтения сообщений, но все они так или иначе топчутся на одном месте, дублируя минимальный функционал, представленный OE, но в более или менее приятной визуальной обёртке.

Кажется, с чтением сообщений в Kafka понятно, выбирайте из подходящего. Но что делать, если у вас на проекте не один брокер сообщений? У Artemis, ActiveMQ и RabbitMQ есть свои собственные сомнительные, но рабочие коробочные UI для сообщений, но что с остальными?

Если у вас, например, Redis как распределённый кэш, Kafka как современный способ общения между новыми сервисами, а, скажем, Nats или Tarantool — устоявшееся решения на вашем проекте. Придётся под каждую отдельную задачу открывать очередной UI, лезть в консоль, доставать креды для подключения и так далее.

Но вы можете столкнуться и с тем, что у Nats, например, нет ни одного UI-интерфейса, кроме как двух пет-проектов на GitHub. Никакой поддержки, никаких фич.

BrOk

Нам показалась очевидным, что нужен продукт, покрывающий функциональные требования большинства разработчиков и тестировщиков при работе с брокерами сообщений. Поэтому несколько лет назад мы принялись разрабатывать собственный интерфейс для работы с брокерами сообщений.

Идея перед BrOk стояла следующая: поддержать весь функционал, заявленный у аналогов и развить пользовательский опыт в собственном приложении. Например, мы не просто поддержали создание шаблонов и множественную, как в Conductor, но и прикрутили к ним переменные параметры, чтобы при множественной отправке каждое ваше сообщение было уникальными: со своим UUID, датой, типом, описанием и так далее.

Например, заполнить топик сообщениями с тестовыми данными пользователей. Чтобы не использовать настоящие конфиденциальные данные, сгенерируем содержимое по Regexp-шаблону или значениями из словарей.

Устанавливаем BrOk

Предлагаю идти по порядку и повторить наш запрос — прочитать и отправить сообщение. Приложение распространяется как в WEB-версии в формате Docker-образа, так и в качестве десктопного. На данный момент доступно приложение для Windows, на котором я и буду показывать функционал. Также доступна Linux-версия, в ближайшее время поддержим и MacOS.

При запуске видим рабочий стол с избранными очередями/топиками  и шаблонами сообщений для быстрого доступа. Также на рабочем столе для быстрого доступа выведены сценарии, но о них чуть позже.

Читаем сообщения в BrOk

Для того, чтобы отправить сообщение нам нужно или вызвать окно отправки прямо с рабочего стола или перейти в список топиков. Переходим в список брокеров, выбираем нужный и в списке топиков находим наш. Тут же можем добавить его в избранное, что, кстати, будет влиять на сортировку — избранные топики всегда будут первыми в списке.

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

Отправить сообщение можно тут же по кнопке в правом верхнем углу:

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

Шаблоны сообщений

Но, если говорить об отправке сообщений, то все случаи, которые мы ранее рассматривали достаточно примитивные. Сервисы, как правило, не отправляют одинаковых сообщений. Чтобы протестировать сервис сообщениям из BrOk, они должны быть похожи на настоящие.

Ранее я говорил, что мы добавили параметры в сообщения, покажу как это работает.

Я завёл шаблон пользователя со стандартным набором полей. Кроме пользовательских параметров, внёс и некоторые системные, которые могут добавлять сервисы или же сама Kafka.

Всё, что выделено {{}} — параметры. Вместо них приложение при отправке подставит значение, указанное в настройках параметра. Они обширные и мы стараемся добавлять новые, чтобы удволитворить растущий спрос.

В настройках параметров можно указать один из 10 типов и задать правила, по которым BrOk подставит значения в финальное сообщение. Так, тут мы указали:

• Что нужно выбрать одно из перечисленных имён (параметр name-dictionary), фамилий (surname-dictionary), ролей (role-dictionary), статусов (status-dictionary) и типов сообщений (message-type-dictionary)

• Для баланса пользователя (параметр random-numeric) указали точность и масштаб числа.»4;2» в данном случае означает 4 символа до запятой и 2 после.

• Создать случайный UUID (параметр random-uuid)

Кроме перечисленных, есть типы по генерации случайных строк заданной длины, случайных строк по заданному regex, случайных дат и времени по заданному формату.

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

По сути говоря, мы с вами сейчас за три слайда заполнили топик условно-реальными данными для тестирования систем. Красота!

Другие брокеры сообщений

Как говорится, аппетит у нас появился в процессе еды, поэтому кроме Apache Kafka мы добавили поддержку ActiveMQ, Artemis, RabbitMQ, Redis, NATS, ETCD и на данный момент работаем над поддержкой Tarantool.

Во всех брокерах, аналогично Kafka, реализованы избранные, шаблоны, множественная отправка и так далее — всё стандартизировано.

К примеру, создам схожий шаблон в RabbitMQ. Разумеется, форма отправки, хоть и интуитивно похожа, но отвечает специфике конкретного брокера. Тут появляются уникальные для RabbitMQ режим доставки (routing type) и подход к кодировки отличный от Kafka.

Отправляем это сообщение и смотрим содержимое очереди:

Повторюсь, мы придерживаемся стандартизации, но учитываем особенности конкретного брокера, поэтому форма сообщений отличается от Kafka, вместе с тем, мы также легко заполнили топик условно-живыми данными для тестирования.

Сценарии

Как только мы получили столь серьёзный инструмент, мы поняли, что работу с брокерами можно автоматизировать.

Так появились сценарии — LowCode-дизайнер для создания воркфлоу какого-то процесса, где можно отправить или считать сообщения брокера, выполнить SQL запрос, отправить HTTP-запрос или выполнить Groovy-скрипт.

Сценарии могут быть как маленькими и утелитарными для форматирования/перегона данных или, например, отправки уведомления, так и масштабные для одобрения или отклонения заявок пользователей, сложного и глубокого тестирования и так далее.

REST

Для сценариев мы реализовали интерфейс работы с HTTP-запросами. Во вкладке REST можно создавать запросы и группировать их по коллекциям. Запросы также как и шаблоны поддерживают параметры.

После того, как мы завели себе запрос, мы можем его использовать в сценариях. Для этого создадим соответствующую задачу, выберем коллекцию и запрос.

Тут же можно и отредактировать запрос, если, например, вам нужно, чтобы часть запроса заполнялась переменными сценария. Сохранённый таким образом запрос получит статус внутреннего, сценарного и не будет влиять на оригинальный.

Тут, например, в теле запроса логин будет подставляться из значения переменной user_login, остальные данные будут заполнены автоматически через параметры как при обычной отправке.

Также есть возможность сохранить ответ запроса в качестве переменных и использовать их в других задачах сценария. Для этого требуется указать связи. Например, из ответа на запрос о получении пользователя,  мы можем сохранить любое поле, к примеру, его логин или id.

Если мы знаем, что ответ запроса выглядит, например, так:

{
  "uuid": "fj739194-8qk8-145r-76d8-0s75d6798s01",
  "name": "Игорь",
  "surname": "Степанов",
  "role": "Тестировщик",
  "balance": "1207.42",
  "status": "ONLINE"
}

Тогда для сохранения пользовательского uuid в переменную user_uuid правило поиска будет выглядеть так:

Мы также можем задать некоторое условие. Например, присваивать значение переменной user_uuid только в том случае, если должность пользователя «Тестировщик». Такое правило будет выглядеть так:

{
  "uuid": "%{user_uuid}",
  "role": "Тестировщик"
}

SQL

Кроме того, для покрытия большей части пользовательских задач, которые могут возлагаться на сценарии, мы добавили возможность работы с СУБД. Для этого на вкладке сценариев необходимо завести JDBC-подключение.

В сценарии затем можем добавить соответствующую задачу, выбрать ей подключение и написать SQL-запрос. Задача отправит его, учитывай контекст сценария.

Например, тут перед отправкой запроса BrOk вставит в него значение переменной user_balance, которую мы могли получить в задачах, завершённых ранее по сценарию.

Пример

Чтобы было нагляднее, я создал небольшой сценарий, который мы, например, использовали для тестирования функционала отправки уведомлений.

Этот сценарий отправляет череду уведомлений с помощью HTTP. Опишу алгоритм действий, который будет выполнен, если запустить такой сценарий:

1. Сперва в задаче SQL мы добавляем в специальную таблицу статические значения тестовых пользователей. 

2. Сервис отреагирует на появление пользователей и отправит в Kafka часть пользовательских данных. Их считает  слушатель и запишет его данные в качестве переменных сценария

3. Параллельный шлюз запустит задачу отправки сообщений события в другой топик Kafka, а слушатель его считает и запишет данные о событии в переменные сценария

4. В случае, если слушатель упадёт с ошибкой ожидания, т.е. по какой-то причине не дождётся сообщения о событии из топика demo-topic, мы отправим уведомление по HTTP и затем SQL-запросом очистим базу от тестовых пользователей

5. Если сообщение всё же дошло, то мы на одной ветке в Groovy-скрипте генерируем случайное число и отправляем в уведомлении в качестве нового ID. В другой ветке ждём отчёта от сервиса уведомлений, что он корректно выполнил запрос, залогировав всё в Artemis.

6. Если дожидаемся логов, то через SQL добавляем в таблицу тестов очередной успешный, если нет — очищаем данные о тестовых пользователях.

Прочее

Много и уникальных фич, например, мы добавили взаимодействие между пользователями в WEB-версии приложения. Так, пользователи могут делиться сообщениями из брокера внутри BrOk через уведомления или ссылку. Кроме сообщений, можно делиться шаблонам, сценариями, запросами со вкладки REST и так далее. У пользователей есть профиль, аватар и описание.

Овервью

Несмотря на то, что на рынке существует множество как коммерческих, так и некоммерческих решений, глазу негде разбежаться. У одного продукта условно-бесплатный доступ, но крайне ограниченный функционал, как у OffsetExplorer, у другого широкий и богатый функционал, но за это требуют большие деньги, как в Сonductor, третий вроде и бесплатный и с функционалом, но он не поддерживается и его сложно установить для личного пользования. Кроме того, большая часть продуктов сосредоточена на работе с конкретной технологией и их нельзя назвать универсальными решениями.

BrOk представляет широкий функционал для работы с множеством брокеров сообщений, поддерживает большую часть функционала аналогов, обладает и своим собственным, уникальным функционалом. Что важно, у нас бэклог расписан на полтора года вперёд и мы активно его поддерживаем.

Наш продукт распространяется совершенно бесплатно для некоммерческого использования без каких-либо скрытых реклам, условий и подводных камней. Скачать и попробовать вы его можете на нашем сайте, будем рады отзывам.

До встречи!