И, если уж на то пошло, то почему не journald?

Вот когда будет несколько сот гигов в сутки с одного инстанса - тогда и узнаешь, как работает.

У меня пока сотня, но это я еще не все собрал.

Кстати, логи с сетевых железок, имеет смысл вообще собирать?

Это по вкусу. Модель угроз смотри, вот это вот всё.

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

нет. если читать их некому.

как дополнительный вариант - можно логи сгружать в КХ. И делать желаемую аналитику.
Универсальных систем на все случаи жизни построить не получится.

А в чем преимучество CH перед ES?

скорость, компрессия.

rsyslog написан на C, если что, и автор докторскую защитил на нём - ну так, к слову.

так что на rsyslog не гони.

кто сказал что я гоню? вопрос не в передаче, а в хранении. Я говорю что хранить в еластике дорого.

рсислог не обеспечивает никак пост обработку и постройку аналитики.

Это-то понятно, что на C. А на чем еще коммитить к Самому?

это означает что нужно потом делать свой велосипед(от парсера до выгрузки в системы по типу еластика или КХ)

А вот это вот точно?

Постобработка - это до выгруза в эластик?

это два разных мира

Вот я и спрашиваю: может можно вообще journald для этого использовать?