Kafka для самых маленьких тестировщиков

Всем привет! Меня зовут Максим, я QA в Максилекте.

Недавно коллеги попросили меня рассказать о базовых вещах в Kafka, которые могут быть полезны при тестировании общающихся между собой микросервисов или сервисов, взаимодействующих со сторонними ресурсами. В этой статье — основные идеи моего рассказа.

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

Дисклаймер:

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

Если нужна базовая информация о Kafka с точки зрения разработчика — смотрите одну из наших предыдущих статей.

Инструменты работы с Kafka

Базовый инструмент — command line interface (CLI), который входит в поставку Kafka и скачивается с официального сайта (https://kafka.apache.org/downloads). По сути это набор shell-скриптов, из которых чаще всего используются продюсер, консьюмер и просмотр топиков.

Сейчас распространены UI обертки для этих скриптов с разными функциями. В некоторых смыслах с ними удобнее взаимодействовать, но все зависит от подхода к развертыванию Kafka на конкретном проекте. Иногда тестировщик не может повлиять на то, будет ли поднят какой-либо UI (и какой именно). Например, на моем проекте сейчас развернут один из самых простых инструментов — возможностей у него намного меньше, чем у скриптов. А бывают проекты, где из-за жестких требований к сохранению консистентности данных тестировщики вообще не имеют доступа к продюсерам или консьюмерам. Отчасти это правильно — поместим мы туда, допустим, некорректное сообщение “грязными руками”, а какой-то другой сервис его прочитает. В итоге вся команда будет искать проблемы в других сервисах. Так что многофункциональный UI для Kafka зачастую и не нужен.

Также есть большое количество плагинов для IDE. Говорят, удобен официальный плагин от JetBrains для Intellij IDEA, но лично я им не пользовался. Кажется, он доступен только в Ultimate-версии IDEA.

Основные сценарии обращения к Kafka в тестировании

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

Ниже мы рассмотрим основные сценарии работы с Kafka при тестировании.

Просмотр списка топиков

Название кейса говорит само за себя. Этот кейс полезен при анализе проблем — если в тестируемом решении мы не получаем никаких сообщений из Kafka. В этом случае стоит проверить, а созданы ли вообще в кластере топики? Корректно ли они названы? Да и в целом полезно понимать структуру кластера.

Для просмотра списка топиков можно использовать shell-скрипт. Например, вот так можно посмотреть список топиков на локальном инстансе Kafka:

./kafka-topics.sh --list --bootstrap-server localhost:9092

Аргументов у этого скрипта может быть много, но базовые — это —list и сервер, к которому мы подключаемся.

Помещение сообщения в топик

Для целей тестирования в топик иногда нужно помещать сообщения. Допустим, у нас на проекте уже есть консьюмер, но еще не имплементирован или корректно не работает продюсер (либо он по каким-то причинам недоступен).

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

./kafka-console-prosucer.sh --topic quickstart-events --bootstrap-server localhost:9092

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

Чтение сообщений из топиков

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

В этом случае нам потребуется такой скрипт: 

./kafka-console-consumer.sh --topic quickstart-events --from-beginning --bootstrap-server localhost:9092

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

Прежде чем приступить к выполнению команды, рекомендую уточнить у разработчиков, как правильно читать конкретно ваши топики, имплементированные в Kafka. Так меньше шансов затронуть работу приложения.

Просмотр списка консьюмеров

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

./kafka-consumer-groups.sh --list --bootstrap-server localhost:9092

Для расширения выводимой информации можно применять дополнительные аргументы —all-groups или —describe.

Сброс офсета

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

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

Другая ситуация — если кто-то уже вычитывал сообщения из топика, но что-то пошло не так (допустим, кто-то случайно удалил таблицу и нужно ее заполнить заново). В этом случае нам тоже нужно сбросить офсет, но перескочить к самым ранним сообщениям  с помощью атрибута —to-earliest и повторно их обработать.

kafka-consumer-groups --bootstrap-server localhost:9092 --group test --topic ИмяТопика --reset-offsets --to-earliest (--to-latest)

Конечно, здесь упомянуты не все кейсы использования Kafka в тестировании, а лишь самые распространенные. Если вы считаете, что сюда стоит добавить еще какие-то кейсы, пишите в комментариях.

Автор: Максим Лукиных, Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на нашу страницу в VK или на Telegram-канал, чтобы узнавать обо всех публикациях и других новостях компании Maxilect.