Вопрос или проблема
У меня есть служба, настроенная на CentOS 7, которая выводит много сообщений в журнал, что приводит к следующему в системном журнале / журнале: systemd-journal[xxxx]: Suppressed 864 messages from /system.slice/example.service
.
Тем не менее, я хочу видеть все сообщения службы для целей отладки и диагностики. Кроме того, я хочу отключить ограничение частоты, так как это просто тестовый сервер.
Я установил RateLimitInterval=0
и RateLimitBurst=0
в /etc/systemd/journald.conf, но systemd-journal, похоже, не подчиняется этой настройке. Команда systemctl restart systemd-journald
или перезагрузка системы не помогли.
Есть ли предложения по диагностике этого? Существует ли команда, чтобы показать, какую конфигурацию в данный момент использует systemd-journald?
Поскольку syslog не был предназначен для обработки очень больших сообщений, а также непрерывного потока сообщений, вам следует рассмотреть возможность записи в простой текстовый файл вместо использования услуг syslog.
Это особенно верно, если “сообщения” являются сообщениями типа отладки.
Также “ограничение частоты” может означать две разные вещи:
- Количество сообщений, которые вы хотите выводить
- Количество сообщений, которые вы можете выводить
В руководстве по journald.conf объясняется:
Если в временном интервале, определенном
RateLimitIntervalSec=
, записывается больше сообщений, чем указано вRateLimitBurst=
, все последующие сообщения в течение интервала отбрасываются до его окончания.
Так что, очевидно, вы хотите установить RateLimitIntervalSec
довольно маленьким (например, 1 секунда), а RateLimitBurst
довольно большим (например, несколько миллионов, при условии, что система может обработать сообщение syslog за менее чем одну микросекунду).
Ответ или решение
Обратимся к вашей проблеме с ограничением частоты сообщений в systemd-journald на CentOS 7.
Как вы уже отметили, при больших объемах логируемых сообщений от вашей службы, systemd-journald подавляет избыточные сообщения, чтобы не перегружать систему. Если вы хотите увидеть все сообщения, вы можете настроить параметры RateLimitIntervalSec
и RateLimitBurst
в файле конфигурации /etc/systemd/journald.conf
.
Настройка конфигурации
-
Откройте файл конфигурации
journald.conf
в текстовом редакторе. Например, используяvi
илиnano
:sudo vi /etc/systemd/journald.conf
-
Вам нужно установить параметры
RateLimitIntervalSec
иRateLimitBurst
. Ваша конфигурация может выглядеть следующим образом:[Journal] RateLimitIntervalSec=1s RateLimitBurst=1000000
Параметр
RateLimitIntervalSec
определяет интервал времени, в течение которого измеряется количество сообщений, аRateLimitBurst
– максимальное количество разрешенных сообщений в этом интервале. УстановивRateLimitBurst
на максимально возможное значение, вы сможете зафиксировать все сообщения. -
После внесения изменений сохраните файл и выйдите из редактора.
Применение изменений
- Перезапустите службу systemd-journald, чтобы новые настройки вступили в силу:
sudo systemctl restart systemd-journald
Проверка текущих настроек
Чтобы убедиться, что новые настройки применились, используйте следующую команду:
sudo journalctl --catalog --no-pager | grep RateLimit
Однако, следует учитывать, что такая команда может не показать напрямую примененные параметры конфигурации.
Если вы хотите проверить настройки в файле конфигурации, выполните команду:
sudo systemctl show --property=RateLimitIntervalSec --property=RateLimitBurst systemd-journald
Альтернативные подходы
Если после изменений сообщения по-прежнему подавляются, можно рассмотреть возможность изменения подхода к логированию. Например, вместо записи в журнал systemd, вы можете перенаправить вывод вашей службы в файл. Для этого вы можете использовать опцию StandardOutput
и StandardError
в сервисном файле вашей службы:
[Service]
StandardOutput=append:/var/log/example_service.log
StandardError=append:/var/log/example_service.log
Это позволит вам сохранять все лог-сообщения в указанный файл без каких-либо ограничений.
Итог
Следуя приведённым выше шагам, вы должны сможете отключить подавление сообщений в systemd-journald и получить доступ ко всем вашим логам. Однако не забывайте о том, что даже при тестировании большого объема сообщений в журнале может значительно повлиять на производительность системы, поэтому рекомендуем рассмотреть использование текстовых файлов для логирования в рабочей среде.