Оглавление

• Назначение Rsyslog
• Процесс логирования в Linux
• Как настроить Rsyslog в Linux
• Правила обработки логов
• Удаленное логирование с помощью Rsyslog
• Заключение

Назначение Rsyslog

В операционной системе Linux, как правило, ведется логирование всех событий и процессов, а также ошибок. Вся эта информация собирается в лог-файлах, иногда ее накапливается так много, что эти файлы могут быть чрезмерно большими, такие логи становятся источниками новых ошибок и сбоев системы. Поэтому возникает необходимость управлять лог-файлами и процессом логирования.

В системах на базе Unix, еще с 80-х годов 20-го века за управление лог-файлами отвечал сервис Syslog. В современных версиях Linux вместо Syslog используется утилита Rsyslog, которая была разработана в 2004 году на базе форка Syslog.

Rsyslog — это мощный сервис для управления логами в Linux, который позволяет осуществлять фильтрацию контента логов, передавать логи по сети, может вести обработку сообщений со скоростью до миллиона операций в секунду.

Rsyslog поддерживает следующие протоколы: TLS, RELP, TCP, SSL. Сервис Rsyslog совместим с СУБД MySQL, Oracle, PostgreSQL, поддерживает многопоточность, функцию фильтрации журналов и может настраивать формат вывода.

«По умолчанию», пакет Rsyslog доступен в базовом дистрибутиве Linux (например, в серверной ОС Ubuntu 20.04).

Процесс логирования в Linux

Логи программ в Linux расположены в директории /var/log/, программы просто записывают свое состояние или накапливаемые ошибки в лог-файлы. Директорию /var/log/
можно посмотреть с помощью команды:

ls -l /var/log/

Большое значение имеет детализация логирования данных, можно настроить различные уровни детализации, например, в самом лог-файле программы или с помощью сервиса Rsyslog. Здесь необходимо соблюдать баланс между детализацией информации в лог-файле и объемом свободного дискового пространства.

На примере ядра ОС Linux посмотрим степень детализации сообщений в лог-файле. К примеру, KERN_EMERG означает, что система неработоспособна, а KERN_ERR — обычная ошибка, в то же время, KERN_CRIT — это уже критическая ошибка, KERN_WARNING — предупреждение. А вот kern.* будет соответствовать всем сообщениям, создаваемым ядром. Ниже приведем таблицу со стандартными уровнями приоритетов и описанием их значений:

emerg	неработоспособность системы
alert	необходимо срочно принять меры
crit	критическая ошибка
err	обычная ошибка
warning	предупреждение
notice	замечание
info	информационное сообщение
debug	сообщения отладки

В следующей таблице покажем объекты (источники), которые могут создавать лог-файлы в системе.

auth/authpriv	сообщения по безопасности/авторизации
cron	сообщения демонов crond и atd
daemon	другие системные демоны
kern	сообщения ядра ОС
local0 – local7	зарезервировано для локального использования
lpr	подсистема принтера
mail	подсистема электронной почты
news	подсистема новостей USENET
syslog	cообщения, генерируемые Syslog
user	сообщения, генерируемые на уровне пользователя
uucp	подсистема UUCP

Как настроить Rsyslog в Linux

Все работы будем проводить на примере серверной ОС Ubuntu 20.04. Приступим непосредственно к настройкам Rsyslog, для начала посмотрим директорию /etc/rsyslog.d/, какие конфигурационные файлы там находятся:

ls /etc/rsys*

Главный конфигурационный файл — это /etc/rsyslog.conf, для вывода на экран его содержимого используем команду cat:

cat /etc/rsyslog.conf

Как мы видим, с помощью директивы IncludeConfig /etc/rsyslog.d/*.conf к этому основному файлу подключаются все файлы из папки /etc/rsyslog.d/. Эта директива располагается в самом начале файла /etc/rsyslog.conf.

Из примера файла на скриншоте выше видно, что здесь собраны основные настройки, с помощью которых можно работать с локальными файлами логов. Для получения информации из логов по сети, необходимо добавить (или раскомментировать) некоторые дополнительные сетевые настройки.

Синтаксис любой директивы имеет следующий вид:

$ переменная значение

В начале файла размещены общие директивы по настройке программ и загрузке модулей, во второй части файла можно добавить собственные настройки. Ниже дадим пример общих директив:

$ModLoad imklog # provides kernel logging support
# provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514
# provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514

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

1. модули ввода — начинаются с im, применяются для сбора информации из различных источников;
2. модули вывода — начинаются с om, служат для передачи информации по сети или в базу данных;
3. модули фильтрации — начинаются с fm, предназначены для фильтрации данных по различным параметрам;
4. модули парсинга — начинаются с pm, необходимы для расширенного синтаксического анализа сообщения.

Приведем более конкретные примеры по описанию модулей. Например, можно уточнить модуль ввода или вывода, с помощью информации: откуда или куда мы будем вводить или выводить данные. Ниже примеры по модулю вывода:

omfile — вывод в файл;

omfwd — пересылка по сети, через udp или tcp;

onmysql, ompgsql, omoracle — запись в базу;

omelasticsearch — запись в ElasticSearch.

Приведем еще примеры по модулям:

imuxsock — отвечает за получение информации из сокетов;

imklog — собирает сообщения ядра;

mark — служит для маркировки соединения, можно настроить rsyslog для выдачи сообщений о том, что syslog все еще работает, с периодом каждые 10 мин:

$ MarkMessagePeriod 600

После описания работы модулей в файле rsyslog.conf описываются глобальные директивы, например, для описания формата представления времени в секундах:

$ ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

Затем устанавливаются разрешения для файлов журналов, которые ведутся в системе. Права можно выставить такие, как вам нужно:

$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022

Далее расскажем про правила сортировки логов.

Правила обработки логов

Ниже приведем пример правил, которые прописаны в файле rsyslog.conf «по умолчанию»:

auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none    -/var/log/syslog
cron.*                               /var/log/cron.log
daemon.*                         -/var/log/daemon.log
kern.*                              -/var/log/kern.log
lpr.*                                -/var/log/lpr.log
mail.*                             -/var/log/mail.log
user.*                            -/var/log/user.log

Синтаксис правил имеет следующий вид:

источник.приоритет действие

Примечание: Две таблицы с источниками и приоритетами мы привели выше, в предыдущих разделах статьи.

Если вместо «приоритета» стоит знак «*», то это означает, что логировать нужно все приоритеты, если, к примеру, указано *.info — то логируются все источники, если *.* — обрабатываются все источники со всеми приоритетами. А вот если указано, например, mail.none, то это означает запрет на логирование любых уровней сообщений.

Правила логирования могут быть и более сложными, кроме «источника» и «приоритета» можно использовать более сложные конструкции: сравнения и условия.

Синтаксис такого правила выглядит следующим образом:

:поле, сравнение, "значение" путь_к_файлу

В качестве «сравнения» могут выступать следующие параметры:

• contains — указанное значение содержится в поле;
• isequal — поле идентично значению;
• startswith — поле начинается со значения;
• regex — служит для сравнения поля с регулярным выражением.

Также может быть использован синтаксис на основе условия «if»:

if $поле сравнение 'значение' then файл

Приведем практические примеры использования некоторых правил.

1) Покажем, как записать все сообщения категорий auth и authpriv в файл /var/log/auth.log, а затем продолжить их обработку:

 # legacy
auth,authpriv.*  /var/log/auth.log
# новый формат
if ( $syslogfacility-text == "auth" or $syslogfacility-text == "authpriv" ) then {
    action(type="omfile" file="/var/log/auth.log")
}

 2) Простой шаблон правила, который дает наиболее полную информацию о сообщении:

$template precise,”%syslogpriority%,%syslogfacility%,%timegenerated%,%HOSTNAME%, %syslogtag%,%msg%\n”

3) Шаблон, который можно использовать для записи в базу данных:

$template MySQLInsert,”insert iut, message, received at values (‘%iut%’, ‘%msg:::UPPERCASE%’, ‘%timegenerated:::date-mysql%’) into systemevents\r\n”, SQL

4) Пример фильтрации сообщений в конкретный лог только от программы WireGuard:

if $syslogtag == 'wireguard' then /var/log/wireguard.log

Или:

:syslogtag, isequal, "wireguard:" /var/log/wireguard.log
& stop

Удаленное логирование с помощью Rsyslog

Очень часто системному администратору необходимо решить задачу сбора логов по сети, ведь это достаточно удобно — собирать все лог-файлы с рабочих машин на один сервер и там их хранить. Надо отметить, что Rsyslog — это клиент-серверное решение, которое работает по сети через 514 порт по протоколам TCP/UDP.

Далее приведем простые директивы для отправки лога на удаленный компьютер:

*.info;mail.none;authpriv.none;cron.none @xx.xx.xx.xx:514

где 514 — это порт, на котором слушает rsyslog, xx.xx.xx.xx — IP удаленного компьютера.

Для приема логов на сервере необходимо прописать следующую команду:

if $fromhost-ip contains '192.168.1.10' then /var/log/proxyserver.log

Отметим, что еще нужно прописать правила фильтрации логов, иначе вся информация будет передаваться в один общий лог-файл системы Linux.

Опишем кратко, как настроить Rsyslog, как на сервере, так и на клиентских машинах.

Если по какой-то причине Rsyslog у вас не установлен, то инсталлировать серверный пакет Rsyslog можно следующей командой:

sudo apt install rsyslog

Затем необходимо запустить и включить службу Rsyslog на сервере:

sudo systemctl start rsyslog
sudo systemctl enable rsyslog
sudo systemctl status rsyslog

Затем на сервере нужно открыть и отредактировать следующим образом файл:

nano /etc/rsyslog.conf

Для настройки сбора логов на сервере, необходимо раскомментировать следующие строки файла:

# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")

# provides TCP syslog reception
module(load="imtcp")
input(type="imtcp" port="514")

Далее нужно прописать шаблон для хранения входящих журналов от клиентских компьютеров:

$template remote-incoming-logs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?remote-incoming-logs

Для того, чтобы изменения вступили в силу, после сохранения файла, перезапустите службу:

sudo systemctl restart rsyslog

В случае, если у вас запущен брандмауэр, то необходимо разрешить работу Rsyslog:

ufw allow 514/tcp
ufw allow 514/udp
ufw reload

На каждой клиентской машине, нужно отредактировать конфигурационный файл следующим образом:

nano /etc/rsyslog.conf

Добавим следующие строки:

#Enable sending system logs over UDP to rsyslog server
*.* @rsyslog-server-ip:514

#Enable sending system logs over TCP to rsyslog server
*.* @@rsyslog-server-ip:514

##Set disk queue when rsyslog server will be down:

$ActionQueueFileName queue
$ActionQueueMaxDiskSpace 1g
$ActionQueueSaveOnShutdown on
$ActionQueueType LinkedList
$ActionResumeRetryCount -1

Далее на клиентских компьютерах нужно перезапустить Rsyslog:

sudo systemctl restart rsyslog

После проведения данных настроек, все лог-файлы будут находиться на сервере, посмотреть эти записи (с именами хостов ваших машин-клиентов) можно в каталоге:

ls -l /var/log/

Заключение

В этой статье мы раскрыли достаточно полезную тему для системного администратора — сбор лог-файлов с помощью утилиты Rsyslog. Данный материал поможет специалисту наладить логирование, как на локальной машине, так и по сети, встроенными средствами Linux.

Однако, использование командной строки в Rsyslog — не всегда удобное и доступное решение. Для работы с большими массивами лог-файлов необходимо их как-то визуализировать и грамотно обрабатывать. Подобные решения с открытым исходным кодом существуют, это стек ELK от Elasticsearch, а также Logstash и Kibana. В следующей статье мы постараемся рассказать про работу с ними.

Если же у вас возникают проблемы с настройкой логирования в Linux, то вы всегда можете обратиться за консультацией к системным администраторам компании FREEhost.UA.

Подписывайтесь на наш телеграмм - канал t.me/freehostua, чтобы быть в курсе новых полезных материалов. Смотрите наш Youtube канал на youtube.com/freehostua.

Дата: 27.01.2022 Автор: Евгений

Голосування 1 2 3 4 5