Syslog и rsyslog

Модель syslog: facility × severity.

Каждое syslog-сообщение имеет два классификационных измерения:

# FACILITY — какая подсистема сгенерировала сообщение:
# kern      сообщения ядра
# user      сообщения уровня пользователя
# mail      почтовая подсистема
# daemon    системные демоны
# auth      безопасность/авторизация (authpriv — для чувствительных данных)
# syslog    сообщения самого syslogd
# cron      планировщик (cron и at)
# local0-7  зарезервировано для локального использования

# SEVERITY (0=критичнейший, 7=наименее важный):
# 0 emerg    система неработоспособна
# 1 alert    требуется немедленное действие
# 2 crit     критические условия
# 3 err      условия ошибки
# 4 warning  предупреждения
# 5 notice   нормальное, но значимое условие
# 6 info     информационные сообщения
# 7 debug    сообщения отладки

# В правилах rsyslog селектор: facility.severity:
# auth.err       → auth-сообщения на уровне err и выше
# *.warning      → все facility на уровне warning и выше
# kern.=debug    → только kernel debug (= означает точное совпадение)
# auth,authpriv.* → auth и authpriv на любой severity

Пара facility/severity кодируется как целое число в протоколе syslog. Ядро использует kern.emerg для паник; SSH использует auth.info для входов; cron использует cron.notice для завершения заданий.

Чтение правил маршрутизации rsyslog.conf.

/etc/rsyslog.conf и файлы в /etc/rsyslog.d/ содержат правила, которые сопоставляют селекторы и маршрутизируют их к действиям:

# Просмотреть основной конфиг:
cat /etc/rsyslog.conf

# Типичный блок маршрутизации Ubuntu/Debian:
# auth,authpriv.*          /var/log/auth.log
# *.*;auth,authpriv.none   -/var/log/syslog
# kern.*                   -/var/log/kern.log
# mail.*                   -/var/log/mail.log
# cron.*                   /var/log/cron.log

# Синтаксис: <селектор>  <действие>
# Селектор: facility.severity (несколько facility через запятую)
# Действие: /путь/к/файлу  (ведущий - = асинхронная запись, чуть быстрее)
#           @host:port     (UDP-пересылка)
#           @@host:port    (TCP-пересылка)
#           |/путь/пайп    (именованный пайп)

# Модификатор .none исключает facility:
# *.*;auth,authpriv.none  → все facility на всех severity
#                           КРОМЕ auth и authpriv

# Проверить, что rsyslog запущен:
systemctl status rsyslog

rsyslog обрабатывает правила сверху вниз. Сообщение может совпасть с несколькими правилами и быть записано в несколько мест. В отличие от iptables, неявного «стопа» нет — сообщение проходит через весь ruleset, если явно не использовать действие stop или модификатор отброса (~).

Пересылка логов на центральный коллектор.

Наиболее распространённое применение rsyslog помимо локальной маршрутизации — отправка логов на центральный syslog-сервер (Graylog, Loki rsyslog input, SIEM или другой rsyslog-экземпляр).

# Пересылать все логи на удалённый syslog-сервер по TCP:
# /etc/rsyslog.d/50-forward.conf
cat <<'EOF' | sudo tee /etc/rsyslog.d/50-forward.conf
# Загрузить модуль TCP-вывода:
module(load="omfwd")

# Пересылать всё на центральный коллектор 10.0.0.5:514 по TCP:
*.* action(type="omfwd"
           target="10.0.0.5"
           port="514"
           protocol="tcp"
           action.resumeRetryCount="-1"
           queue.type="linkedList"
           queue.size="10000"
           queue.filename="fwd-queue"
           queue.saveOnShutdown="on")
EOF

sudo systemctl restart rsyslog

# Проверить, что rsyslog загрузил конфиг без ошибок:
sudo rsyslogd -N1
# rsyslogd: version ..., config validation run ...
# rsyslogd: End of config validation run. Bye.

# Тест отправкой сообщения:
logger -p auth.info "тест с $(hostname)"
# На коллекторе должно появиться сообщение

Настройка queue.saveOnShutdown="on" сохраняет исходящую очередь на диск, чтобы сообщения не терялись при перезапуске rsyslog во время недоступности сети. action.resumeRetryCount="-1" повторяет попытки бесконечно вместо отброса сообщений после N неудач.

Пересылка journald в syslog через imjournal.

На современных Ubuntu/Debian journald является основным коллектором логов. rsyslog читает из журнала через входной модуль imjournal, переводя структурированные записи журнала в классический syslog-пайплайн.

# Модуль imjournal обычно уже включён в /etc/rsyslog.conf:
grep -A5 'imjournal' /etc/rsyslog.conf
# module(load="imjournal"
#        StateFile="/var/spool/rsyslog/imjournal.state"
#        RateLimit.Interval="600"
#        RateLimit.Burst="20000"
#        IgnorePreviousMessages="off")

# Это означает:
# - rsyslog читает новые записи журнала по мере поступления
# - StateFile отслеживает позицию (перезапуск не отправляет старые сообщения повторно)
# - RateLimit предотвращает перегрузку rsyslog при шторме логов

# Альтернатива — ForwardToSyslog в journald.conf — устарела:
# НЕ используй ForwardToSyslog=yes (создаёт Unix-сокет, который читает rsyslog;
# менее надёжно, чем imjournal, и не рекомендуется в новых версиях systemd)

# Убедиться, что сообщения текут journal → rsyslog:
logger "test-syslog-routing"
grep "test-syslog-routing" /var/log/syslog

Ключевое понимание: на современном сервере обычно нужно только настроить место назначения для пересылки rsyslog. Мост journald → rsyslog (imjournal) уже настроен. Ты не заменяешь journald на rsyslog — ты используешь rsyslog как агент пересылки данных журнала.

Использование logger для тестовых сообщений и проверки маршрутизации.

logger — утилита командной строки для отправки в syslog. Она отправляет сообщение с любым facility и severity — незаменима для тестирования правил маршрутизации без реальных событий.

# Отправить сообщение на auth.info:
logger -p auth.info "попытка входа с 203.0.113.42"

# Отправить сообщение на daemon.err:
logger -p daemon.err "пул подключений исчерпан"

# Отправить с пользовательским тегом (отображается как имя программы в логе):
logger -t myapp -p local0.warning "лимит запросов для пользователя 9812"

# Проверить маршрутизацию:
grep "попытка входа" /var/log/auth.log       # должно быть здесь
grep "пул подключений" /var/log/syslog        # должно быть здесь
grep "лимит запросов" /var/log/syslog         # local0 → syslog по умолчанию

# Отправить на удалённый rsyslog (для сквозного теста):
logger --server 10.0.0.5 --port 514 -p daemon.warning "удалённое тестовое сообщение"

logger незаменим при проверке нового правила rsyslog перед вводом в эксплуатацию: создать правило, перезапустить rsyslog, отправить тест через logger, убедиться, что он появился в нужном месте.