>> Сначала выяснить, куда логи собссно пишутся, затем посмотреть, в каком формате они вообще ведутся
> Ну да. Документацию программ почитать. Увы, мир суров. Интуитевен только интерфейс с соской...В случае с journald достаточно почитать документацию 1 (одной) программы размером 2 (два) экрана, 5 (пять) минут поиграться с форматами вывода, чтобы подсмотреть, какое значение имеет смысл передавать параметру FIELD и собссно на этом всё. Лично у меня на вышеприведённое ушло 15 (пятнадцать) минут попивания чая.
>> затем придумать и отладить регэксп для выковыривания только того, что нужно и только затем — собссно позвать grep. Да уж, удачнее просто некуда.
> Универсального формата нет и не предвидится. Приложению виднее как мариновать данные в логе, если простенький формат уровня syslog не устраивает.
Вот-вот. А потом из-за таких вот самородков с «приложению виднее» выясняется, что для обучения приложения не гадить в readonly раздел, на котором /var/log только для проформы, нужно переписать половину этого самого приложения.
И ах да. utmp/wtmp ведь являются бинарниками уже сто лет и почему-то вам это не мешает. Будьте последовательны уже.
>> Можно ли? Если мне не изменяет склероз, Rainer Gerhards активизировал разработку rsyslog (в частности, добавил туда поддержку альтернативных бэкендов и криптоподпись логов) *только после* анонса journald.
> Вы пропустили самую существенную часть ключевой фразы. Правильнее: добавил *еще*. Есть разница, правда?
*Встроенного* *структурированного* хранилища логов как не было, так и нет. Поэтому разницы нету. Есть миллиард файликов в /var/log, которые каждая софтина считает своим долгом вести в собственном уникальном формате. Есть демон, который умеет в том числе гадить в эти файлы. И есть софт, который тоже умеет гадить в эти файлы в обход помянутого демона.
Олсо journald предоставляет (пользуясь близостью к systemd) несколько больше информации о процессе, пославшем сообщение в лог.
