Галимые упражнения с systemd-journald
Вот здесь я писал про отмороженного заказчика, который ни в зуб ногой в IT, но при этом хочет чтобы всё было круто и "бизапасно". При ближайшем рассмотрении виртуалок, которые он предоставил, выяснилось прекрасное. Они там непонятно зачем настроили сервис audit (когда ядро сообщает обо всех системных вызовах) в максимально говорливый режим (INFO), а userspace-обвязку прописали по каким-то тухлым методичкам, которым сто лет в обед.
В итоге каждое (!) такое сообщение (системный вызов) от ядра пишется в пять разных мест: два раза в systemd-journald (от имени демона auditd и напрямую туда же через unix-сокет), два раза в "/var/log/syslog" через rsyslog, и один раз в кастомную папку в отдельный текстовый файл. (*facepalm*) Вся эта мутотень генерирует примерно по гигабайту (!) логов в сутки даже в режиме, когда система ничем не нагружена. Но отключать эту всю по***ту не могу, эти "бизапасники" взъерепенятся. Мне вот искренне интересно, они всерьёз собираются все эти гигабайты своими глазами читать?
Ну ладно, так-то это всё это меня не касается. Но есть два неприятных момента во всей этой истории.
- Оно забивает свободное место на корневом разделе диска. И нужно за этим постоянно следить, чтобы приложение не ровен час не встало. А мне лишние телодвижения на ровном месте как-то нафиг не упёрлись.
- В потоке всего этого поноса становится достаточно проблематично выцеплять действительно нужные сообщения об ошибках. Да и journalctl начинает ощутимо подтормаживать на таких объемах логов.
Первый шаг самый очевидный: создать отдельный раздел для логов и выкинуть весь "/var/log" на него. Сделано. Но остается ещё второй пункт. И вот тут я узнал, что у journald тоже существуют namespaces.
Копируем файл "/etc/systemd/journald.conf" во что-нибудь типа "/etc/systemd/journald@noise.conf". И пишем внутри что-то типа такого.
journald.conf:
[Journal]
SystemMaxUse=4G
Storage=persistent
ReadKMsg=no
journald@noise.conf:
[Journal]
RuntimeMaxUse=20M
Storage=volatile
ReadKMsg=no
ForwardToKMsg=no
"Нормальный" journald ограничиваем 4мя гигабайтами файлового (persistent) хранилища. "Шумный" namespace помещаем в оперативную память (volatile) и просим занимать собой не более 20ти мегабайт. Затем отключаем audit-сокет и перенаправляем выхлоп auditd в другой namespace.
systemctl stop systemd-journald-audit.socket
systemctl disable systemd-journald-audit.socket
systemctl mask systemd-journald-audit.socket
systemctl edit auditd.service
[Unit]
After=
After=local-fs.target systemd-tmpfiles-setup.service systemd-journald@noise.service
[Service]
LogNamespace=noise
Дальше, как водится, перезапустить одно-другое-третье. И цель достигнута. Сообщения от ядра попадают в единственном экземпляре через auditd в "шумный" namespace, где особо не задерживаются. Откуда их забирает настроенный "бизапасниками" rsyslogd и складывает куда-то в текстовые файлы, попутно отсылая всё это на какой-то ещё сервер по сети. А у меня есть логи безо всей этой ненужной мути.
Есть, конечно, ложки дёгтя во всех этих бочках, с которыми я не очень разобрался.
Во-первых, нельзя иметь несколько persistent-хранилищ для journald в разных местах файловой системы / на разных разделах. Это, к сожалению, by design. В моём случае это не страшно, но в целом неприятно. Технически данное ограничение при очень большом желании можно обойти symlink-ами, но при этом возникает охапка других вопросов, связанная с race conditions при монтировании разных файловых систем.
Во-вторых конкретно у меня разные journald namespaces почему-то дерутся за "/dev/kmsg" несмотря на то, что я его явно отключил. То ли баг какой в journald, то ли ещё что-то, не пойму.
В-третьих, по мере заполнения хранилища journald автоматически перезапускается. Не знаю, штатное ли это поведение, или это я где-то накосячил. Но в моем случае journald@noise перезапускается каждую минуту-две. Не смертельно, но как минимум выглядит странно.
Если у кого-то есть идеи как решить мою изначальную задачу проще, милости прошу в комменты.