История изменений

То есть необходимости грепа оно всё равно не отменяет. Типовые фильтры там немногочисленны и слишком уж примитивны.

Молоток не подходит для забивания свай - откажемся от молотка? Тебе дается инструмент, который покрывает подавляющее большинство запросов к логгеру, которые заключаются в чем-то типа «дай мне лог с последней загрузки для сервиса ххх». Если инструмент закрывает большую часть типовых задач - то он однозначно стоит внедрения.

акого размера должны быть логи чтобы это ускорение стало реально существенно?

Пережевать десятки и сотни мегабайт регекспами, или пробежаться по индексам? По-моему, ответ очевиден.

пишут всё равно в свой отдельный лог который типично анализируется специальными тулзами

Это возвращает нас к первому пункту: инструмент, подходящий для большей части задач - это хорошо. Плохо, когда инстурмент является настолько универсальным, что его одинаково неудобно использовать всем. Сислог пишет текстовые файлы, но индексации в них нет, для фильтрации нужны велосипеды с грепом, а для ротирования нужен внешний костыль.

Так в том-то и дело что не исключает.

Вот том-то и дело, что исключает. Просто с оговоркой: для большинства задач. А значит его уже стоит использовать. Я тебе больше скажу: есть типовые запросы, которые ты можешь выполить с journalctl, но для syslog тебе придется костылять велосипед: запрос логов юнитов по регекспу. Например, «дай мне логи сервисов foo* за сегодняшний день», который покажет тебе сплошной вывод оных сервисов, сообщения которых будут идти рядом друг с другом, чтобы ты увидел корелляцию их взаимодействия.

В том-то и дело что не «единичные»,а как раз любой крупный сервис,который пишет свои логи примерно всегда.

Нет, это буквально единичные исключения. У тебя на системе запущена (или ожидает запуска) херова гора разных подсистем, и все они пишут свои логи. Ядро, udev, logind какой-нибудь, kwin, что угодно. Для логов больших сервисов же существуют специальные инструменты, которые удобны именно для анализа, а не для рядового администрирования. И их тоже можно собирать через journald, кстати.

То есть это дистростроители так сконфигурировали.

Ну так и чьи это проблемы? Пинай разработчиков дистрибутива, пусть делают нормально. Ты же понимаешь, что настройку записи в сислог точно так же нужно кому-то реализовать, как и запись в журнал? Просто сопровождающие в дебиане яжхудожники и упаковывают дефолты кто во что горазд и «как видят».

То есть необходимости грепа оно всё равно не отменяет. Типовые фильтры там немногочисленны и слишком уж примитивны.

Молоток не подходит для забивания свай - откажемся от молотка? Тебе дается инструмент, который покрывает подавляющее большинство запросов к логгеру, которые заключаются в чем-то типа «дай мне лог с последней загрузки для сервиса ххх». Если инструмент закрывает большую часть типовых задач - то он однозначно стоит внедрения.

акого размера должны быть логи чтобы это ускорение стало реально существенно?

Пережевать сотни мегабайт регекспами или пробежаться по индексам? По-моему, ответ очевиден.

пишут всё равно в свой отдельный лог который типично анализируется специальными тулзами

Это возвращает нас к первому пункту: инструмент, подходящий для большей части задач - это хорошо. Плохо, когда инстурмент является настолько универсальным, что его одинаково неудобно использовать всем. Сислог пишет текстовые файлы, но индексации в них нет, для фильтрации нужны велосипеды с грепом, а для ротирования нужен внешний костыль.

Так в том-то и дело что не исключает.

Вот том-то и дело, что исключает. Просто с оговоркой: для большинства задач. А значит его уже стоит использовать. Я тебе больше скажу: есть типовые запросы, которые ты можешь выполить с journalctl, но для syslog тебе придется костылять велосипед: запрос логов юнитов по регекспу. Например, «дай мне логи сервисов foo* за сегодняшний день», который покажет тебе сплошной вывод оных сервисов, сообщения которых будут идти рядом друг с другом, чтобы ты увидел корелляцию их взаимодействия.

В том-то и дело что не «единичные»,а как раз любой крупный сервис,который пишет свои логи примерно всегда.

Нет, это буквально единичные исключения. У тебя на системе запущена (или ожидает запуска) херова гора разных подсистем, и все они пишут свои логи. Ядро, udev, logind какой-нибудь, kwin, что угодно. Для логов больших сервисов же существуют специальные инструменты, которые удобны именно для анализа, а не для рядового администрирования. И их тоже можно собирать через journald, кстати.

То есть это дистростроители так сконфигурировали.

Ну так и чьи это проблемы? Пинай разработчиков дистрибутива, пусть делают нормально. Ты же понимаешь, что настройку записи в сислог точно так же нужно кому-то реализовать, как и запись в журнал? Просто сопровождающие в дебиане яжхудожники и упаковывают дефолты кто во что горазд и «как видят».