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

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

Настройка системного журнала#

Настройки параметров службы journald (ротация журналов, максимальный уровень сообщений, которые будут храниться в журнале, уровень доступа и прочее) можно задать с помощью файла конфигурации /etc/systemd/journald.conf. Подробнее «База знаний» → «Файл /etc/systemd/journald.conf».

Просматривать данные журналов systemd можно с помощью утилиты journalctl. Подробнее «База знаний» → «Утилита journalctl».

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

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

Основным файлом конфигурации для 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, который устанавливает чувствительность к регистру имен свойств.

Основные события#

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

Доступ к системному журналу#

Доступ к системному журналу регулируется многоуровневой системой прав и контроля доступа, основанной на традиционных Unix-разрешениях, группах пользователей и расширенных ACL (Access Control Lists). Все пользователи имеют доступ к их личным журналам. Однако по умолчанию, чтобы иметь доступ к системному журналу и журналам других пользователей, необходимо быть добавленным в одну из специальных системных групп:

• systemd-journal - основная группа, предоставляющая доступ к системному журналу. Файлы журнала по умолчанию принадлежат этой группе. Добавленные в нее пользователи получают доступ к чтению всех журналов системы.

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

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

Проверить группы пользователя можно с помощью:

groups <user_name>

Где <user_name> – имя пользователя.

Добавить пользователя в группу, например, systemd-journal:

usermod -a -G systemd-journal <user_name>

Для просмотра системного журнала в SberLinux OS Server используется служба systemd-journald и утилита journalctl. Подробнее о командах для работы с журналом - в подразделе «Основные команды для работы с journald».

Основные команды для работы с journald#

Вывод журналов#

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

• Чтобы отобразить в терминале сообщения из файлов журналов за все время работы ОС SberLinux OS Server, используйте команду journalctl без каких-либо опций:

  journalctl
  

• Для просмотра журналов, относящихся к определенному файлу, предоставьте команде journalctl путь к файлу. Приведенный пример показывает все журналы устройства /dev/sda:

  journalctl /dev/sda
  

• Чтобы отобразить в терминале сообщения из файлов журналов, сгенерированных во время текущей загрузки операционной системы, используйте команду journalctl с опцией -b:

  journalctl -b
  

• Для вывода сообщений из журналов предыдущей загрузки ОС, добавьте в предыдущую команду аргумент -1:

  journalctl -b -1
  

  Аргументы опции -b обозначают хронологический порядок журналов загрузки ОС, например:

  • 1 — первая загрузка, найденная в журнале в хронологическом порядке;

  • 2 — вторая загрузка и так далее;

  • 0 - последняя загрузка;

  • -1 — предыдущая загрузка.

• Чтобы отобразить в терминале сообщения из файлов журналов, сгенерированных во время текущей загрузки операционной системы с расшифровкой ошибок, используйте опции -xb:

  journalctl -xb
  

• Опции команды можно группировать, например, для вывода в терминал сообщений ядра (опция -k) второй из предыдущих сессий используйте команду:

  journalctl -k -b -2
  

Фильтрация по дате и времени#

С помощью journalctl можно просматривать сообщения журнала за определенные периоды времени. Для этого используются опции --since (с указанного времени/даты) и --until (по указанное время/дату). Например, чтобы отобразить сообщения журнала с 17 часов 15 минут 20 июля 2024 года, введите команду:

journalctl --since "2024-07-20 17:15:00"

Примеры различных форматов указания даты и времени для опций --since и --until:

• полный формат YYYY-MM-DD HH:MM:SS:

  journalctl --since "2024-05-05 00:01" --until "2024-05-06 01:40"
  

• специальные слова yesterday (вчера), today (сегодня), tomorrow (завтра), «now» (сейчас):

  journalctl --since "yesterday" --until "2024-05-06 01:40"
  

• относительные выражения:

  journalctl --since "10 hours ago"
  journalctl --since "1 minute ago"
  journalctl --since "50 minute ago" --until "5 minute ago"
  

Фильтрация по модулям#

Для просмотра журнала конкретного модуля применяется опция -u. Например, команда ниже отображает в консоли сообщения веб-сервера nginx.

journalctl -u nginx.service

Для просмотра сообщений журнала определенных служб за заданный период времени используйте сочетание опций -u и --since:

journalctl -u nginx.service -u php-fpm.service --since today

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

Фильтрация по процессам, пользователям и группам#

Чтобы посмотреть сообщения журнала для определенного процесса, укажите в команде journalctl его идентификационный номер (PID):

journalctl _PID=381

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

В сценарии ниже в качестве примера приведен веб-сервер, запущенный от имени пользователя www-data:

1. Определите ID пользователя www-data:

   id -u www-data
   

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

   33
   

   Отобразите сообщения журнала процессов, запущенных от имени пользователя www-data, командой:

   journalctl _UID=33
   

2. Выведите в консоль список пользователей, о которых имеются записи в журналах, командой:

   journalctl -F _UID
   

3. Аналогичный список групп пользователей, можно получить с помощью команды:

   journalctl -F _GUID
   

Фильтрация по пути процесса#

Чтобы посмотреть журналы для определенного процесса, укажите в команде journalctl путь к его исполняемому файлу. Например:

journalctl /usr/bin/docker

Фильтрация сообщений по уровню ошибки#

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

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

В journalctl используется следующая система классификации уровней ошибок:

• EMERG (система неработоспособна) — код уровня 0;

• ALERT (необходимо немедленное вмешательство) — код уровня 1;

• CRIT (критическое состояние) — код уровня 2;

• ERR (ошибка) — код уровня 3;

• WARNING (предупреждение) — код уровня 4;

• NOTICE (все нормально, но стоит обратить внимание) — код уровня 5;

• INFO (информационное сообщение) — код уровня 6;

• DEBUG (сообщение отладки) — код уровня 7.

Код уровня ошибки указывается в команде journalctl после опции -p.

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

journalctl -p err -b

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

Nov 02 12:58:41 localhost kernel: shpchp 0000:01:00.0: Slot initialization failed

Синтаксис сообщений об ошибках:

<timestamp> <hostname> <sender_of_the_message>: <description>

Где:

• <timestamp> - временная метка;

• <hostname> - имя хоста, на котором произошло событие;

• <sender_of_the_message> - компонент, сгенерировавший сообщение;

• <description> - описание ошибки.

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

<timestamp> [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
    _TRANSPORT=<sender_of_the_message>
    SYSLOG_FACILITY=<syslog_level>
    SYSLOG_IDENTIFIER=<sender_ID>
    _BOOT_ID=<current_boot_ID>
    _MACHINE_ID=<machine_ID>
    _HOSTNAME=<hostname>
    _RUNTIME_SCOPE=<runtime>
    PRIORITY=<priority_level>
    _SOURCE_MONOTONIC_TIMESTAMP=<time_since_the_start_of_the_system>
    MESSAGE=<description>

Где:

• <timestamp> - временная метка;

• <session_ID> - идентификатор сессии;

• <message_ID> - идентификатор сообщения;

• <boot_ID> - идентификатор загрузки;

• <timestamp_ID> - идентификатор метки времени;

• <time_ID> - идентификатор времени события;

• <additional_ID> - дополнительный идентификатор;

• <sender_of_the_message> - компонент, сгенерировавший сообщение;

• <syslog_level> - уровень системного журнала;

• <sender_ID> - идентификатор отправителя сообщения;

• <current_boot_ID> - идентификатор текущей загрузки системы;

• <machine_ID> - уникальный идентификатор машины;

• <hostname> - имя хоста, на котором произошло событие;

• <runtime> - среда выполнения, в которой было записано сообщение;

• <priority_level> - уровень сообщения;

• <time_since_the_start_of_the_system> - время в миллисекундах с момента старта системы;

• <description> - текст сообщения, описание ошибки.

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

Примеры событий для каждого уровня ошибок:

• EMERG (0):

  Sat 2024-11-02 03:35:49.356005 UTC [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
      _TRANSPORT=kernel
      SYSLOG_FACILITY=0
      SYSLOG_IDENTIFIER=kernel
      _MACHINE_ID=<machine_ID>
      _HOSTNAME=localhost.localdomain
      _RUNTIME_SCOPE=system
      _BOOT_ID=<current_boot_ID>
      PRIORITY=0
      MESSAGE=__common_interrupt: 1.59 No irq handler for vector
      _SOURCE_MONOTONIC_TIMESTAMP=66351116624
  

• ALERT (1):

  Tue 2024-11-05 10:35:59.795541 UTC [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
      _MACHINE_ID=<machine_ID>
      _UID=0
      _GID=0
      _TRANSPORT=syslog
      _HOSTNAME=localhost.localdomain
      _RUNTIME_SCOPE=system
      SYSLOG_FACILITY=1
      _BOOT_ID=<current_boot_ID>
      SYSLOG_IDENTIFIER=root
      _SELINUX_CONTEXT=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
      PRIORITY=1
      SYSLOG_TIMESTAMP=Nov  5 10:35:59
      MESSAGE=This is an alarm level message
      _PID=19245
      _SOURCE_REALTIME_TIMESTAMP=<timestamp>
  

• CRIT (2):

  Tue 2024-11-05 10:34:46.508242 UTC [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
      _MACHINE_ID=<machine_ID>
      _UID=0
      _GID=0
      _TRANSPORT=syslog
      _HOSTNAME=localhost.localdomain
      _RUNTIME_SCOPE=system
      SYSLOG_FACILITY=1
      _BOOT_ID=<current_boot_ID>
      PRIORITY=2
      SYSLOG_IDENTIFIER=root
      SYSLOG_TIMESTAMP=Nov  5 10:34:46
      MESSAGE=This is a critical message
      _PID=19225
      _SELINUX_CONTEXT=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
      _SOURCE_REALTIME_TIMESTAMP=<timestamp>
  

• ERR (3):

  Fri 2024-11-01 09:10:02.364827 UTC [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
      _TRANSPORT=kernel
      SYSLOG_FACILITY=0
      SYSLOG_IDENTIFIER=kernel
      _BOOT_ID=<current_boot_ID>
      _MACHINE_ID=<machine_ID>
      _HOSTNAME=localhost
      _RUNTIME_SCOPE=initrd
      _KERNEL_SUBSYSTEM=pci
      _KERNEL_DEVICE=+pci:0000:01:00.0
      _UDEV_SYSNAME=0000:01:00.0
      PRIORITY=3
      _SOURCE_MONOTONIC_TIMESTAMP=3095097
      MESSAGE=shpchp 0000:01:00.0: Slot initialization failed
  

• WARNING (4):

  Fri 2024-11-01 08:34:59.863990 UTC [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
      _TRANSPORT=kernel
      SYSLOG_FACILITY=0
      SYSLOG_IDENTIFIER=kernel
      _BOOT_ID=<current_boot_ID>
      _MACHINE_ID=<machine_ID>
      _HOSTNAME=localhost
      _RUNTIME_SCOPE=initrd
      _SOURCE_MONOTONIC_TIMESTAMP=4700596
      PRIORITY=4
      MESSAGE=device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.
  

• NOTICE (5):

  Fri 2024-11-01 08:34:59.432363 UTC [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
      _TRANSPORT=kernel
      PRIORITY=5
      SYSLOG_FACILITY=0
      SYSLOG_IDENTIFIER=kernel
      _BOOT_ID=<current_boot_ID>
      _MACHINE_ID=<machine_ID>
      _HOSTNAME=localhost
      _RUNTIME_SCOPE=initrd
      _SOURCE_MONOTONIC_TIMESTAMP=82015
      MESSAGE=Unknown kernel command line parameters "BOOT_IMAGE=(hd0,gpt3)/ostree/SBCOS-9.4-<commit_hash>/vmlinuz-5.14.0-427.40.1.el9_4.x86_64 ostree=/ostree/boot.1/SBCOS-9.4/<commit_hash>/0", will be passed to user space.
  

• INFO (6):

  Fri 2024-11-01 08:34:59.430949 UTC [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
      _SOURCE_MONOTONIC_TIMESTAMP=0
      _TRANSPORT=kernel
      SYSLOG_FACILITY=0
      SYSLOG_IDENTIFIER=kernel
      _BOOT_ID=<current_boot_ID>
      _MACHINE_ID=<machine_ID>
      _HOSTNAME=localhost
      _RUNTIME_SCOPE=initrd
      PRIORITY=6
      MESSAGE=x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
  

• DEBUG (7):

  Fri 2024-11-01 08:34:59.431473 UTC [s=<session_ID>;i=<message_ID>;b=<boot_ID>;m=<timestamp_ID>;t=<time_ID>;x=<additional_ID>]
      _TRANSPORT=kernel
      SYSLOG_FACILITY=0
      SYSLOG_IDENTIFIER=kernel
      _BOOT_ID=<current_boot_ID>
      _MACHINE_ID=<machine_ID>
      _HOSTNAME=localhost
      _RUNTIME_SCOPE=initrd
      PRIORITY=7
      _SOURCE_MONOTONIC_TIMESTAMP=791
      MESSAGE=e820: remove [mem 0x000a0000-0x000fffff] usable
  

Отключение разбивки вывода на страницы#

По умолчанию journalctl использует для вывода сообщений журнала внешнюю утилиту less. При этом вывод разбивается на страницы, а длинные строки обрезаются под размер экрана. Для просмотра текста, выходящего за границы экрана, используют клавиши ← и →. При этом становится невозможным использовать стандартные инструменты для работы с текстом (например, grep).

Проблему можно решить с помощью опции --no-pager:

journalctl --no-pager

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

Выбор формата вывода#

С помощью опции -o можно преобразовать сообщения журнала в различные форматы, что упрощает их анализ и обработку. Например, объект JSON можно представить в более структурированном и читабельном виде, используя форматы json-pretty или json-sse:

journalctl -u nginx.service -o json-pretty

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

• cat — отображает сообщения из журнала без служебных полей;

• export — сериализует журнал в бинарный поток, подходит для экспорта или резервного копирования сообщений журнала;

• short — максимально совпадает со стандартным syslog;

• short-iso — максимально совпадает с syslog с метками времени в формате ISO 8601;

• short-monotonic — максимально совпадает с syslog c монотонно возврастающими метками времени (monotonic timestamp);

• short-precise — максимально совпадает с syslog с метками точного времени (время событий указывается с точностью до микросекунд);

• verbose — максимально подробный формат представления данных (включает даже те поля, которые в других форматах не отображаются).

Просмотр информации о недавних событиях и в режиме реального времени#

Опция -n позволяет просматривать информацию о недавних событиях в системе:

journalctl -n

По умолчанию на экран выводятся последние 10 событий. С помощью аргумента опции -n можно указать желаемое количество событий, например, для вывода 20 событий используйте команду:

journalctl -n 20

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

journalctl -f

Вывод журнала в текстовый файл#

Если нужно сохранить журнал в текстовом формате, используйте конструкцию <command> > <file-path>. Например, чтобы сохранить все текущие сообщения журнала в файл /home/user/loginfo.log, используйте команду:

journalctl -b > /home/user/loginfo.log

Для обработки полученных таким образом текстовых файлов журналов могут использоваться универсальные инструменты: cat, less, tail, head, текстовый редактор nano или команда grep для поиска информации по заданному шаблону.

Примеры использования:

• Отображение последних десяти строк файла с помощью утилиты tail:

  tail /home/user/loginfo.log
  

• Увеличение количества выводимых строк до 100 с помощью опции -n:

  tail -n 100 /home/user/loginfo.log
  

• Отслеживание появление новых строк в файле в режиме реального времени с помощью опции -f:

  tail -f /home/user/loginfo.log
  

Проверка целостности файлов журналов#

Чтобы проверить целостность файлов журналов systemd, проанализировав их контрольные суммы, выполните команду:

journalctl --verify

Переключение на syslog#

Допускается либо параллельное ведение журналов в syslog, либо полное переключение на него. За это отвечают параметры Storage и ForwardToSyslog в файле /etc/systemd/journald.conf:

[Journal]
Storage=none
ForwardToSyslog=yes

Где:

• Storage — определяет, где хранить данные журнала. Возможные значения:

  • volatile — данные хранятся только в оперативной памяти (в каталоге /run/log/journal);

  • persistent — данные хранятся предпочтительно на диске (в каталоге /var/log/journal);

  • auto (по умолчанию) — хранится на диске, если существует каталог /var/log/journal, иначе в оперативной памяти;

  • none — данные журнала не сохраняются.

• ForwardToSyslog — определяет, следует ли пересылать сообщения системного журнала в syslog. Возможные значения: yes или no.

После внесения этих настроек необходимо установить один из вариантов syslog, например, сервис Rsyslog.

Сервис Rsyslog#

Rsyslog — это сервис для обработки и управления log-файлами. Предоставляет возможности для сбора, фильтрации, пересылки и хранения log-файлов в ОС. Является расширенной версией syslog.

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

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

• обрабатывает большое количество сообщений одновременно, что повышает производительность системы;

• поддерживает передачу log-файлов через сети с использованием протоколов TCP, SSL, TLS и RELP;

• поддерживает запись сообщений не только в текстовые файлы, но и в базы данных, такие как MySQL, PostgreSQL;

• позволяет настраивать правила для разделения сообщений между различными файлами или игнорирования ненужных записей;

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

Основной конфигурационный файл - /etc/rsyslog.conf. Подробнее о файле rsyslog.conf «База знаний» → «Файл /etc/rsyslog.conf».

Дополнительные конфигурационные файлы с расширением .conf могут быть расположены в каталоге /etc/rsyslog.d/ и подключаются в /etc/rsyslog.conf с помощью директивы IncludeConfig /etc/rsyslog.d/*.conf.

При настройке Rsyslog можно редактировать как основной файл /etc/rsyslog.conf, так и создавать или изменять отдельные файлы внутри каталога /etc/rsyslog.d/.

Демон rsyslogd - один из ключевых компонентов сервиса Rsyslog, отвечающий за сбор, фильтрацию и запись log-файлов в системном журнале. Подробнее о работе rsyslogd «База знаний» → «Демон rsyslogd».

Работа с Rsyslog#

Сервис Rsyslog установлен в системе по умолчанию и запускается автоматически.

Чтобы убедиться, что сервис работает в системе, выполните:

systemctl status rsyslog

rpm -qa | grep rsyslog

Если сервис не запущен, выполните:

systemctl start rsyslog

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

systemctl enable rsyslog

Чтобы изменить конфигурацию Rsyslog:

1. Откройте для редактирования конфигурационный файл и внесите изменения:

   nano /etc/rsyslog.conf
   

2. Проверьте правильность синтаксиса конфигурационного файла:

   rsyslogd -N 1
   

3. Перезагрузите сервис:

   systemctl restart rsyslog
   

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

Утилита logrotate предназначена для автоматизации обработки журналов. Подробнее «База знаний» → «Утилита logrotate».

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

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

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

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

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

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

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

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

Управление размером log-файлов на диске#

Доступны следующие функции управления размером:

• Определение текущего объема журналов.

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

  journalctl --disk-usage
  

• Ротация журналов.

  Настройка ротации журналов осуществляется с помощью опций −−vacuum-size и −−vacuum-time. Первая из них устанавливает предельно допустимый размер для хранимых на диске файлов журнала (в примере ниже - 1 ГБ):

  journalctl --vacuum-size=1G
  

  Как только объем сообщений превысит указанное значение, лишние файлы журнала будут автоматически удалены.

  Аналогичным образом работает опция −−vacuum-time. Она устанавливает для файлов журнала время хранения, по истечении которого они будут автоматически удалены:

  journalctl --vacuum-time=1years
  

• Настройка ротации в конфигурационном файле.

  Настройки ротации журналов можно также прописать в конфигурационном файле /еtc/systemd/journald.conf, который включает в числе прочих следующие параметры:

  • SystemMaxUse — максимальный объем, который файлы журнала могут занимать на диске;

  • SystemKeepFree — объем свободного места, которое должно оставаться на диске после сохранения файлов журнала;

  • SystemMaxFileSize — объем отдельного файла журнала, по достижении которого он должен быть удален с диска;

  • SystemMaxFiles — максимальное количество файлов журнала, которые могут храниться на диске;

  • RuntimeMaxUse — максимальный объем, который файлы журнала могут занимать при хранении в оперативной памяти (run/log/journal);

  • RuntimeKeepFree — объем свободного места, которое должно оставаться в оперативной памяти (run/log/journal) после сохранения файлов журнала;

  • RuntimeMaxFileSize — объем отдельного файла журнала, по достижении которого он должен быть удален из оперативной памяти (run/log/journal);

  • RuntimeMaxFiles — максимальное количество файлов журнала, которые могут храниться в оперативной памяти (run/log/journal).

Отладка журнала#

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

1. Создайте каталог systemd-journald.service.d в /etc/systemd/system/:

   mkdir -p /etc/systemd/system/systemd-journald.service.d/
   

2. Создайте файл drop-in /etc/systemd/system/systemd-journald.service.d/10-debug.conf с содержимым:

   [Service]
   Environment=SYSTEMD_LOG_LEVEL=debug
   

3. Перезапустите службу systemd для сканирования на новые и измененные модули:

   systemctl daemon-reload
   

4. Перезапустите службу systemd-journald:

   systemctl restart systemd-journald
   

5. Выведите сообщения ядра в консоль и отфильтруйте по шаблону systemd-journald:

   dmesg | grep systemd-journald
   

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

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

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

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

sudo service auditd start

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

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

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 сортирует сообщения по типу и приоритету и записывает их в файлы в каталоге /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 непрерывно считывает сообщения, полученные systemd-journald службой из журнала. rsyslogd затем фильтрует и обрабатывает события и записывает их в Rsyslog-файлы журналов или пересылает другим службам в соответствии со своей конфигурацией.

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

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

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

Дополнительная информация о работе перечисленных инструментов указана в справочных страницах man: rsyslogd(8) и rsyslog.conf(5).

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

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

Все программы ОС 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 загрузчиком.