В современных дистрибутивах Linux почти везде вместо традиционных текстовых логов средствами syslog используются бинарные логи journald. Они также, как и текстовые логи, иногда разрастаются до больших размеров, так что необходимо заниматься чисткой. Вот об этом и будет заметка. На днях пришлось на одном сервере этим заняться, поэтому решил сразу оформить заметку. Написана она будет по мотивам Debian 11.

Смотрим, сколько логи занимают места:
# journalctl --disk-usage
Обычно они хранятся в директории /var/log/journal.

Настройки ротации логов могут быть заданы в файле /etc/systemd/journald.conf. Управляются они следующими параметрами:

[Journal]
SystemMaxUse=1024M
SystemMaxFileSize=50M

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

# systemctl restart systemd-journald.service

Так же вы можете обрезать логи в режиме реального времени. Примерно так:

# journalctl --vacuum-size=1024M
# journalctl --vacuum-time=7d

В первом случае обрезали старые логи, чтобы их осталось не больше 1024 мегабайт. Во втором обрезали все логи, старше 7-ми дней.

Кстати, если вы не хотите связываться с настройками journald, то можете команды выше просто в cron добавить на регулярное выполнение. Это тоже будет решение по ротации логов.

По умолчанию journald может занимать до 10% объёма раздела, на котором он находится. Но не более 4 Гб. На деле именно с ограничением в 4 Гб я чаще всего и сталкивался. Если у вас общий системный диск 40+ Гб, то как раз логи в 4 Гб у вас и будут.

Если у вас в логи спамит какая-то конкретная служба, то имеет смысл для неё отдельно настроить ограничение, выделив её логи в отдельный namespace. Для этого в unit службы в раздел [Service] добавьте отдельное пространство логов. Покажу на примере ssh. Запускаем редактирования юнита.
# systemctl edit ssh
Добавляем:
[Service]
LogNamespace=ssh

Создаём в директории /etc/systemd/ отдельный конфиг для этого namespace [email protected] со своими параметрами:

[Journal]
SystemMaxUse=20M

Перезапускаем службу:
# systemctl restart ssh

Смотрим его логи отдельно:
# journalctl --namespace ssh

Я, кстати, по старинке, всегда запускаю текстовые логи через syslog. Просто привык к ним. В итоге у меня и бинарные логи в journal, и текстовые в syslog. Примерно как с cron и timers. Через systemd больше функциональности и настройки гибче, но старые инструменты проще и быстрее в настройке.

#linux #logs #systemd #journal

ServerAdmin.ru

В современных дистрибутивах Linux почти везде вместо традиционных текстовых логов средствами syslog используются бинарные логи journald. Они также, как и текстовые логи, иногда разрастаются до больших размеров, так что необходимо заниматься чисткой. Вот об этом и будет заметка. На днях пришлось на одном сервере этим заняться, поэтому решил сразу оформить заметку. Написана она будет по мотивам Debian 11.

Смотрим, сколько логи занимают места:
# journalctl --disk-usage
Обычно они хранятся в директории /var/log/journal.

Настройки ротации логов могут быть заданы в файле /etc/systemd/journald.conf. Управляются они следующими параметрами:

[Journal]
SystemMaxUse=1024M
SystemMaxFileSize=50M

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

# systemctl restart systemd-journald.service

Так же вы можете обрезать логи в режиме реального времени. Примерно так:

# journalctl --vacuum-size=1024M
# journalctl --vacuum-time=7d

В первом случае обрезали старые логи, чтобы их осталось не больше 1024 мегабайт. Во втором обрезали все логи, старше 7-ми дней.

Кстати, если вы не хотите связываться с настройками journald, то можете команды выше просто в cron добавить на регулярное выполнение. Это тоже будет решение по ротации логов.

По умолчанию journald может занимать до 10% объёма раздела, на котором он находится. Но не более 4 Гб. На деле именно с ограничением в 4 Гб я чаще всего и сталкивался. Если у вас общий системный диск 40+ Гб, то как раз логи в 4 Гб у вас и будут.

Если у вас в логи спамит какая-то конкретная служба, то имеет смысл для неё отдельно настроить ограничение, выделив её логи в отдельный namespace. Для этого в unit службы в раздел [Service] добавьте отдельное пространство логов. Покажу на примере ssh. Запускаем редактирования юнита.
# systemctl edit ssh
Добавляем:
[Service]
LogNamespace=ssh

Создаём в директории /etc/systemd/ отдельный конфиг для этого namespace [email protected] со своими параметрами:

[Journal]
SystemMaxUse=20M

Перезапускаем службу:
# systemctl restart ssh

Смотрим его логи отдельно:
# journalctl --namespace ssh

Я, кстати, по старинке, всегда запускаю текстовые логи через syslog. Просто привык к ним. В итоге у меня и бинарные логи в journal, и текстовые в syslog. Примерно как с cron и timers. Через systemd больше функциональности и настройки гибче, но старые инструменты проще и быстрее в настройке.

#linux #logs #systemd #journal

👍129👎2

hottg.com/srv_admin/3133

9.96K viewsSep 25, 2023 at 06:11