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

Тут обсуждают, зачем логи через кафку пускать?

По-моему все достаточно просто - буфер для усреднения нагрузки + способ не потерять данные, если место сборки логи упадет и потрет локальный stdout раздел.
Кафка один из вариантов, но можно же и другие.
Если в системе одна виртуалка, с которой логи собираются в условный стекдрайвер, то тут посередине ничего не нужно

а у fluent какой буфер, какого размера, он настраивается?

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

Опять же, тут “кафка” можно заменить на другую очередь, просто кафка идеально подходит для логов, т.к. она сама лог

Есть в памяти, есть на диске, настраивается

А зачем для логов дедупликация? И вообще ее проще сделать на сайдкаре продьюсера )

Так никто и не говорит приложением в кафку писать логи (не говорили же?)
Обычно так и делается, что сайдкар парсит логи из stdout и отправляет кафкой в elk

Логи приложухой писать щас современно

сайдкаром это для легаси приложух

хотелось бы раскрытия "обычно так и делается" - весь разговор выше был об этом

Ну как именно сайдкар из приложения логи получает - не так важно.
Но дедупликация часто на нем (как и буферизация и дофига всего еще )

Это очень плохая идея )

почему плохая?

я кстати уже придумал как оправдать при этом что делать если кафка недоступна - надо что бы приложение работало с этим же кластером кафки и если кафка не работает, то тогда приложение не работает, а если приложение не работает то и логов нет - фьить ха

щас все так делают

Приходится кучу логики делать в приложении, а обычно оно так не умеет.
И при падении приложения - теряешь все логи, а это совсем грустно, так как нужны именно логи при падении )

почему теряешь?

Вот да, приложение, которое падает если логи недоступны - это ровно то, что нужно для надежных систем, да )