Исправление intelfx, (текущая версия) :
Лезешь с другого устройства в инет, чтобы узнать, как читать логи. Ибо если этим не заниматься каждый день, то нафиг тебе это не надо.
А мог ведь просто зайти в знакомом текстовом редакторе
Ты забываешь, что знаний о том, как обращаться с обычными текстовыми логами, у тебя тоже по дефолту не было. Поэтому этот аргумент субъективен: он основывается на твоём личном нежелании разбираться; на желании того, чтобы «всё было как раньше».
И как ни удивительно, никакая метаинформация для фильтрации в этом случае не нужна.
В этом конкретном случае — не нужна. Есть ещё множество других, например, посмотреть логи конкретного демона за некий период времени. Или все ошибки конкретного демона. Или ещё что-то там такое. Можно сказать, мол, «всегда можно руками отфильтровать» или «заранее настроить rsyslog+logrotate». Но 1) сообщений может быть слишком много, чтобы фильтровать руками и 2) ты не всегда заранее знаешь, на какие именно поля/признаки настраивать фильтрацию-сортировку на лету.
для всех подряд систем, включая телефоны
Как раз-таки «для всех подряд систем» подобное и предназначено, потому что average user не будет писать *дцать правил для rsyslog. А когда приспичит — опа, всё уже собрано, метаданные проставлены, просто впиши выражение для фильтра и радуйся.
И кто сказал, что «включая телефоны»? Storage=none и всё хорошо. Можно вообще замаскировать юнит. Здесь всё на совести вендора.
Могу сказать, чем меня напрягают эти решения, которые жрут память и проц как не в себя и почти могут подать кофе в постель, предварительно напечатав чашку на 3d-принтере и покрыв все qr-кодами, но при этом полезной работы еще не производят.
Здесь всё предложение представляет собой ничем не подкреплённое эмоционирование. По крайней мере, к systemd/journald здесь вроде бы ничего отношения не имеет.
А вот еще интересное. На то, чтобы проставить метаинформацию расходуется процессорное время.
Сколько его расходуется по сравнению с «традиционным вариантом» системы логгирования? Было бы неплохо получить цифры, чтобы быть уверенным в том, что этим дополнительным процессорным временем нельзя пренебречь (например, по сравнению с временем, затрачиваемым на прикладные задачи).
Исходная версия intelfx, :
Лезешь с другого устройства в инет, чтобы узнать, как читать логи. Ибо если этим не заниматься каждый день, то нафиг тебе это не надо.
А мог ведь просто зайти в знакомом текстовом редакторе
Ты забываешь, что знаний о том, как обращаться с обычными текстовыми логами, у тебя тоже по дефолту не было. Поэтому этот аргумент субъективен: он основывается на твоём личном нежелании разбираться и желании того, чтобы «всё было как раньше».
И как ни удивительно, никакая метаинформация для фильтрации в этом случае не нужна.
В этом конкретном случае — не нужна. Есть ещё множество других, например, посмотреть логи конкретного демона за некий период времени. Или все ошибки конкретного демона. Или ещё что-то там такое. Можно сказать, мол, «всегда можно руками отфильтровать» или «заранее настроить rsyslog+logrotate». Но 1) сообщений может быть слишком много, чтобы фильтровать руками и 2) ты не всегда заранее знаешь, на какие именно поля/признаки настраивать фильтрацию-сортировку на лету.
для всех подряд систем, включая телефоны
Как раз-таки «для всех подряд систем» подобное и предназначено, потому что average user не будет писать *дцать правил для rsyslog. А когда приспичит — опа, всё уже собрано, метаданные проставлены, просто впиши выражение для фильтра и радуйся.
И кто сказал, что «включая телефоны»? Storage=none и всё хорошо. Можно вообще замаскировать юнит. Здесь всё на совести вендора.
Могу сказать, чем меня напрягают эти решения, которые жрут память и проц как не в себя и почти могут подать кофе в постель, предварительно напечатав чашку на 3d-принтере и покрыв все qr-кодами, но при этом полезной работы еще не производят.
Здесь всё предложение представляет собой ничем не подкреплённое эмоционирование. По крайней мере, к systemd/journald здесь вроде бы ничего отношения не имеет.
А вот еще интересное. На то, чтобы проставить метаинформацию расходуется процессорное время.
Сколько его расходуется по сравнению с «традиционным вариантом» системы логгирования? Было бы неплохо получить цифры, чтобы быть уверенным в том, что этим дополнительным процессорным временем нельзя пренебречь (например, по сравнению с временем, затрачиваемым на прикладные задачи).