> Все эти костыли по-своему замечательны, но проблем дизайна протокола syslog они не
> решают. Наиболее паршивых проблем две:
> 1. Неструктурированная запись. syslog by design ориентирован на человека, а не на
> машинный парсинг, поэтому вместо структурированной записи с именами полей, получается
> одна текстовая строчка, которую в общем случае может понять только человек.
> Такое вот сжатие с потерями. В то время как в Journal
> это сжатие происходит не на стадии записи лога, а на стадии
> выдачи его человеку. При необходимости, и программы, и человек могут использовать
> полезную информацию о структуре записи (например, искать сообщения по UUID).

Все программисты сразу кинулись переписывать программы под journald ?

> 2. Недоверенная информация. В syslog может писать кто угодно и что угодно.
> Даже из-под nobody можно написать туда такого, что админ будет месяц
> разбираться.

А вот ненадо ставить права на лог 777.

> В UNIX эту проблему решили много лет назад, введя специальный защищенный бинарный
> лог (BSM). Так появилась инфраструктура аудита.
> Но вопросы структурирования, индексирования информации, быстрого поиска по ней и т.д. актуальны
> не только для событий безопасности, но и для всех системных событий,
> так что появление Journal было неизбежно.

вы действительно хотите индексировать логи на боевом сервере?

Как там у journald с удаленными логами, не стриминг по http а именно удаленная запись логов.