У нас долгое время было так:
(логи приложения\системные логи) - (redis logstash rsyslog) - elasticsearch
Переехали на такую схему:
(логи приложения\системные логи) - fluent-bit - kafka - fluentd - (loki, elasticsearch, kafka и тд)
Схемы упрощенные, но в целом так.
После переезда на вторую схему (занимался не я, так что всех подробностей могу не знать) задачек от команд типа "Аааааа, мы не видим свои логи, памагите" стало гораздо меньше)

А зачем там был redis? и если был logstash - то зачем еще и rsyslog? И зачем кафка между двумя fluent, там и так есть буферизация при отказе получателя, так что кафка не нужна.
Т.е. сначала была совсем странная схема, потом перешли на более вменяемую, но зачем-то с кафкой в центре.

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

Чтобы в случае отказа одного из серверов ничего не отвалилось.

Или нужно ещё что-то? Контрол центр вообще необходим для работы?

А то во всех кейсах, что я находил, все сервисы раскиданы по разным серверам. Это мне кажется не очень надежным решением

А буферизация рассчитана на какое время? 5 минут? Час? День? Неделю?

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

Решение когда вся информация организации идет в 1 инстанс чего угодно выглядит странным.
Это ведь классическая «единая точка отказа» (single point of failure).

Тем более когда нагрузка очень большая.

А если пода погибла, то всё, потеряли этот буфер?

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

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

Кто в предлагаемой схеме буде отвечать за промежуточное хранение данных?

Эээ, так и флюент буферизирует на диск, если получатель недоступен. В чем разница?

Это который сайдкар?

И тут тоже тонкость. По одной записи в кафку отправлять не будешь, неэффективно, так что буферизовать все равно придется на сайдкаре )

Ага, сайдкар.

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

То есть мы надёжность хранения в Кафке на полном серьёзе сравниваем с надёжностью хранения в сайдкаре, жизненным циклом которого управляет k8s и запущенное в поде основное приложение?

Если логи являются бизнес-критикал, то там вообще другие решения (но не надо это называть логами, это уже телеметрия или аудит)

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

Куда будут доставляться логи если кафка недоступна?

Нет. Мы про то, что надежность всей цепочки в данном сценарии практически не меняется от замены кафки на http