И, традиционно, нельзя использовать в качестве внешнего монитора и клавиатуры для подключения к серверу. Хотя, казалось бы, вот уж точно интересная для ЦА фича была бы
Когда вы вбиваете journalctl в консоль, то читаются все логи и передаются в pager (по умолчанию это less), а последний уже и обрабатывает ваше GG, переходя в конец текстового полотна.
Где в этом процессе вы увидели хоть какое-то управление или фильтрацию логов в самом journalctl? Самое натуральное «прочитай и вывали мне всё, что есть, а я промотаю руками до конца», только обмазанное less.
Вкратце:
— Да, я (естественно) читал мануал
— Да я это пробовал
— Нет, у меня не сложилось впечатление о том, что это пригодно для прода — слишком много нюансов всплывает в реальной эксплуатации. Я, если честно, ни одного места с systemd-journal-remote в эксплуатации не знаю.
journald достаточно производительный by design, у него даже rate limit, например, в общем-то аналогичен rsyslog'у (1000msg/30sec vs 20000msg/10min соответственно). Да, он однопоточный, но можно запустить отдельный поток, тут про это уже написали.
А ещё я бы серьёзно поразмыслил над вопросом реальной необходимости логирования в таких количествах, что озвученная проблема производительности так остро стоит.
Я бы это, если честно, применял только в случае необходимости сливания логов в пределах локалхоста через сокеты. Подозреваю что оно именно для данной задачи и делалось, больно уж сыро для реальной ненадёжной сети всё. Для консолидации с кучи машин на отдельный сервер всё-таки лучше что-то специализированное расчехлить.
Классические системы, как вы сказали, все эти проблемы решили еще 10 лет назад как минимум
Проблемы софта, пишущего в stdout/stderr не решили, только костыли с педиректом вывода полуручными методами
Ну тупой кейс, забил в консоли journalctl, нажал вниз до конца
Ну так именно что не разобрались, судя по написанному. Потому что и вывод можно фильтровать по разному и искать по временным рамкам и индексирование, учитываемое при чтении имеется. И, конечно же, это всё не работает от слова совсем ежели вы самолично просите вывалить вам ВСЕ логи, которые имеются в принципе.
Если без шуток, то сейчас бы всякие оркестраторы с системами инициализации в одну кучу валить и сравнивать. Или на локалхосте кубер для банального запуска софта использовать.
bash скрипт, или python или Perl или go или ...? ))
тоесть любая init система ))
Это не init-системы, а вагоны костылей разной степени запутанности. Они нативно и без велосипедов нередко и запустить/остановить то нужный софт не могут.
Никто не только не заставляет пользоваться исключительно journald, но даже и вообще писать его бинарные логи на диск. Неправильно воспринимать сабж как замену для какой-нибудь
классической системы типа rsyslog. Его задача — собирать всеми возможными способами вывод разнообразного софта в единое полотно. А что дальше с этим потоком логов творить — ваше дело. Можно, например, буквально за 10 секунд сделать так, что journald будет хранить логи только в оперативной памяти + форвардить их в классический rsyslog/syslog-ng/ваша_привычная_система. И пусть она пишет в текстовые файлы по любой желаемой логике, пересылает по сети на единый сервер, сливает в /dev/null — всё, что захотите.
Использовать "классические" системы без такой прослойки в мире современного софта, часто пишущего свои логи тупо в stdout, ОЧЕНЬ неудобно. Как минимум, нужно много костылей по передаче fd этих stdout от каждого запущенного скрипта в одну из многочисленных "классических" систем логирования. Journald же встроен в init систему и позволяет проворачивать такие вещи элементарным образом.
Так что конкретно это и близко не техническая причина, просто вы не разобрались до конца в целевой нише journald.
Ну вот про Tarantool вы зря так. Там, ЕМНИП, ACID by design заложен, по крайней мере в пределах одного инстанса приложения. Оно попросту однопоточное, это даже преподносилось как плюшка и одна из главных причин высокой производительности: никаких затратных межядерных синхронизаций и блокировок.
Ну и как замену "взрослым" RDBMS никто tarantool серьёзно и не позиционировал. У него другая область применения и в ней он на самом деле хорош.
Сразу видно того, кто не особенно разбирался в данном вопросе.
Community версия регулярно получает всякие плюшки из pro, просто это происходит на пару версий позже. И такой подход весьма часто встречается в различном софте. Разработчики этих самых плюшек тоже, знаете ли, хотят кушать, а работа над ними часто занимает очень много времен. Буквально на уровне несовместимости с "поковырять в свободное время".
Странный встречный вопрос на странную претензию: покажите мне любую другую init-систему, в которой такое возможно провернуть нативно и без велосипедов.
Подозреваю что пример вряд ли найдётся ибо это задача не совсем из тех, что должны решать данные системы.
Все исторические версии всех пакетов давно складываются в archive.org (а до этого складывались на archive.archlinux.org). Можно скачать и поставить оттуда нужную версию.
У меня лично даже накорябан специальный reverse proxy на aiohttp для скачивания с этих ресурсов конкретной запрашиваемой версии пакета. Натуральным образом можно абсолютно прозрачно поставить нужное на системе хоть годовалой давности.
Можно сделать ход конём и использовать в своём питоновском скрипте sd_notify. Это нечто watchdog-like, созданное для отправки в systemd keepalive сообщений и оповещений об изменении состояния сервиса через специальный сокет. Можно отслеживать и обрабатывать не только падения с ошибками, но и, например, зависание сервиса.
По поводу автоматического перезапуска упавшего сервиса есть нюанс: по умолчанию systemd позволяет не более DefaultStartLimitBurst(=5) перезапусков за интервал, равный DefaultStartLimitIntervalSec(=10s). После чего юнит уходит в failed state и больше не перезапускается вообще. Так что может быть нужным либо StartLimitIntervalSec/StartLimitBurst поправить, либо интервал межу рестартами увеличить. Или сервис может упасть навсегда после пяти неудачных попыток рестарта.
И, традиционно, нельзя использовать в качестве внешнего монитора и клавиатуры для подключения к серверу. Хотя, казалось бы, вот уж точно интересная для ЦА фича была бы
Так делают просто потому что есть старый привычный инструмент, а journald — новый и нужно привыкать.
Где в этом процессе вы увидели хоть какое-то управление или фильтрацию логов в самом journalctl? Самое натуральное «прочитай и вывали мне всё, что есть, а я промотаю руками до конца», только обмазанное less.
— Да, я (естественно) читал мануал
— Да я это пробовал
— Нет, у меня не сложилось впечатление о том, что это пригодно для прода — слишком много нюансов всплывает в реальной эксплуатации. Я, если честно, ни одного места с systemd-journal-remote в эксплуатации не знаю.
А ещё я бы серьёзно поразмыслил над вопросом реальной необходимости логирования в таких количествах, что озвученная проблема производительности так остро стоит.
Проблемы софта, пишущего в stdout/stderr не решили, только костыли с педиректом вывода полуручными методами
Ну так именно что не разобрались, судя по написанному. Потому что и вывод можно фильтровать по разному и искать по временным рамкам и индексирование, учитываемое при чтении имеется. И, конечно же, это всё не работает от слова совсем ежели вы самолично просите вывалить вам ВСЕ логи, которые имеются в принципе.
Если без шуток, то сейчас бы всякие оркестраторы с системами инициализации в одну кучу валить и сравнивать. Или на локалхосте кубер для банального запуска софта использовать.
Это не init-системы, а вагоны костылей разной степени запутанности. Они нативно и без велосипедов нередко и запустить/остановить то нужный софт не могут.
Никто не только не заставляет пользоваться исключительно journald, но даже и вообще писать его бинарные логи на диск. Неправильно воспринимать сабж как замену для какой-нибудь
классической системы типа rsyslog. Его задача — собирать всеми возможными способами вывод разнообразного софта в единое полотно. А что дальше с этим потоком логов творить — ваше дело. Можно, например, буквально за 10 секунд сделать так, что journald будет хранить логи только в оперативной памяти + форвардить их в классический rsyslog/syslog-ng/ваша_привычная_система. И пусть она пишет в текстовые файлы по любой желаемой логике, пересылает по сети на единый сервер, сливает в /dev/null — всё, что захотите.
Использовать "классические" системы без такой прослойки в мире современного софта, часто пишущего свои логи тупо в stdout, ОЧЕНЬ неудобно. Как минимум, нужно много костылей по передаче fd этих stdout от каждого запущенного скрипта в одну из многочисленных "классических" систем логирования. Journald же встроен в init систему и позволяет проворачивать такие вещи элементарным образом.
Так что конкретно это и близко не техническая причина, просто вы не разобрались до конца в целевой нише journald.
Ну вот про Tarantool вы зря так. Там, ЕМНИП, ACID by design заложен, по крайней мере в пределах одного инстанса приложения. Оно попросту однопоточное, это даже преподносилось как плюшка и одна из главных причин высокой производительности: никаких затратных межядерных синхронизаций и блокировок.
Ну и как замену "взрослым" RDBMS никто tarantool серьёзно и не позиционировал. У него другая область применения и в ней он на самом деле хорош.
Сразу видно того, кто не особенно разбирался в данном вопросе.
Community версия регулярно получает всякие плюшки из pro, просто это происходит на пару версий позже. И такой подход весьма часто встречается в различном софте. Разработчики этих самых плюшек тоже, знаете ли, хотят кушать, а работа над ними часто занимает очень много времен. Буквально на уровне несовместимости с "поковырять в свободное время".
Да, документация у systemd прямо эталонно хороша. Её, на мой взгляд, можно смело ставить в пример того, как нужно маны писать.
Можно вопрос для пополнения личной статистики? А по каким объективным техническим причинам было решено использовать НЕ systemd?
Странный встречный вопрос на странную претензию: покажите мне любую другую init-систему, в которой такое возможно провернуть нативно и без велосипедов.
Подозреваю что пример вряд ли найдётся ибо это задача не совсем из тех, что должны решать данные системы.
Все исторические версии всех пакетов давно складываются в archive.org (а до этого складывались на archive.archlinux.org). Можно скачать и поставить оттуда нужную версию.
У меня лично даже накорябан специальный reverse proxy на aiohttp для скачивания с этих ресурсов конкретной запрашиваемой версии пакета. Натуральным образом можно абсолютно прозрачно поставить нужное на системе хоть годовалой давности.
Можно сделать ход конём и использовать в своём питоновском скрипте sd_notify. Это нечто watchdog-like, созданное для отправки в systemd keepalive сообщений и оповещений об изменении состояния сервиса через специальный сокет. Можно отслеживать и обрабатывать не только падения с ошибками, но и, например, зависание сервиса.
По поводу автоматического перезапуска упавшего сервиса есть нюанс: по умолчанию systemd позволяет не более DefaultStartLimitBurst(=5) перезапусков за интервал, равный DefaultStartLimitIntervalSec(=10s). После чего юнит уходит в failed state и больше не перезапускается вообще. Так что может быть нужным либо StartLimitIntervalSec/StartLimitBurst поправить, либо интервал межу рестартами увеличить. Или сервис может упасть навсегда после пяти неудачных попыток рестарта.