Тут возникла странная ситуация с кафкой... Уже кучу метрик вывел

на графики - видно проблемы, но корневую причину не могу найти.
История такая - всё работает прекрасно, продюсеры пишут, консьюмеры читают, трафик как обычно (нет какого-то резкого скачка), кол-во коннектов на брокерах где-то по 300 шт.
Внезапно брокер 1 исключает брокера 3 из in-sync реплик по большому кол-ву партиций топиков.
Через минут 10 брокер исключает брокера 1 из in-sync реплик по большому кол-ву партиций топиков и в это же время брокер 1 исключает брокеров 2, 3 из in-sync реплик по большому кол-ву партиций топиков (остается один)

Со стороны приложений начинается тупняк, кажется на методе commit offset у консьюмеров. Продюсеры работают без проблем.
ошибки и таймауты commit offset видно на графиках.
Брокеры в одном L2 сегменте на виртуалках. CPU, RAM, DISK-I/O, network на околонулевых отметках - запас как минимум кратный.
В это же время чуть больше становится на сетевом стеке ретрансмитов (грубо с 0-10 до 30-50 с пиками до 150).
Тестирую сеть между хостами - потерь нет. Т.е. ретрансмиты судя по всему из-за тупняка внутри брокеров (переполнены сетевые буферы???).
Перезапуск приложений с косьюмерами позволяет немного разгрести очередь и потом опять возникает проблема. Потом проблема уходит спустя пару часов, пока искали корневую причину.

Что это может быть в кафке и как бы это на график вывести?

Не являюсь сетевым админом, но проверьте так же связь с хостами зукипера. Не глючит ли кластер зукипера? Видят ли хосты друг друга и кафку? Так же я ловил кейс, когда провайдер геореплецировал массово данные и диски/сеть жёстко тупили. Узнавали мы про это косвенно. Так же мы ловили похожее поведение на старых версиях кафки при большом количестве партиций в кластере. Там крутили таймауты(возможно крутили tcp, уже не помню), помогало. А ну и ещё читайте логи, там обычно если что-то с кафкой, то информация есть. Те же самые ретраи самой Кафки между брокерами там видны.

зукиперы на тех же хостах - по здоровью у них всё тоже ровно. Кол-во записей росло в моменты проблем, т.к. лидеры менялись. Про DRS то я не подумал. Надо глянуть, но это бы было видно на графиках ОС (а там всё ровно.) кафка в этой инсталляции не такая уж и старая 3.1.0. И партиций не много 2500 на 3 брокера и rf=3. Пока нагрузка маленькая и данных не много. В логах вот и увидел, что синхронизация реплик стала страдать и брокеры друг друга исключали из insync реплик разных партиций. Больше ничего существенного в логах не видно. В логах консьюмеров видно было ретраии на коммиты оффсетов.

А сеттинги брокеров тюнили или дефолтовые?

нет, намеренно не меняли практически ничего кроме очевидных моментов (тут где-то дефолты могут быть, но оставлены для явности): num.network.threads=3 num.io.threads=8 socket.send.buffer.bytes=102400 socket.receive.buffer.bytes=102400 # This parameter must be less than the JAVA heap size socket.request.max.bytes=104857600 queued.max.requests=500 num.recovery.threads.per.data.dir=1 offsets.topic.replication.factor=3 transaction.state.log.replication.factor=3 transaction.state.log.min.isr=1 # Increase carefully, cluster performance may drop message.max.bytes=1000000 replica.lag.time.max.ms=10000 leader.imbalance.check.interval.seconds=30

ну из очевидного, раз у вас реплики разъезжаются, то накрутить: num.replica.fetchers (с этим аккуратней, я удвоил дефолт, стало хуже, поэтому по чуть чуть добавляйте). replica.fetch.max.bytes (в тестах на 3-х брокерах дальше 50MB у меня уже особо на скорость не влияло) replica.socket.receive.buffer.bytes (лично в моих тестах 360кб дало более менее норм результаты, при сильном завышении начинались проблемы) еще смотрю у себя в конфиге, что в два раза сократил replica.socket.timeout.ms, но почему уже не помню... может и нет особого в этом смысла. А вообще в идеале синтетикой сформировать свой типовой профиль нагрузки (размер сообщения, рейт, число консьюмеров, продьюсеров) и погонять на тесте играясь с настройками. Мне так удалось существенно (в разы) улучшить производительность на тех же виртуалках.