Comments 8
Было бы интересно узнать, как вы мониторите производительность брокеров Kafka в проде.
При нагрузке на уровне продакшна (сотни топиков и трафик более 5 Мбит/с) используем Prometheus с поддержкой Hosted Graphite и MetricFire. Это позволяет обрабатывать большие объемы данных (до 1 ТБ метрик в месяц). Реализуем экспорт метрик из Kafka в Prometheus с помощью JMX (Java Management Extensions). Отслеживаем использование CPU, памяти, дискового пространства, сетевой трафик, отставание консьюмеров (consumer lag), задержку обработки (latency) и количество сообщений в секунду.
Настраиваем алерты, чтобы быстро реагировать на превышение пороговых значений, например, рост consumer lag. Отслеживаем через интерфейс Hosted Graphite. При дальнейшем масштабировании распределяем нагрузку между несколькими экземплярами Prometheus с использованием federation, а метрики храним с помощью Thanos или Cortex.
А насколько корректно в смысле системного дизайна в шине передачи данных фильтровать и менять данные?
Глобально изменять и фильтровать данные в инфраструктуре Kafka нежелательно, так как она создана для передачи данных без их модификации — «как есть». То есть она должна доставлять сообщения от продюсеров к консьюмерам без вмешательства в их содержимое. Если изменять данные на уровне брокера, это может увеличить нагрузку на систему.
Легкие изменения вроде добавления временных меток через transformations вполне допустимы, так как их влияние на производительность минимально.
Сложные же задачи лучше выполнять на стороне консьюмеров, с помощью Apache Flink или Kafka Streams. Тогда обработка данных будет в отдельном слое, а Kafka сможет сосредоточиться на доставке сообщений.
На практике мы чаще реализуем отдельный сервис обработки на Apache Flink. Но это если пиковая нагрузка может доходить до 10 000 сообщений в секунду. Для средних нагрузок (до 2 000 сообщений в секунду) достаточно Kafka Sreams.
User topic - а что будет с пользователями которые заказывали 1 год назад? Или нужно отдельным процессом пушить старого user в топик ?
В Kafka данные в топиках хранятся в соответствии с политикой retention, которая по умолчанию составляет 7 дней. Если не увеличить retention, то данные о пользователях, заказывавших год назад, будут удалены из топика. И да, в таком случае потребуется отдельный процесс для загрузки этих данных обратно, например, из базы данных, с последующей отправкой в Kafka.
Для долгосрочного хранения лучше использовать data lake (например, локально развернутый MinIO), и загружать данные в Kafka по мере необходимости, чтобы не перегружать кластер. Это если данные о заказах за год нужны редко (для отчетов, например).
Если же часто, то можно избежать их удаления, скорректировав политику хранения (например, увеличить срок хранения до года), но это потребует дополнительного пространства для хранения данных.
А чем принципиально отличается kafka streams от kafka producer / consumer?
Kafka Producer — это клиент, который отправляет данные в топики Kafka. Kafka Consumer получает данные из топиков для их обработки. Оба действуют как базовые инструменты для взаимодействия с Kafka, но сами данные они не модифицируют. Этим занимается библиотека Kafka Streams. Она обрабатывает потоки данных в реальном времени внутри Kafka и позволяет не только читать и писать данные (как Producer/Consumer), но и выполнять трансформации данных, такие как фильтрация, агрегация или соединение потоков в реальном времени.
Потоковая обработка данных с Kafka Streams: что это и как использовать