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

Было бы офигительно увидеть примеры - типа вот делал так с system v, а вот так теперь легко и просто делаю с systemd.

Ну, не знаю, насколько мои примеры интересны, но у нас получилось сделать следующее:

1. Гибкие системы зависимостей между сервисами и «типа-сервисами». Например, следующая штука: на одной инсталляции grpcwebproxy крутится на отдельном от основного grpc-сервиса хосте, а на другой — на том же. По условиям задачи его необходимо перезапускать, когда перезапускается основной сервис (ну, написан он так, внутрь ещё не лазили, не было времени). В случае systemd-шных unit’ов это решается добавками в /etc/systemd/system/grpcwebproxy.service.d/10-deps.conf, добавляющими нужные зависимости для данной конкретной инсталляции (в частности, PartOf). Туда же — единообразно описываемые зависимости на не-сервисные сущности типа маунтов и каталогов.

2. Объединение нескольких сервисов в таргеты.

3. Работа с cgroups и лимитами ресурсов для сервисов.

То есть, я не говорю, что это что-то прямо уникальное. Но от monit-а (с которыми были свои проблемы) удалось отказаться, конфигурация наших сервисов стала попроще. Она, правда, тут же усложнилась отказоустойчивостью и работой в кластере, но, кажется, там в принципе просто не бывает :-)

И в редакторе мне их нравилось больше смотреть, чем в консоли со странным управлением.

Ну, если у Вашего less-а странное управление — возьмите другой $PAGER :-)

В целом, про логи могу сказать только то, что journald работает. И логи за нужный промежуток времени можно посмотреть, указав даты. «Битые логи» (ну, физически битые) разгребать не приходилось, да, я думаю, на основном комплексе и не придется. Для сколько-нибудь серьезного комплекса все одно какой-нибудь logstash нужно ставить, и валить логи туда.

Было бы офигительно увидеть примеры - типа вот делал так с system v, а вот так теперь легко и просто делаю с systemd.

Ну, не знаю, насколько мои примеры интересны, но у нас получилось сделать следующее:

1. Гибкие системы зависимостей между сервисами и «типа-сервисами». Например, следующая штука: на одной инсталляции grpcwebproxy крутится на отдельном от основного grpc-сервиса хосте, а на другой — на том же. По условиям задачи его необходимо перезапускать, когда перезапускается основной сервис (ну, написан он так, внутрь ещё не лазили, не было времени). В случае systemd-шных unit’ов это решается добавками в /etc/systemd/system/grpcwebproxy.service.d/10-deps.conf, добавляющими нужные зависимости для данной конкретной инсталляции (в частности, PartOf). Туда же — единообразно описываемые зависимости на не-сервисные сущности типа маунтов и каталогов.

2. Объединение нескольких сервисов в таргеты.

3. Работа с cgroups и лимитами ресурсов для сервисов.

И в редакторе мне их нравилось больше смотреть, чем в консоли со странным управлением.

Ну, если у Вашего less-а странное управление — возьмите другой $PAGER :-)

В целом, про логи могу сказать только то, что journald работает. И логи за нужный промежуток времени можно посмотреть, указав даты. «Битые логи» (ну, физически битые) разгребать не приходилось, да, я думаю, на основном комплексе и не придется. Для сколько-нибудь серьезного комплекса все одно какой-нибудь logstash нужно ставить, и валить логи туда.