Логи в Linux часть 2. Модули и сервер логов

В первой части статьи "Логи в Linux часть 1. rsyslog, journald и logrotate" вы узнали об основах управления и анализа лог-файлов. Во второй части вы узнаете как работать с модулями в rsyslogd. Вы также узнаете, как организована интеграция между rsyslogd и journald и как настроить центральный сервер.

Модули rsyslogd

В первой части вы узнали, как настраивать правила в rsyslogd, который позволяет отправлять сообщения определенным адресатам на основе ранее настроенных объектов и приоритетов. В этом разделе вы узнаете о другой функции, которая используется в rsyslogd: modules. Модули делают rsyslogd расширяемым и позволяют включать функции, которые не включены по умолчанию.

В rsyslogd могут использоваться разные типы модулей:

Модули ввода: это модули, названия которых начинаются с im. Модули ввода используются для указания, откуда rsyslogd будет получать сообщения.

Модули вывода: это модули, имена которых начинаются с om. По умолчанию сообщения лога отправляются адресатам, как указано в /etc/rsyslog.conf. С помощью модулей вывода сообщения можно отправлять в другое место, например, в базу данных или в журнал.

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

Зачем нужны модули?

Оригинальный syslog был разработан давно, когда системы UNIX использовались в ограниченных целях, а количество сервисов было намного меньше, чем сегодня.

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

Два наиболее важных типа модулей - это модули ввода и вывода. Модуль ввода позволяет получать от сервисов то, что не включено в первоначальный список объектов. Модули ввода, например, используются для того, чтобы rsyslogd мог получать сообщения из journald или из текстовых файлов, генерируемых сервисами, которые не могут напрямую логироваться в rsyslogd.

Модули вывода используются для добавления назначения по умолчанию. В исходном проекте количество мест назначения, которые можно было использовать, было ограничено, и, например, запись в базу данных не поддерживалась. Чтобы разрешить нестандартным логам другие места назначения с помощью rsyslogd, можно использовать модули вывода. Примером полезного модуля вывода является модуль базы данных mysql, который позволяет записывать сообщения непосредственно в базу данных. Другим примером модуля вывода является usrmsg, который позволяет syslog'у писать сообщения пользователям.

Использование модулей в rsyslog

Давайте рассмотрим пример, где модуль imfile (файл входного модуля) используется для мониторинга входного файла и записи новых событий в rsyslogd (Листинг 1).

Листинг 1
$ModLoad imfile
$InputFileName /var/log/httpd/access_log
$InputFileTag apache-access:
$InputFileStateFile state-apache-access
$InputRunFileMonitor
$InputFileFacility local1
$InputFileSeverity info
$InputFilePollInterval 30

В листинге 1 используются несколько параметров. В таблице 1 показан обзор этих параметров и их использование.

Таблица 1

Модуль

Для чего используется

 InputFileName

Имя файла, который отслеживает модуль.

 InputFileTag

Тег, который используется при записи логов.

 InputFileStateFile

Имя файла, который rsyslog использует для внутреннего отслеживания изменений.

 InputRunFileMonitor

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

 InputFileFacility

Название объекта rsyslog, который будет использоваться в этом модуле.

 InputFileSeverity

Приоритет (тип сообщения), который будет использоваться при логировании.

 InputFilePollInterval

Интервал, который следует использовать для опроса входного файла.

Другим распространенным модулем, который часто используется с rsyslog, является модуль ommysql, модуль вывода, который позволяет записывать сообщения в MySQL или MariaDB. Файл createDB.sql (который по умолчанию устанавливается в каталог /usr/share/doc/rsyslog) обеспечивает доступность всех необходимых настроек в базе данных mysql.

Поскольку вы являетесь администратором rsyslog, вам нужно только настроить модуль вывода в rsyslog. Это будет выглядеть следующим образом.
$ModLoad ommysql
*.* :ommysql:myservername,rsyslog,dbuser,password

Как видите, для отправки сообщений в MySQL много не надо. Вам просто нужно загрузить модуль вывода ommysql и добавить строку, которая отправляет все сообщения со всеми приоритетами в модуль ommysql, который настроен во второй строке. При этом необходимо указать разные параметры, как вы можете видеть во второй строке:
  • Имя сервера базы данных.
  • Название базы данных.
  • Имя пользователя, используемое для подключения к базе данных.
  • Пароль, используемый этим пользователем.
Убедитесь, что вы установили соответствующего владельца и разрешения для файла конфигурации; в противном случае все желающие смогут прочитать имя пользователя и пароль базы данных!

Подключение journald к rsyslog

По умолчанию journal отправляет сообщения в rsyslogd. В этом разделе вы узнаете, как настроено это соединение, что позволит вам дополнительно настроить его в соответствии с вашими потребностями.

Journald отправляет сообщения в rsyslog по умолчанию. Об этом заботятся две части конфигурации. Во-первых, файл /etc/systemd/journald.conf содержит строку ForwardToSyslog, которая по умолчанию имеет значение yes. В листинге 2 показано содержимое этого файла. Во-вторых rsyslog.conf содержит конфигурацию, необходимую для получения сообщений из journald.

Листинг 2
[root@kvm ~]# cat /etc/systemd/journald.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See journald.conf(5) for details.

[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitInterval=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
#MaxLevelWall=emerg
#LineMax=48K

Первое решение для получения сообщений из journal было через модуль imuxsock. Этот модуль обеспечивает прием сообщений через сокеты UNIX, которые являются прямыми соединениями между процессами Linux с использованием файловых дескрипторов. Этот метод теперь устарел и заменен модулем imjournal, который был специально разработан для интеграции rsyslogd и journald. В rsyslog.conf для правильной обработки приема журнала необходимы две строки:

$OmitLocalLogging on
$IMJournalStateFile imjournal.state

Первая отключает прием логов через модуль imuxsocks. Вторая строка определяет имя файла состояния, который rsyslogd использует для отслеживания состояния синхронизации между rsyslogd и journald.

Настройка удаленного логирования

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

Зачем нужен удаленный сервер логов?

Имеет смысл использовать центральный сервер логов по нескольким причинам:
  • Сообщения, хранящиеся на удаленном сервере, не могут быть доступны злоумышленникам, если конечно они не проникли на удаленный сервер.
  • На удаленном сервере можно выделить больше места для хранения сообщений, в результате чего logrotate может быть настроен на хранение сообщений в течение более длительного периода, чем период по умолчанию 5 недель, который по умолчанию используется для большинства файлов.
  • На одном сервере просматривать лог-файлы проще, чем подключаться к нескольким серверам для анализа информации, которая была зарегистрирована.
Помимо аргумента безопасности для настройки удаленного сервера логов, logrotate является еще одной важной причиной, почему имеет смысл это делать. По умолчанию logrotate делает ротацию лог-файлов каждую неделю и хранит их в сжатом виде в течение последних 4 недель.

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

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

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

Настройка сервера сведена к следующему:
  • Настройте rsyslogd для получения сообщений, поступающих с удаленных серверов, используя входные модули imudp или imtcp.
  • Настройте файервол на прием входящего трафика через порт 514.
  • Добавьте правила на клиентские серверы для отправки сообщений на удаленный сервер логов.
Подробная процедура настройки удаленного сервера жописана в упражнении 1.

Упражнение 1.

В этом упражнении вы настроите сервер (server2) для получения сообщений от удаленного сервера (server1). Вы конфигуруете rsyslogd на server1 для пересылки сообщений на server2 и открываете порт файервола на server2, чтобы разрешить получать сообщения из лог-файла.

1. Войдите под root на сервере server2. Затем откройте файл /etc/rsyslog.conf.

2. В файле rsyslog.conf включите следующие две строки, чтобы включить прием логов на TCP-порт 514:
$ ModLoad imtcp
$ InputTCPServerRun 514

3. Закройте файл конфигурации и введите systemctl restart rsyslog, чтобы перезапустить сервис rsyslogd.

4. На server2 откройте TCP-порт 514:
firewall-cmd --add-port=514/tcp --permanent
firewall-cmd --reload

5. Войдите под root на server1 и прокрутите вниз до конца файла конфигурации. Здесь вы найдете следующую строку с примером конфигурации:
#*.* @@remote-host:514

Эта строка показывает, как настроить ваш сервер для пересылки сообщений на удаленный сервер. Измените эту строку, чтобы она читалась следующим образом, чтобы пересылать rsyslogd сообщения на server2:
*.* @@адрес-сервера-server2:514

6. Выполните systemctl restart rsyslog, чтобы перезапустить rsyslogd и начать запись на удаленный сервер.

При настройке удаленного сервера логов вы можете включить прием логов по TCP и UDP. Поскольку UDP является протоколом без установления соединения, доставка сообщений не гарантируется. Это важная причина, чтобы предпочесть обработку журналов по протоколу TCP. Однако если вы хотите настроить сервер, который может принимать сообщения журнала от устаревших syslog-совместимых устройств, вам следует также включить прием журнала по UDP.

Как вы видели в упражнении 1, включить прием логов очень просто; примерные строки для приема логов по TCP или UDP уже присутствуют. Вы просто должны удалить хеш-знаки перед строками:

# Provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

# Provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514

Чтобы отправить сообщения на сервер логов, вы можете использовать пример строки в конце /etc/rsyslog.conf. В этой строке вы используете один @ для отправки журналов по UDP и двойной @ для отправки журналов по TCP.

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

Например, используйте следующую строку для отправки сообщений с приоритетом ошибки и выше на удаленный сервер с использованием TCP:

*.err @@адрес-сервера

Заключение

Это была вторая и заключительная часть статьи о логировании в Linux. В этой части статьи вы узнали, как настроить расширенные функции rsyslog. Вы узнали, как работать с модулями в rsyslogd, как подключить journald к rsyslogd и как настроить центральный сервер логов.

Добавить комментарий