История изменений
Исправление liksys, (текущая версия) :
- Бинарные логи journald требуют использования journalctl или libsystemd, что затрудняет автоматический разбор или интеграцию в shell-скрипты и CI/CD пайплайны.
На затрудняет. journalctl вполне себе дружественен к shell-скриптам, а индексация и селекторы позволяют обрабатывать логи сильно проще - не нужно городить конструкции из грепов и седов. А еще не забываем про встроенную агрегацию и запросы по нескольким сервисам. И всё это, кстати, доступно в том числе и по API.
Неудобно, медленно при большом объёме логов.
Это неправда, разумеется.
grep ‘nginx.*failed to bind’ /var/log/syslog
А это вообще не эквивалент команды с journald, потому что не учитывает выборку по времени. Ты приводишь разные команды для сравнения.
Бинарные логи journald не соответствуют многим регламентам, и не обеспечивают встроенных механизмов подписания, хеширования, сохранения изменений, контроля доступа по принципу least privilege.
journald при большом потоке логов быстро захламляется, замедляется, не даёт тонкого контроля над размером и временем хранения
Есть неймспейсы.
И так далее, и в том же духе.
Думаю, не стоит продолжать метать перед тобой бисер. С тобой и твоим фанатизмом всё ясно.
Не дерзи, клоун, здесь технический форум, а не свинарник. Объясняю популярно: всё, что ты перечисляешь, это очень нишевые юзкейсы. Нужные, но даже не на 1% машин. Для большей части серверов и рабочих станций journald подойдет, для большинства современного эмбеда тоже. А если у тебя сверхвысокий хайлоад - то и используй соответствующие средства.
У каждой технологии есть своя область применения. Самые распространенные задачи journald решает лучше syslog. А для нишевых ты можешь использовать нишевые решения.
Исправление liksys, :
- Бинарные логи journald требуют использования journalctl или libsystemd, что затрудняет автоматический разбор или интеграцию в shell-скрипты и CI/CD пайплайны.
На затрудняет. journalctl вполне себе дружественен к shell-скриптам, а индексация и селекторы позволяют обрабатывать логи сильно проще - не нужно городить конструкции из грепов и седов. А еще не забываем про встроенную агрегацию и запросы по нескольким сервисам. И всё это, кстати, доступно в том числе и по API.
Неудобно, медленно при большом объёме логов.
Это неправда, разумеется.
grep ‘nginx.*failed to bind’ /var/log/syslog
А это вообще не эквивалент команды с journald, потому что не учитывает выборку по времени. Ты приводишь разные команды для сравнения.
Бинарные логи journald не соответствуют многим регламентам, и не обеспечивают встроенных механизмов подписания, хеширования, сохранения изменений, контроля доступа по принципу least privilege.
journald при большом потоке логов быстро захламляется, замедляется, не даёт тонкого контроля над размером и временем хранения
Есть неймспейсы.
И так далее, и в том же духе.
Думаю, не стоит продолжать метать перед тобой бисер. С тобой и твоим фанатизмом всё ясно.
Не дерзи, клоун, здесь технический форум, а не свинарник. Объясняю популярно: всё, что ты перечисляешь, это очень нишевые юзкейсы. Нужные, но даже не на 1% машин. Для большей части серверов и рабочих станций journald подойдет, для большинства эмбеда тоже. А если у тебя сверхвысокий хайлоад - то и используй соответствующие средства.
У каждой технологии есть своя область применения. Самые распространенные задачи journald решает лучше syslog. А для нишевых ты можешь использовать нишевые решения.
Исправление liksys, :
- Бинарные логи journald требуют использования journalctl или libsystemd, что затрудняет автоматический разбор или интеграцию в shell-скрипты и CI/CD пайплайны.
На затрудняет. journalctl вполне себе дружественен к shell-скриптам, а индексация и селекторы позволяют обрабатывать логи сильно проще - не нужно городить конструкции из грепов и седов. А еще не забываем про встроенную агрегацию и запросы по нескольким сервисам. И всё это, кстати, доступно в том числе и по API.
Неудобно, медленно при большом объёме логов.
Это неправда, разумеется.
grep ‘nginx.*failed to bind’ /var/log/syslog
А это вообще не эквивалент команды с journald, потому что не учитывает выборку по времени. Ты приводишь разные команды для сравнения.
Бинарные логи journald не соответствуют многим регламентам, и не обеспечивают встроенных механизмов подписания, хеширования, сохранения изменений, контроля доступа по принципу least privilege.
journald при большом потоке логов быстро захламляется, замедляется, не даёт тонкого контроля над размером и временем хранения
Есть неймспейсы.
И так далее, и в том же духе.
Думаю, не стоит продолжать метать перед тобой бисер. С тобой и твоим фанатизмом всё ясно.
Не дерзи, клоун, здесь технический форум, а не свинарник. Объясняю популярно: всё, что ты перечисляешь, это очень нишевые юзкейсы. Нужные, но даже не на 1% машин. Для большей части серверов и рабочих станций это подойдет, для большинства эмбеда тоже. А если у тебя сверхвысокий хайлоад - то и используй соответствующие средства.
У каждой технологии есть своя область применения. Самые распространенные задачи journald решает лучше syslog. А для нишевых ты можешь использовать нишевые решения.
Исходная версия liksys, :
- Бинарные логи journald требуют использования journalctl или libsystemd, что затрудняет автоматический разбор или интеграцию в shell-скрипты и CI/CD пайплайны.
На затрудняет. journalctl вполне себе дружественен к shell-скриптам, а индексация и селекторы позволяют обрабатывать логи сильно проще - не нужно городить конструкции из грепов и седов. А еще не забываем про встроенную агрегацию и запросы по нескольким сервисам. И всё это, кстати, доступно в том числе и по API.
Неудобно, медленно при большом объёме логов.
Это неправда, разумеется.
grep ‘nginx.*failed to bind’ /var/log/syslog
А это вообще не эквивалент команды с journald, потому что не учитывает выборку по времени. Ты приводишь разные команды для сравнения.
Бинарные логи journald не соответствуют многим регламентам, и не обеспечивают встроенных механизмов подписания, хеширования, сохранения изменений, контроля доступа по принципу least privilege.
journald при большом потоке логов быстро захламляется, замедляется, не даёт тонкого контроля над размером и временем хранения
Есть неймспейсы.
И так далее, и в том же духе.
Думаю, не стоит продолжать метать перед тобой бисер. С тобой и твоим фанатизмом всё ясно.
Не дерзи, клоун, здесь технический форум, а не свинарник. Объясняю популярно: всё, что ты перечисляешь, это очень нишевые юзкейсы. Нужные, но даже не на 1% машин. Для большей части системных серверов и рабочих станций это подойдет, для много эмбеда тоже подойдет. А если у тебя сверхвысокий хайлоад - то и используй соответствующие средства.
У каждой технологии есть своя область применения. Самые распространенные задачи journald решает лучше syslog. А для нишевых ты можешь использовать нишевые решения.