> В случае с journald достаточно почитать документацию 1 (одной) программы размером 2
> (два) экрана, 5 (пять) минут поиграться с форматами вывода, чтобы подсмотреть,
> какое значение имеет смысл передавать параметру FIELD и собссно на этом
> всё. Лично у меня на вышеприведённое ушло 15 (пятнадцать) минут попивания
> чая.Да дело не в том, насколько аккуратна и полна документация. Это простой способ судить о том, насколько плох дизайн программы. Вот и все. Это вам написали в ответ на непонятную отсылку к коду.
> Вот-вот. А потом из-за таких вот самородков с «приложению виднее» выясняется,
> что для обучения приложения не гадить в readonly раздел, на котором
> /var/log только для проформы, нужно переписать половину этого самого приложения.
Не пользуйтесь плохими программами. Сейчас XXI век - уже давно есть выбор в любой области. Лично я с подобным не сталкивался уже лет 10. Нигде пути уже не хардкодят (ну, в отличие от Поттеринга, кстати).
> И ах да. utmp/wtmp ведь являются бинарниками уже сто лет и почему-то
> вам это не мешает. Будьте последовательны уже.
Это, скажем так, не совсем лог типа syslog. А чем, собственно, вам не нравится это исключение?
> *Встроенного* *структурированного* хранилища логов как не было, так и нет. Поэтому разницы
> нету.
Его и не будет. Нечего, в общем случае, структурировать. Пример: гуру ваш считает уместным гадить в логи тоннами ratelimit.c: 12 events suppressed. Что вы предлагаете здесь "структурировать" - кроме "вот - строчка в лог" и "а вот - pid программы"?
Посмотрите на апач. Это пример *сложного* сервиса. Как не странно, никакого мегаформата для логов (error) они не выдумали. Может это от того, что у кого-то есть знания и опыт, опыт работы с большими объемами данных?
> Есть миллиард файликов в /var/log, которые каждая софтина считает своим
> долгом вести в собственном уникальном формате. ...
Есть люди, которые знают что, куда, как и почему гадит. А есть школьники, для которых всякая ерунда - непостижимый сюрприз, а системная документация - тайна за семью печатями...
