Системный журнал#

События системного журнала описаны в разделе «Сценарии администрирования» → «Сценарии администрирования root-администратора» → «Ядро SberLinux» → «Начало работы с ведением журнала ядра».

Устранение неполадок в системных журналах описаны в разделе «Устранение неполадок с помощью лог-файлов».

В SberLinux OS Server существует единый демон, отвечающий за журналирование событий локальной системы и удаленных систем. Все события собираются из сокета /dev/log, порта UDP – 514, а так же от демона klogd, который присылает сообщения от ядра. Все собранные сообщения фильтруются демоном rsyslog через правила в файле /etc/rsyslog\.conf и в соответствии с правилами распределяются по соответствующим местам назначения. Файлы логов периодически обрезаются. Периодичность определяет файл logrotate.conf и команда logrotate, которая запускается системным планировщиком – cron.

Syslog (управление логированием)#

Функция системного журналирования (логирование) – это основной источник информации о работе системы и ошибках. Журналирование может осуществляться на локальной системе, а так же сообщения журналирования могут пересылаться на удаленную систему, кроме того, в конфигурационном файле /etc/rsyslog\.conf возможна тонкая регулировка уровня журналирования. Журналирование осуществляется при помощи демона rsyslog, который обычно получает входную информацию при помощи сокета /dev/log (локально) или с порта UDP – 514 (с удаленных машин).

syslog-server:~# ls -l /dev/log
srw-rw-rw- 1 root root 0 Дек 17 06:25 /dev/log

В случае локального журналирования главным файлом – хранителем информации, обычно является /var/log/messages, но в большинстве инсталляций используются и многие другие файлы, которые могут быть тщательно настроены с помощью вышеуказанного конфигурационного файла. Например, может возникнуть необходимость выделить в отдельный лог сообщения, создаваемые демоном электронной почты.

Служба Rsyslog в SberLinux OS#

В SberLinux OS Server служба Rsyslog устанавливается и запускается автоматически на сервере. Чтобы убедиться, что демон работает в системе, выполните следующую команду:

systemctl status rsyslog.service

• Если служба не запущена по умолчанию, выполните следующую команду, чтобы запустить демон rsyslog:

  systemctl start rsyslog.service
  

• Если демон rsyslog не установлен по умолчанию в системе, которую планируете использовать в качестве централизованного сервера журналов, выполните команду dnf и установите пакет rsyslog. Запустить демон:

dnf install rsyslog
systemctl start rsyslog.service

Чтобы настроить rsyslog в качестве централизованного сервера журналов, выполните следующие действия:

1. Откройте основной файл конфигурации /etc/rsyslog\.conf:

   vi /etc/rsyslog.conf
   

2. В файле конфигурации /etc/rsyslog\.conf раскомментируйте следующие строки, чтобы разрешить прием транспорта UDP на сервер Rsyslog через порт 514. Rsyslog использует стандартный протокол UDP для передачи журналов:

   module(load="imudp") # needs to be done just once
   input(type="imudp" port="514")
   

   Протокол UDP не имеет накладных расходов TCP и делает передачу данных быстрее, чем протокол TCP. С другой стороны, протокол UDP не гарантирует надежности передаваемых данных.

3. Если необходимо использовать протокол TCP для приема журнала, нужно найти и раскомментировать строки в файле конфигурации /etc/rsyslog\.conf, чтобы настроить демон rsyslog для привязки и прослушивания сокета TCP на порту 514:

   module(load="imtcp") # needs to be done just once
   input(type="imtcp" port="514")
   

4. Создайте новый шаблон для получения удаленных сообщений, так как этот шаблон будет направлять локальный сервер Rsyslog, где сохранять полученные сообщения, отправленные сетевыми клиентами Syslog:

   $template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log"
   *.* ?RemoteLogs
   

   Где $template RemoteLogs направляет демон rsyslog для сбора и записи всех переданных сообщений журнала в отдельные файлы на основе имени клиента и удаленного клиентского приложения, создавшего сообщения на основе описанных свойств, добавленных в конфигурацию шаблона: HOSTNAME и PROGRAMNAME.

   Все полученные файлы журнала будут записаны в локальную файловую систему в выделенный файл, названный в честь имени хоста клиентской машины, и храниться в каталоге /var/log/.

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

   RemoteLogs - это произвольное имя, присвоенное этой директиве шаблона. Можно использовать любое имя, которое лучше всего подходит для созданного шаблона.

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

   service rsyslog restart
   

6. После перезапуска сервера Rsyslog он должен действовать как централизованный сервер журнала и записывать сообщения от клиентов Syslog. Чтобы проверить сетевые сокеты Rsyslog, запустите утилиту grep для фильтрации строки rsyslog:

   netstat -tulpn | grep rsyslog
   

Чтобы настроить сложные шаблоны rsyslog, прочтите руководство по файлу конфигурации rsyslog, выполнив команду:

man rsyslog.conf

Настройка параметров логирования#

Основным файлом конфигурации для rsyslog является /etc/rsyslog\.conf. Здесь можно указать глобальные директивы, модули и правила, которые состоят из частей фильтра и действия. Также можно добавлять комментарии в виде текста, следующего за хеш-знаком (#).

Фильтры#

Правило задается частью фильтра, который выбирает подмножество сообщений системного журнала, и частью действия, которое определяет, что делать с выбранными сообщениями. Чтобы определить правило в конфигурационном файле /etc/rsyslog\.conf, определите фильтр и действие в одной строке, а затем разделите их одним или несколькими пробелами или табуляциями.

rsyslog предлагает различные способы фильтрации сообщений системного журнала в соответствии с выбранными свойствами. Доступные методы фильтрации можно разделить на фильтры, основанные на объекте/приоритете, свойствах и выражениях.

Фильтры на основе объекта/приоритета#

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

FACILITY.PRIORITY

Где:

• FACILITY определяет подсистему, которая выдает конкретное сообщение системного журнала. Например, почтовая подсистема обрабатывает все сообщения системного журнала, связанные с почтой. FACILITY может быть представлено одним из следующих ключевых слов (или числовым кодом):

  • kern (0);

  • user (1);

  • mail (2);

  • daemon (3);

  • auth (4);

  • syslog (5);

  • lpr (6);

  • news (7);

  • cron (8);

  • authpriv (9);

  • ftp (10);

  • local0 через local7 (16 - 23).

• PRIORITY определяет приоритет сообщения системного журнала. PRIORITY может быть представлен одним из следующих ключевых слов (или числом):

  • debug (7);

  • info (6);

  • notice (5);

  • warning (4);

  • err (3);

  • crit (2);

  • alert (1);

  • emerg (0).

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

В дополнение можно использовать звездочку (*) для определения всех объектов или приоритетов (в зависимости от того, где ставите звездочку, до или после запятой). Указание ключевого слова приоритета none служит для объектов без заданных приоритетов. Как условия объекта, так и условия приоритета не зависят от регистра.

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

Фильтры на основе свойств#

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

Фильтр на основе свойств должен начинаться с двоеточия (:). Чтобы определить фильтр, используйте следующий синтаксис:

:PROPERTY, [!]COMPARE_OPERATION, "STRING"

Где:

• PROPERTY указывает желаемое свойство;

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

• COMPARE_OPERATION определяет одну из операций сравнения;

• STRING указывает значение, с которым сравнивается текст, предоставляемый свойством. Это значение должно быть заключено в кавычки. Чтобы избежать определенного символа внутри строки (например, кавычки (")), используйте символ обратной косой черты (\).

Фильтры на основе выражений#

Фильтры на основе выражений выбирают сообщения системного журнала в соответствии с определенными арифметическими, логическими или строковыми операциями. Фильтры на основе выражений используют собственный язык сценариев rsyslog под названием RainerScript для создания сложных фильтров.

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

if EXPRESSION then ACTION else ACTION

Где EXPRESSION представляет выражение, подлежащее вычислению, например: $msg startswith 'DEVNAME' или $syslogfacility-text == 'local0'. Можно указать более одного выражения в одном фильтре с помощью and or операторов.

Обратите внимание, что rsyslog поддерживает сравнения без учета регистра в фильтрах на основе выражений. Можно использовать contains_i или startswith_i сравнивать операции внутри атрибута EXPRESSION, например:

if $hostname startswith_i "<HOST_NAME>" then ACTION

Где ACTION представляет действие, которое должно быть выполнено, если выражение возвращает значение true. Это может быть одно действие или произвольный сложный скрипт, заключенный в фигурные скобки.

Фильтры на основе выражений обозначаются ключевым словом if в начале новой строки. Ключевое слово then отделяет EXPRESSION от ACTION. При необходимости вы можете использовать ключевое слово else, чтобы указать, какое действие должно быть выполнено в случае, если условие не будет выполнено.

С фильтрами на основе выражений можно вложить условия, используя скрипт, заключенный в фигурные скобки. Сценарий позволяет использовать фильтры на основе объекта/приоритета внутри выражения. С другой стороны, фильтры на основе свойств здесь не рекомендуются. RainerScript поддерживает регулярные выражения со специализированными функциями re_match() и re_extract().

Шаблоны#

Любой вывод, сгенерированный rsyslog, может быть изменен и отформатирован в соответствии с вашими потребностями с помощью шаблонов. Чтобы создать шаблон, используйте следующий синтаксис в /etc/rsyslog.conf:

template(name=”TEMPLATE_NAME” type=”string” string="text %PROPERTY% more text" [option.OPTION="on"])

Где:

• template() - директива, вводящей блок, определяющий шаблон;

• TEMPLATE_NAME - обязательный аргумент, который используется для ссылки на шаблон. Обратите внимание, что TEMPLATE_NAME должно быть уникальным;

• type - обязательный аргумент, который может принимать одно из следующих значений:

  • “list”;

  • “subtree”;

  • “string”;

  • “plugin”.

• string - аргументом является фактический текст шаблона. Внутри этого текста могут использоваться специальные символы, такие как \n для перевода строки или \r для возврата каретки. Другие символы, такие как % или", должны быть экранированы, если вы хотите использовать эти символы буквально;

• %PROPERTY% - указывает свойство, которое позволяет получить доступ к определенному содержимому сообщения системного журнала;

• OPTION - атрибут определяет любые параметры, которые изменяют функциональность шаблона. В настоящее время поддерживаются следующие параметры шаблона sql: и stdsql, которые используются для форматирования текста в виде SQL-запроса, или json, который форматирует текст так, чтобы он подходил для обработки в формате JSON, и casesensitive который устанавливает чувствительность к регистру имен свойств.

Настройка ротации журналов с помощью logrotate#

Утилита logrotate предназначена для автоматизации обработки журналов. Не требует установки и поставляется по умолчанию.

С помощью данной утилиты можно управлять log-файлами на основе правил, определенных в конфигурационном файле /etc/logrotate.conf. Например, можно настроить удаление или отправку на другой сервер log-файлов, достигших определенного «возраста» или размера.

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

• hourly - каждый час;

• daily - каждый день;

• weekly - каждую неделю;

• monthly - каждый месяц;

• yearly - каждый год.

Часто используемые параметры настроек logrotate:

• mail <adress> - отправляет старый журнал на указанный адрес;

• olddir <directory> - перемещает старый журнал в указанный каталог;

• rotate <N> - хранит определенное количество ротированных журналов, удаляя остальное;

• create - создает пустой журнал после перемещения предыдущего;

• size <000M> - указывает максимальный размер журнала, при превышении которого файл будет перемещен или удален;

• notifempty - не выполняет никаких действий с журналом, если он пуст.

Ознакомиться с другими параметрами настроек конфигурационного файла можно в справочной странице man, вызвав ее с помощью команды:

man -S 8 logrotate

Чтобы настроить различные правила ротации для журналов конкретных служб и утилит, необходимо отредактировать дополнительные настройки в каталоге /etc/logrotate.d/.

Аудит системы с помощью auditd#

На основе предварительно настроенных правил и свойств демон аудита (auditd) генерирует записи журнала для записи информации о событиях, происходящих в системе.

Управление службой аудита#

После auditd настройки запустите службу для сбора информации аудита:

sudo service auditd start

Единственная причина использовать service команду вместо systemctl - это правильно записать значение идентификатора пользователя (UID).

Включите auditd демон, чтобы он мог запускаться во время загрузки:

sudo systemctl enable auditd

Поиск журналов аудита#

Используйте этот ausearch инструмент для поиска в журналах аудита. По умолчанию он выполняет поиск в /var/log/audit/audit.log файле.

Например, для поиска записей журнала на основе key_name:

sudo ausearch -i -k user-modify

Создание аудиторских отчетов#

Используйте этот aureport инструмент для запроса и создания отчетов аудита на основе журналов аудита.

Например, чтобы сгенерировать отчет обо всех исполняемых событиях, выполните:

sudo aureport -x

Журналирование FreeIPA#

Полный перечень файлов и каталогов журналов FreeIPA приведен в разделе «Сценарии администрирования» → «Сценарии root-администратора» → «Работа с управлением учетными записями пользователей» → «FreeIPA» → «Журналирование FreeIPA».

Устранение неполадок с помощью лог-файлов#

Службы, обрабатывающие сообщения системного журнала#

Следующие две службы обрабатывают syslog сообщения:

• Демон systemd-journald;

• Служба Rsyslog.

Демон systemd-journald собирает сообщения из различных источников и пересылает их Rsyslog для дальнейшей обработки. Демон systemd-journald собирает сообщения из следующих источников:

• из ядра;

• на ранней стадии процесса загрузки;

• из стандартного вывода и вывода ошибок демонов при их запуске;

• из Syslog.

Служба Rsyslog сортирует сообщения syslog по типу и приоритету и записывает их в файлы в каталоге /var/log, где постоянно хранятся сообщения журнала.

Подкаталоги для хранения сообщений системного журнала#

Следующие подкаталоги в /var/log каталоге хранят syslog сообщения:

• /var/log/messages - все syslog сообщения, подкаталог содержит глобальный системный журнал, в котором пишутся сообщения с момента запуска системы, от ядра, различных служб, обнаруженных устройствах, сетевых интерфейсов и много другого;

• /var/log/secure - сообщения и ошибки, связанные с безопасностью и аутентификацией;

• /var/log/maillog - сообщения и ошибки, связанные с почтовым сервером;

• /var/log/cron - файлы журналов, связанные с периодически выполняемыми задачами;

• /var/log/boot.log - файлы журналов, связанные с запуском системы.

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

Служба ведения журнала Rsyslog:

Приложение Rsyslog в сочетании со службой systemd-journald обеспечивает локальную и удаленную поддержку ведения журнала в SberLinux OS Server. Демон rsyslogd непрерывно считывает syslog сообщения, полученные systemd-journald службой из журнала. rsyslogd затем фильтрует и обрабатывает эти syslog события и записывает их в Rsyslog-файлы журналов или пересылает другим службам в соответствии со своей конфигурацией.

Демон rsyslogd также обеспечивает расширенную фильтрацию, защищенную от шифрования ретрансляцию сообщений, модули ввода и вывода и поддержку транспортировки с использованием протоколов TCP и UDP.

Файл /etc/rsyslog.conf является основным файлом конфигурации для Rsyslog, в нем можно указать правила, в соответствии с которыми rsyslogd обрабатывает сообщения^ классифицировать сообщения по их источнику, теме (объекту) и срочности (приоритету), а затем назначить действие, которое должно быть выполнено, когда сообщение соответствует этим критериям.

В файле /etc/rsyslog.conf, можно просмотреть список файлов журналов, поддерживаемых rsyslogd. Большинство файлов журнала находятся в /var/log/ каталоге. Некоторые приложения, такие как httpd и samba, хранят свои файлы журналов внутри /var/log/ подкаталога.

Дополнительные источники: rsyslogd(8) и rsyslog.conf(5). Документация, установленная вместе с rsyslog-doc пакетом в /usr/share/doc/rsyslog/html/index.html файле.

Подробнее о настройках журналов см. в разделах «Подкаталоги для хранения сообщений системного журнала» и «Просмотр лог-файлов с помощью командной строки».

Управление логированием и настройка уровней логов#

Все программы SberLinux OS Server ведут лог путем отправки сообщений об ошибках или своем состоянии с помощью syslog или просто записывая все сообщения в файл, который будет находиться в каталоге /var/log/.

Но важное значение имеет уровень подробности логирования. Можно настраивать подробность в каждой отдельной программе или с помощью syslog. Это поможет уменьшить использование дискового пространства для хранения логов.

Например, ядро определяет уровни (приоритеты) логов:

• KERN_EMERG - система неработоспособна;

• KERN_ALERT - нужно немедленно принять меры;

• KERN_CRIT - критическая ошибка;

• KERN_ERR - обычная ошибка;

• KERN_WARNING - предупреждение;

• KERN_NOTICE - замечание;

• KERN_INFO - информационное сообщение;

• KERN_DEBUG - сообщения отладки.

Настройка Rsyslog в SberLinux OS Server#

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

Основные возможности Rsyslog:

• многопоточность;

• TCP, SSL, TLS, RELP;

• поддержка MySQL, PostgreSQL;

• фильтрация журналов;

• полностью настраиваемый формат вывода.

Все настройки Rsyslog находятся в файле /etc/rsyslog.conf и других конфигурационных файлах из /etc/rsyslog.d/.

Чтобы посмотреть, существуют ли файлы, выполните:

ls /etc/rsys*
rsyslog.conf rsyslog.d/

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

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

$ModLoad imuxsock
#Загружает модуль imuxsock, который предоставляет поддержку для локального системного журналирования. Этот модуль необходим для приема сообщений от процессов, работающих на той же машине, где запущен Rsyslog
$ModLoad imklog
#Загружает модуль imklog, который добавляет поддержку журналирования ядра. Этот модуль нужен для сбора сообщений, поступающих от ядра операционной системы
$ModLoad immark
#Загружает модуль immark, который позволяет добавлять специальные сообщения --MARK-- в журнал через регулярные интервалы времени. Эти сообщения могут быть использованы для диагностики и анализа логов

provides UDP syslog reception

$ModLoad imudp
#Загружает модуль imudp, который обеспечивает прием сообщений по протоколу UDP. Этот модуль используется для получения логов от удаленных систем по сети
$UDPServerRun 514
#Активирует UDP-сервер на порту 514. Этот параметр указывает Rsyslog слушать указанный порт для входящих соединений по протоколу UDP.

provides TCP syslog reception

$ModLoad imtcp
#Загружает модуль imtcp, который обеспечивает прием сообщений по протоколу TCP. Этот модуль используется для получения логов от удаленных систем по сети с использованием надежного протокола TCP.
$InputTCPServerRun 514
#Активирует TCP-сервер на порту 514. Этот параметр указывает Rsyslog слушать указанный порт для входящих соединений по протоколу TCP.

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

1. Модули ввода - можно рассматривать, как способ сбора информации из различных источников, начинаются с im.

2. Модули вывода - позволяют отправлять сообщения в файлы или по сети, или в базу данных, имя начинается на om;

3. Модули фильтрации - позволяют фильтровать сообщения по разным параметрам, начинаются с fm;

4. Модули parsing - предоставляют расширенные возможности для синтаксического анализа сообщения, начинаются с pm.

Сначала загружается модуль imuxsock, который позволяет сервису получать сообщения из сокетов, а последующий загружаемый модуль imklog получает сообщения ядра. Модуль mark позволяет маркировать соединения или выводить сообщения о том, что syslog все еще работает. Например, можно дать указания Rsyslog выводить сообщения каждые 20 минут:

MarkMessagePeriod 1200

Далее идут глобальные директивы:

ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

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

Дальше следует набор прав разрешений для файлов журналов, которые будут созданы в системе:

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

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

Правила сортировки лог-файлов#

Набор правил по умолчанию:

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

Каждое правило имеет свой синтаксис, сначала идет источник и приоритет, затем действие. Если источник и приоритет совпадают, сообщение отправляется в указанный файл. Например, можно отправить больше сообщений в лог системы /var/messages:

*.info;mail.none;authpriv.none;cron.none /var/log/messages

В этой строке выберите все сообщения уровня info, кроме mail, authpriv и cron. Шаблон mail.none означает, что ни один уровень сообщений не нужно логировать. Соответственно, конструкция *.info - означает, что логируются сообщения от всех источников, но только с уровнем info, а (точка) . - означает все сообщения, со всеми уровнями.

Источник и приоритет нечувствительны к регистру. Также приоритеты уровней error, warn и panic больше не используются, так как считаются устаревшими.

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

• auth;

• authpriv;

• cron;

• daemon;

• kern;

• lpr;

• mail;

• mark;

• news;

• security (эквивалентно auth);

• syslog;

• user;

• uucp;

• local0 ... local7.

Уровень событий задается приоритетом. А в качестве приоритетов можно применить:

• emerg (раньше panic);

• alert;

• crit;

• error (раньше err);

• warn (раньше warning);

• notice;

• info;

• debug.

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

Можно выполнять фильтрацию сообщений с помощью синтаксиса:

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

В качестве операции сравнения можно использовать такие варианты:

• contains — поле содержит указанное значение;

• isequal — поле должно быть идентичным значению;

• startswith — поле должно начинаться со значения;

• regex — сравнивает поле с регулярным выражением.

Например, отфильтруйте сообщения только от определенной программы:

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

Кроме того, можно использовать более простой синтаксис, в виде выражения if. Вот основной синтаксис:

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

Здесь используются те же самые компоненты. Например:

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

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

Чтобы отправить лог на удаленный сервер, нужно указать @ и <IP_address> удаленной машины, на которой запущен Rsyslog:

*.info;mail.none;authpriv.none;cron.none @<IP_address>:514

Где 514 - это порт, на котором осуществляется Rsyslog. Настройка Rsyslog на прием логов заключается в запуске сервиса с модулями imtcp и imudp.

Чтобы получить логи с определенной машины, отфильтровать их из общего потока с помощью фильтров, выполните:

if $fromhost-ip contains '<IP_address>' then /var/log/proxyserver.log

Без фильтров, сообщения с разных машин будут писаться в один общий лог системы SberLinux OS Server, в зависимости от того, как они будут распределены.

Просмотр лог-файлов с помощью командной строки#

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

Используйте команду journalctl для просмотра сообщений в системном журнале с помощью командной строки, например:

journalctl -b | grep kvm

Пример вывода:

May 15 11:31:41 localhost.localdomain kernel: kvm-clock: Using msrs 4b564d01 and 4b564d00
May 15 11:31:41 localhost.localdomain kernel: kvm-clock: cpu 0, msr 76401001, primary cpu clock
...

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

Оболочки и инструменты командной строки#

Relax and Recover (ReaR) полностью поддерживается на 64-разрядной архитектуре. Базовая функциональность Relax and Recover (ReaR) полностью поддерживается rear версией пакета 2.6-9.el8 или более поздней. Резервное копирование и восстановление логических разделов (LPAR) на данный момент не поддерживается. ReaR поддерживает сохранение и восстановление структуры диска только на устройствах хранения данных с расширенным количеством ключей (ECKD) прямого доступа (DASD). Для этой цели не поддерживаются DASD-диски с фиксированным доступом (FBA) и диски SCSI, подключенные по протоколу Fibre Channel (FCP). В настоящее время доступен единственный метод вывода - начальная загрузка программы (IPL), который создает ядро и начальный диск оперативной памяти (initrd), совместимые с zIPL загрузчиком.