Никак, разработчику не впился systemd
ему нужен механизм запуска его творения на целевой системе, ну и init систему
он рассматривает как такой механизм, но к сожалению мир не совершенен, и поэтому ему сильно проще передать через формат компоуз файла информацию, чем курить nnn… количество мэн документации по systemd
В итого, субъект становится штукой которой интересуются полторы калеки которые работают прям на железе, но к сожалению он для них так же проблемен, ибо не выполняет заявленных функций.
И да, я и есть те полторы калеки, монтирование файловых систем, запуск задач по таймеру и тд я решал еще 15 лет назад, связываю компоуз и реальный мир я каждый день, неожиданно мне за это платят, и не зп, мне клиенты платят. И пр. пр. пр.
Ну давайте так, систему легирования systemd по факту убил, вернее усложнил и сделал частично неработоспособной.
Варианты как посмотреть что то роли не играют.
Рассказы про валидацию логов, ну тоже если честно.
По крону, есть кейсы где интересней, но в общем то на то и вышло.
Есть варианты сильно лучше чем написание программ для запуска (баш портянок)
есть хуже, появились новые возможности (но сильно опоздали, показатель просто тупо запуск через докер(podman))
Претензии конкретные, замена функционала по логированию на софт не способный это делать, и не возможность простыми способами использовать альтернативы.
Я знаю как использовать journalctl, в примере выше сценарий явно расписан
это просто тупо логика, и она ну нифига не реализована, и посему если нужно чтоб journalctl использовала начальная линия поддержки, его приходится обкладывать альянсами или скриптами
Претензия по моему конкретно расписана, вы скажете что это не правда?
Обсуждаемо, задача любой синит системы ( в минимуме) сводится к запустить, остановить, отследить статус. Потом к этому добавили формирование окружения и тд, потом логику.
Вот то что вы называете костылями оно просто добавляет логику. Либо эта логика заложена в синит сиcтеме, ну а вы спрашивали какая синит система способна. Отвечаю, любая, потому что есть по сути Тьюринг полное приложение в виде скрипта, или это сразу описанной в программе.
Рецепт в студию ))
верней 2 рецепта
1) redhat like os
2) debian like os
Нужно отключить вообще journald
все логи, ядро и прочее должны идти в rsyslog или syslog-ng
идти они должны напрямую, не через journald.
Отсюда вопрос, наверно я отстал от жизни, запускаю я через systemd, по старой памяти оно гадит в stdout — stderr
как мне это в rsyslog минуя journald отправить?
Ну могу тупо в udp перенаправить, просто средствами linux и с определенной версии systemd, далее читать на сокете. Но это костыли, я просто так могу решить ограничения этой системы, есть другие костыли. Но вы мне говорите что есть универсальная система, но блин она не МОЖЕТ прокачать мой объем логов, и дальше?
Классические системы, как вы сказали, все эти проблемы решили еще 10 лет назад как минимум(с systemd не помню как тогда было), вы просто не смотрели их документацию.
К journald у меня конкретная претензия, мне приходится ее тупо выпиливать и заменять на rsyslog, syslog-ng, различные шипперы логов типа filebeat и тд (их ну дофига, тупо читают файл и пинают по tcp(udp))
Ну тупой кейс, забил в консоли journalctl, нажал вниз до конца, жду минуту (что по cpu и памяти смотреть не хочу, раньше было страшно, но на машине 32 гита оперативы, и в общем не смертельно)
еще раз, жду минуту, shift-gg (в переводе, покажи последнее)
в терминале (даже фантастическом) меньше 300 строк, утилита вместо того чтоб тупо прочитать (с бинарных данных, с ИНДЕКСАЦИЕЙ) последние 300 строк, посмотреть сколько у меня терминал показывает и вывести, тупо ЧИТАЕТ ВСЕ ЛОГИ ПОСЛЕДОВАТЕЛЬНО.
bash скрипт, или python или Perl или go или ...? ))
тоесть любая init система ))
Тут все деферамбы systemd сводятся к тому что оно уменьшило необходимость написания этих скриптов ( программ) и заменило эти программки на конфиг а претензии к тому, что там где раньше сидела программа которая нормально работала, под общую лавочку завезли что то, что зачастую не работает (ну или работает в n… количестве кейсов, но вариант не использовать systemd при этих кэйсах сделали весьма сложным)
Ну а ответ на ваш вопрос, любая. Они до systemd решали эти вопросы. И сейчас решают.
ЭЭЭ… мухи с котлетами не путайте. Формат файла и целостность перпендикулярны, вы можете делать бинарную вставку с хэшем, можете просто делать текстовую вставку с кэшем и префиксом, можете просто держать отдельный файл с таблицей
1 строка — хэш
2 строка — хэш от первой и от второй
и тд
вообще любой формат что бинарный, что не бинарный (по вашему определению)
это последовательность битов и байтов, они могут быть читаемы человеком или нет, но для компа роли никакой. Вопрос индексов (ну коль уж так надо) легко решается дом файлами, более того, я б сильно предпочел именно такое решение, как минимум это возможность индексирования постфактум, вначале накидали логов, потом индексировали. Более того, это давно работающее и стандартное решение, и целостность туда прикручивается с легкостью.
Вообще за 20 лет работы сталкивался, но ограничения все эти спокойно обходятся. Про здрастьте, в новых убунтах в сообщение дня вбито, ставьте куб, локальный, не парьтесь мозг. Там народ видно не в курсе, или просто забил.
Двоякое мнение, с одной стороны стало проще, с другой стороны особых изменений это не принесло. Скорее всякие куберы и номады движутся в более правильном направлении, и systemd их пытается догонять, но он уже проиграл. Максимум что он вытеснил другие системы инициализации но чисто политическими механизмами.
Почитал в доках, похоже что то в этом направлении делают.
Но пока не вижу решения, вариант выделите явный источник логов в отдельный канал предварительным описанием конфигов явно не решение. Пока костыль, возможно даже поможет, если не дешевле мимо него обработать.
А если закапываться, то есть конкретные вопросы на решение которых просто положили, из расчета кому надо и кто понимает, найдет решение, а остальным хватит 640kB
Собственно про journald выше упомянутый, который ну нифига не является достаточно производительным решением by design
ему нужен механизм запуска его творения на целевой системе, ну и init систему
он рассматривает как такой механизм, но к сожалению мир не совершенен, и поэтому ему сильно проще передать через формат компоуз файла информацию, чем курить nnn… количество мэн документации по systemd
В итого, субъект становится штукой которой интересуются полторы калеки которые работают прям на железе, но к сожалению он для них так же проблемен, ибо не выполняет заявленных функций.
И да, я и есть те полторы калеки, монтирование файловых систем, запуск задач по таймеру и тд я решал еще 15 лет назад, связываю компоуз и реальный мир я каждый день, неожиданно мне за это платят, и не зп, мне клиенты платят. И пр. пр. пр.
Варианты как посмотреть что то роли не играют.
Рассказы про валидацию логов, ну тоже если честно.
По крону, есть кейсы где интересней, но в общем то на то и вышло.
Есть варианты сильно лучше чем написание программ для запуска (баш портянок)
есть хуже, появились новые возможности (но сильно опоздали, показатель просто тупо запуск через докер(podman))
Претензии конкретные, замена функционала по логированию на софт не способный это делать, и не возможность простыми способами использовать альтернативы.
Вообще. За исключением вариантов потестить что оно работает на статистической погрешности.
вывалить все логи — и управление с терминала управляющей последовательностью команд, по моему несколько разные вещи.
это просто тупо логика, и она ну нифига не реализована, и посему если нужно чтоб journalctl использовала начальная линия поддержки, его приходится обкладывать альянсами или скриптами
Претензия по моему конкретно расписана, вы скажете что это не правда?
Вот то что вы называете костылями оно просто добавляет логику. Либо эта логика заложена в синит сиcтеме, ну а вы спрашивали какая синит система способна. Отвечаю, любая, потому что есть по сути Тьюринг полное приложение в виде скрипта, или это сразу описанной в программе.
верней 2 рецепта
1) redhat like os
2) debian like os
Нужно отключить вообще journald
все логи, ядро и прочее должны идти в rsyslog или syslog-ng
идти они должны напрямую, не через journald.
как мне это в rsyslog минуя journald отправить?
Ну могу тупо в udp перенаправить, просто средствами linux и с определенной версии systemd, далее читать на сокете. Но это костыли, я просто так могу решить ограничения этой системы, есть другие костыли. Но вы мне говорите что есть универсальная система, но блин она не МОЖЕТ прокачать мой объем логов, и дальше?
Классические системы, как вы сказали, все эти проблемы решили еще 10 лет назад как минимум(с systemd не помню как тогда было), вы просто не смотрели их документацию.
К journald у меня конкретная претензия, мне приходится ее тупо выпиливать и заменять на rsyslog, syslog-ng, различные шипперы логов типа filebeat и тд (их ну дофига, тупо читают файл и пинают по tcp(udp))
Ну тупой кейс, забил в консоли journalctl, нажал вниз до конца, жду минуту (что по cpu и памяти смотреть не хочу, раньше было страшно, но на машине 32 гита оперативы, и в общем не смертельно)
еще раз, жду минуту, shift-gg (в переводе, покажи последнее)
в терминале (даже фантастическом) меньше 300 строк, утилита вместо того чтоб тупо прочитать (с бинарных данных, с ИНДЕКСАЦИЕЙ) последние 300 строк, посмотреть сколько у меня терминал показывает и вывести, тупо ЧИТАЕТ ВСЕ ЛОГИ ПОСЛЕДОВАТЕЛЬНО.
Я не разобрался… ))
тоесть любая init система ))
Тут все деферамбы systemd сводятся к тому что оно уменьшило необходимость написания этих скриптов ( программ) и заменило эти программки на конфиг а претензии к тому, что там где раньше сидела программа которая нормально работала, под общую лавочку завезли что то, что зачастую не работает (ну или работает в n… количестве кейсов, но вариант не использовать systemd при этих кэйсах сделали весьма сложным)
Ну а ответ на ваш вопрос, любая. Они до systemd решали эти вопросы. И сейчас решают.
1 строка — хэш
2 строка — хэш от первой и от второй
и тд
вообще любой формат что бинарный, что не бинарный (по вашему определению)
это последовательность битов и байтов, они могут быть читаемы человеком или нет, но для компа роли никакой. Вопрос индексов (ну коль уж так надо) легко решается дом файлами, более того, я б сильно предпочел именно такое решение, как минимум это возможность индексирования постфактум, вначале накидали логов, потом индексировали. Более того, это давно работающее и стандартное решение, и целостность туда прикручивается с легкостью.
Но пока не вижу решения, вариант выделите явный источник логов в отдельный канал предварительным описанием конфигов явно не решение. Пока костыль, возможно даже поможет, если не дешевле мимо него обработать.
Собственно про journald выше упомянутый, который ну нифига не является достаточно производительным решением by design
Хотя в основном решение неплохое. ))
а их сильно больше, эт что за ....?
спасибо.