Найти в Дзене

Тонкая настройка systemd-journald

Классическая ситуация – все место на диске занято логами, либо логи создают излишнюю нагрузку на систему ввода вывода. Чтобы этого не случилось – логирование нужно настроить в соответствии с реальными потребностями и сегодня мы посмотрим, как это сделать для systemd-journald. Прежде всего посмотрим текущие настройки, это можно сделать командой: cat /etc/systemd/journald.conf По умолчанию все значение в нем закомментированы и представляют настройки службы по умолчанию. Для изменения вы можете использовать данный файл, но официально рекомендуется использовать технологию "drop-ins" и хранить настройки в отдельных файлах. Создадим для этого директорию: mkdir -p /etc/systemd/journald.conf.d А в нем один или несколько файлов с изменениями конфигурации, в нашем случае это будет 00-journal.conf куда мы будем вносить изменившиеся опции. Начнем с места хранения логов. Для сохранения на диск используйте: Storage=persistent Это более надежно, чем auto, которое может иногда приводить к с

Тонкая настройка systemd-journald

Классическая ситуация – все место на диске занято логами, либо логи создают излишнюю нагрузку на систему ввода вывода.

Чтобы этого не случилось – логирование нужно настроить в соответствии с реальными потребностями и сегодня мы посмотрим, как это сделать для systemd-journald.

Прежде всего посмотрим текущие настройки, это можно сделать командой:

cat /etc/systemd/journald.conf

По умолчанию все значение в нем закомментированы и представляют настройки службы по умолчанию. Для изменения вы можете использовать данный файл, но официально рекомендуется использовать технологию "drop-ins" и хранить настройки в отдельных файлах.

Создадим для этого директорию:

mkdir -p /etc/systemd/journald.conf.d

А в нем один или несколько файлов с изменениями конфигурации, в нашем случае это будет 00-journal.conf куда мы будем вносить изменившиеся опции.

Начнем с места хранения логов. Для сохранения на диск используйте:

Storage=persistent

Это более надежно, чем auto, которое может иногда приводить к сюрпризам. Если же вам не нужна запись логов на диск, но вы хотите иметь их для диагностики и отладки используйте хранение в оперативной памяти. Такой метод рекомендуется для виртуальных машин и контейнеров, а также встраиваемых устройств и мини-ПК.

Storage=volatile

Затем проверьте опции:

Compress=yes

Seal=yes

Первая из них включает сжатие логов, вторая – криптографическую защиту, обычно обе включены по умолчанию.

Хранить логи – это хорошо, но не ограничивать размер – очень плохо, поэтому сразу озаботимся этим:

SystemMaxUse=1G

SystemKeepFree=2G

Первая опция задает максимальный размер хранилища логов, а второй нижний предел свободного места. Таким образом мы будем хранить не более одного гигабайта логов, но при условии, что в системе остается не менее 2 ГБ свободного места.

Если вы храните данные в ОЗУ, то используйте следующие опции аналогичного назначения:

RuntimeMaxUse=64M

RuntimeKeepFree=256M

Опции

SystemMaxFileSize=

SystemMaxFiles=100

Задают максимальный размер одного файла журнала и их общее количество, по умолчанию systemd-journald создает файлы размером 8 МБ.

Для хранения в оперативной памяти аналогичные опции:

RuntimeMaxFileSize=

RuntimeMaxFiles=100

Следующие важные настройки – это уровни логирования, в продуктивных средах нет необходимости хранить логи уровня debug, будет вполне достаточно info или notice. Поэтому замените debug на более низкий уровень логирования в этих трех опциях:

MaxLevelStore=debug

MaxLevelSyslog=debug

MaxLevelSocket=debug

Данный набор опций отвечает за пересылку логов в syslog, kernel buffer, консоль и отправку сообщения пользователям.

ForwardToSyslog=no

ForwardToKMsg=no

ForwardToConsole=no

ForwardToWall=yes

Настройки по умолчанию (указаны выше) оптимальны и без необходимости пересылку включать не следует. Единственная включенная пересылка – это отправка пользователям сообщений уровня emerg (катастрофический сбой).

Еще одна важная опция – это лимиты, позволяющие избегать засорения логов однотипными сообщениями. По умолчанию имеет следующие значения:

RateLimitIntervalSec=30s

RateLimitBurst=10000

Это означает, что в течении 30 секунд можно отправить в лог не более 10 000 сообщений. Обратите внимание, что данный лимит действует для каждого источника событий, а не для всей системы.

В высоконагруженных системах лимит можно повысить, например, для гипервизоров, где виртуалки при старте могут быть достаточно «разговорчивы». В виртуальных средах, наоборот, имеет смысл понизить этот лимит, чтобы избежать массового спама логов сбойным сервисом.