Назад | Перейти на главную страницу

graylog не получает сообщения системного журнала cents 7.1 с помощью службы rsyslogd

Доброе утро! Сегодня я играю с Graylog, и на Ubuntu все работает хорошо, но два сервера CentOS 7.1, которые я попытался подключить к нему, ведут себя странно. Я делал заметки по ходу дела и приклеил их ниже. Спасибо, что нашли время прочитать это!

При перенаправлении в rsyslog журналы записываются в файлы удаленного / var / log. При перенаправлении в Graylog служба не отправляет журналы, но если rsyslog запускается sudo rsyslogd вместо службы syslog он будет работать

Вот результат ps aux | grep sysl для каждого процесса: Из службы:

[пользователь] $ ps aux | grep sysl

корень 12362 0,0 0,1 311228 2804? SSL 10:19 0:00 / usr / sbin / rsyslogd -n

пользователь + 12369 0,0 0,0 112640 928 точек / 0 S + 10:19 0:00 grep --color = auto sysl

Из sudo rsyslogd:

[пользователь] $ ps aux | grep sysl

корень 12320 0,0 0,1 313300 2336? SSL 10:18 0:00 rsyslogd

пользователь + 12354 0,0 0,0 112640 932 точек / 0 S + 10:18 0:00 grep --color = auto sysl

Приложение должно быть таким, как указано здесь:

[пользователь] $ который rsyslogd

/ usr / sbin / rsyslogd

Единственная разница заключается в использовании -n флаг.

Содержимое служебного файла rsyslog systemd:

[Ед. изм]

Описание = Служба системного журнала

; Требуется = syslog.socket

[Обслуживание]

Тип = уведомить

EnvironmentFile = - / etc / sysconfig / rsyslog

ExecStart = / usr / sbin / rsyslogd -n $ SYSLOGD_OPTIONS

StandardOutput = null

[Установить]

WantedBy = multi-user.target

; Псевдоним = syslog.service

$ SYSLOGD_OPTIONS "" соответствует / etc / sysconfig / rsyslog

Бег sudo /usr/sbin/rsyslogd -n отправляет сообщения, но блокирует сеанс терминала (CTRL-C не выйдет, придется закрыть панель tmux и повторно подключиться, но rsyslogd останется работать)

Удаление -n $SYSLOGD_OPTIONS из службы приведет к тому, что служба не запустится (происходит сбой, я запускал sudo systemctl daemon-reload)

Я понял. Я был тупым. SELinux не позволяет syslog отправлять журналы через нестандартный порт, что я и пытался сделать. Установка policycoreutils-python и бег sudo semanage port -a -t syslogd_port_t -p tcp 5514 починил это :)