Анализ журналов в Red Hat Enterprise Linux

Red Hat Enterprise LinuxBeginner
Практиковаться сейчас

Введение

В этой лабораторной работе вы получите практический опыт анализа и хранения системных журналов в Red Hat Enterprise Linux 9 с использованием journalctl и rsyslog. Вы начнете с понимания базовой архитектуры системного журналирования, включая роли systemd-journald и rsyslog, а также определения ключевых файлов журналов. Затем вы научитесь просматривать и фильтровать файлы syslog, используя распространенные команды, вручную отправлять пользовательские syslog-сообщения, а также исследовать и фильтровать записи системного журнала с помощью journalctl. Лабораторная работа также охватывает настройку постоянного хранения системного журнала и поддержание точного системного времени с использованием timedatectl и chronyd, что даст вам необходимые навыки для системного анализа и устранения неполадок.

Понимание архитектуры системного журнала и ключевых файлов

На этом этапе вы узнаете об основных компонентах системного журналирования в Red Hat Enterprise Linux 9, уделяя особое внимание службам systemd-journald и rsyslog, а также ключевым файлам журналов, которыми они управляют. Понимание этой архитектуры имеет решающее значение для эффективного системного анализа и устранения неполадок.

Во-первых, давайте рассмотрим службу systemd-journald. Эта служба является ядром журналирования событий операционной системы. Она собирает сообщения о событиях из различных источников, включая ядро системы, процессы ранней загрузки, стандартный вывод/ошибки демонов и события syslog. Служба systemd-journald хранит эти журналы в структурированном, индексированном двоичном файле, называемом journal (журнал).

Далее мы рассмотрим службу rsyslog. В то время как systemd-journald собирает журналы, rsyslog читает сообщения syslog из журнала по мере их поступления. Затем он обрабатывает эти сообщения и записывает их в традиционные файлы журналов в каталоге /var/log или пересылает их другим службам в соответствии со своей конфигурацией. Эти файлы rsyslog сохраняются после перезагрузок.

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

ls /var/log

Вы увидите список различных файлов журналов. В зависимости от вашей системы, вы должны увидеть такие файлы, как anaconda, audit, boot.log, chrony, cron, dnf.log, messages, secure и другие. Некоторые из наиболее распространенных включают:

  • /var/log/messages: Этот файл содержит большинство общих сообщений syslog, за исключением сообщений, связанных с аутентификацией, обработкой электронной почты, выполнением запланированных заданий и отладкой.
  • /var/log/secure: Этот файл хранит сообщения syslog, связанные с событиями безопасности и аутентификации.
  • /var/log/maillog: Этот файл содержит сообщения syslog о почтовом сервере.
  • /var/log/cron: Этот файл регистрирует сообщения syslog о выполнении запланированных заданий.
  • /var/log/boot.log: Этот файл содержит консольные сообщения, не относящиеся к syslog, о запуске системы.

Чтобы просмотреть содержимое этих файлов, вы можете использовать такие команды, как cat, less или tail. Обратите внимание, что для чтения большинства файлов журналов в /var/log требуются права root, поэтому вам нужно будет использовать sudo. Например, давайте посмотрим последние несколько строк файла /var/log/messages, используя tail.

sudo tail /var/log/messages

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

sudo tail /var/log/secure

Понимание назначения этих файлов поможет вам быстро найти соответствующую информацию при устранении проблем с системой.

Просмотр и фильтрация файлов Syslog с использованием распространенных команд

На этом этапе вы узнаете, как эффективно просматривать и фильтровать файлы syslog, используя распространенные команды Linux. Сообщения Syslog классифицируются по facility (какая подсистема создает сообщение) и priority (серьезность сообщения). Понимание этих категорий имеет решающее значение для эффективного анализа журналов.

Во-первых, давайте рассмотрим концепцию Syslog Facilities и Priorities.

Syslog Facilities (службы): Они указывают источник сообщения журнала. Примеры включают kern (сообщения ядра), user (сообщения пользовательского уровня), mail (сообщения почтовой системы), daemon (сообщения системных демонов), auth (сообщения аутентификации и безопасности) и cron (сообщения демона часов).

Syslog Priorities (приоритеты): Они определяют серьезность сообщения, варьируясь от emerg (система неработоспособна) до debug (сообщение уровня отладки). Порядок серьезности от самого высокого к самому низкому: emerg, alert, crit, err, warning, notice, info, debug.

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

Давайте начнем с просмотра всего содержимого /var/log/messages, используя less. Эта команда позволяет прокручивать файл. Нажмите q, чтобы выйти из less. Не забудьте использовать sudo, так как для чтения файлов журналов требуются права root.

sudo less /var/log/messages

Теперь давайте попробуем отфильтровать сообщения. Предположим, вас интересуют сообщения, связанные с authentication (аутентификацией). Эти сообщения обычно находятся в /var/log/secure. Используйте grep, чтобы найти строки, содержащие слово "authentication" в /var/log/secure. Не забудьте использовать sudo для доступа к файлу журнала.

sudo grep "authentication" /var/log/secure

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

sudo grep "sshd" /var/log/secure

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

Dec 16 10:15:30 host sshd[1234]: Accepted publickey for labex from 172.25.0.10 port 12345 ssh2
Dec 16 10:15:30 host sshd[1234]: pam_unix(sshd:session): session opened for user labex(uid=1000) by (uid=0)
...output omitted...

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

sudo grep "$(date '+%b %d')" /var/log/messages

Ротация файлов журналов (Log File Rotation):
Чтобы файлы журналов не занимали слишком много дискового пространства, системы используют logrotate. Эта утилита выполняет ротацию файлов журналов, переименовывая старые (например, /var/log/messages становится /var/log/messages-20220320) и создавая новые, пустые. Через определенный период (обычно четыре недели) самые старые ротированные файлы журналов удаляются. Запланированное задание запускает logrotate ежедневно для управления этим процессом.

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

ls -l /var/log/messages*

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

-rw-------. 1 root root 123456 Mar 20 23:59 /var/log/messages
-rw-------. 1 root root  78901 Mar 13 23:59 /var/log/messages-20220320
-rw-------. 1 root root  54321 Mar 06 23:59 /var/log/messages-20220313.gz
...output omitted...

Это показывает, как logrotate управляет старыми файлами журналов.

Наконец, давайте проанализируем структуру записи syslog. Типичное сообщение журнала в /var/log/secure выглядит так:

Dec 16 10:11:48 host sshd[1433]: Failed password for student from 172.25.0.10 port 59344 ssh2

  • Dec 16 10:11:48: Метка времени записи журнала.
  • host: Хост, отправивший сообщение журнала.
  • sshd[1433]: Имя программы или процесса (sshd) и его PID (1433), отправившего сообщение журнала.
  • Failed password for …: Фактическое содержимое сообщения.

Понимание этого формата помогает вам более эффективно анализировать и интерпретировать записи журнала.

Отправка пользовательских сообщений Syslog вручную

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

Команда logger отправляет сообщения в службу rsyslog. По умолчанию она отправляет сообщение с user facility (службой) и notice priority (приоритетом) (user.notice), если иное не указано с помощью опции -p.

Давайте начнем с отправки простого тестового сообщения в местоположение журнала по умолчанию, которое обычно находится в /var/log/messages.

logger "This is a test message from labex."

После выполнения команды вы можете убедиться, что сообщение было зарегистрировано, проверив файл /var/log/messages. Используйте tail, чтобы просмотреть последние несколько строк файла. Не забудьте использовать sudo для доступа к файлу журнала.

sudo tail /var/log/messages

Вы должны увидеть свое пользовательское сообщение в конце вывода, похожее на это:

...
Dec 16 10:30:00 host labex: This is a test message from labex.

Теперь давайте попробуем отправить сообщение с определенной службой и приоритетом. Вспомните из предыдущего шага, что сообщения syslog классифицируются по службе и приоритету. Например, local7.notice означает, что сообщение будет зарегистрировано со службой local7 и приоритетом notice. Служба local7 часто используется для пользовательских приложений или загрузочных сообщений, и обычно она направляется в /var/log/boot.log конфигурацией rsyslog.

Чтобы отправить сообщение в службу rsyslog для записи в файл журнала /var/log/boot.log, выполните следующую команду logger:

logger -p local7.notice "Log entry created by labex for boot.log"

Теперь убедитесь, что это сообщение было записано в /var/log/boot.log. Используйте sudo для доступа к файлу журнала.

sudo tail /var/log/boot.log

Вы должны увидеть свое пользовательское сообщение в выводе:

...
Dec 16 10:31:00 host labex: Log entry created by labex for boot.log

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

Изучение и фильтрация записей системного журнала с помощью journalctl

На этом шаге вы узнаете, как исследовать и фильтровать записи системного журнала с помощью команды journalctl. Как вы узнали, служба systemd-journald хранит данные журналов в структурированном, индексированном двоичном файле, называемом journal (журнал). Команда journalctl — ваш основной инструмент для взаимодействия с этим журналом.

Давайте начнем с просмотра всех сообщений в журнале. Когда вы запускаете journalctl без каких-либо опций, он отображает все доступные записи журнала, начиная с самых старых. Поскольку вы вошли в систему как labex с привилегиями sudo, у вас будет полный доступ к журналу.

journalctl

Вы увидите большой объем вывода. Нажмите q, чтобы выйти из средства просмотра journalctl. Обратите внимание, что journalctl выделяет важные сообщения журнала: сообщения с приоритетом notice или warning выделены жирным шрифтом, а сообщения с приоритетом error или выше — красным цветом.

Теперь давайте рассмотрим некоторые распространенные опции journalctl для фильтрации и просмотра конкретных записей.

1. Просмотр последних N записей журнала (опция -n):
По умолчанию journalctl -n показывает последние 10 записей журнала. Вы можете указать другое число, например, последние 5 записей:

journalctl -n 5

Вы должны увидеть 5 самых последних записей журнала.

2. Отслеживание новых записей журнала (опция -f):
Аналогично команде tail -f, опция journalctl -f выводит последние 10 строк системного журнала и продолжает выводить новые записи журнала по мере их добавления. Это очень полезно для мониторинга в реальном времени.

journalctl -f

Чтобы выйти из этого непрерывного вывода, нажмите Ctrl+C.

3. Фильтрация по приоритету (опция -p):
Вы можете отфильтровать вывод по уровню приоритета записей журнала. Опция journalctl -p показывает записи с указанным уровнем приоритета (по имени или по номеру) или выше. Уровни приоритета в порядке возрастания: debug, info, notice, warning, err, crit, alert и emerg.

Давайте перечислим записи журнала с приоритетом err или выше:

journalctl -p err

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

4. Фильтрация по unit (юниту) systemd (опция -u):
Вы можете отображать сообщения для указанного systemd unit (юнита), используя опцию journalctl -u и имя юнита. Например, чтобы просмотреть журналы специально для службы sshd:

journalctl -u sshd.service

Это отобразит все записи журнала, связанные с демоном SSH.

5. Фильтрация по временному диапазону (опции --since и --until):
При поиске конкретных событий вы можете ограничить вывод определенным временным интервалом. Обе опции --since и --until принимают аргумент времени в формате "YYYY-MM-DD hh:mm:ss". Двойные кавычки требуются, если в аргументе есть пробелы. Вы также можете использовать относительные термины, такие как yesterday (вчера), today (сегодня), tomorrow (завтра), или временные интервалы, такие как "-1 hour" ("-1 час").

Давайте посмотрим все записи журнала с начала сегодняшнего дня:

journalctl --since today

Теперь давайте посмотрим записи за последний час:

journalctl --since "-1 hour"

6. Просмотр подробного вывода (опция -o verbose):
Чтобы увидеть дополнительные сведения о каждой записи журнала, включая внутренние поля журнала, вы можете использовать опцию -o verbose. Это может быть полезно для расширенного устранения неполадок.

journalctl -n 1 -o verbose

Это покажет последнюю запись журнала со всеми ее подробными деталями. Обратите внимание на такие поля, как _COMM (имя команды), _EXE (путь к исполняемому файлу), _PID (ID процесса), _UID (ID пользователя) и _SYSTEMD_UNIT (systemd unit). Эти поля можно использовать для более точной фильтрации.

Например, чтобы найти записи из определенного процесса sshd с известным PID (вы можете получить PID из предыдущего вывода journalctl -u sshd.service):

journalctl _SYSTEMD_UNIT=sshd.service _PID=<PID_NUMBER>

Замените <PID_NUMBER> фактическим PID, который вы наблюдали из записей sshd. Например, если вы увидели sshd[1433], вы бы использовали _PID=1433.

journalctl _SYSTEMD_UNIT=sshd.service _PID=1433

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

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

На этом шаге вы узнаете, как настроить системный журнал для сохранения данных после перезагрузок. По умолчанию Red Hat Enterprise Linux 9 хранит системный журнал в каталоге /run/log, который является временной файловой системой. Это означает, что все записи журнала очищаются после перезагрузки системы. Чтобы сохранить исторические данные журнала, вам необходимо настроить службу systemd-journald для постоянного хранения.

Конфигурация для systemd-journald находится в файле /etc/systemd/journald.conf. Параметр Storage в этом файле определяет, хранятся ли журналы в энергозависимом режиме или постоянно.

Параметр Storage может быть установлен в одно из следующих значений:

  • persistent: Хранит журналы в каталоге /var/log/journal, который сохраняется после перезагрузок. Если этот каталог не существует, systemd-journald создаст его.
  • volatile: Хранит журналы во временном каталоге /run/log/journal. Данные в /run не сохраняются после перезагрузок. Это поведение по умолчанию, если Storage не указан явно и /var/log/journal не существует.
  • auto: Если каталог /var/log/journal существует, systemd-journald использует постоянное хранилище; в противном случае он использует энергозависимое хранилище. Это значение по умолчанию, если вы не установили параметр Storage.
  • none: Хранилище не используется. Все журналы удаляются, хотя их все еще можно пересылать.

Давайте изменим файл /etc/systemd/journald.conf, чтобы включить постоянное хранение журнала. Вы будете использовать sudo nano для редактирования этого файла.

sudo nano /etc/systemd/journald.conf

Внутри редактора nano найдите раздел [Journal]. Раскомментируйте строку Storage (удалите # в начале) и установите ее значение в persistent.

Ваш файл должен выглядеть примерно так (показаны только соответствующие строки):

[Journal]
Storage=persistent
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#Audit=no
#FlushIntervalSec=
#SyncIntervalSec=
#ReadKMsg=yes
#Audit=yes

После внесения изменений сохраните файл, нажав Ctrl+X, затем Y для подтверждения сохранения и Enter для подтверждения имени файла.

Чтобы изменения вступили в силу, вам необходимо перезапустить службу systemd-journald. Поскольку эта среда является контейнером Docker, systemctl недоступен. Вместо этого мы смоделируем эффект перезапуска службы, обеспечив создание каталога /var/log/journal и наличие правильных разрешений, что systemd-journald сделает при перезапуске в неконтейнеризованной среде.

Сначала давайте создадим каталог, если он не существует, и установим соответствующие разрешения.

sudo mkdir -p /var/log/journal
sudo chown root:systemd-journal /var/log/journal
sudo chmod 2755 /var/log/journal

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

ls -l /var/log/journal

Вы должны увидеть подкаталог с длинным шестнадцатеричным именем (например, 4ec03abd2f7b40118b1b357f479b3112). Внутри этого каталога вы найдете файлы .journal.

ls -l /var/log/journal/ <YOUR_HEX_ID> /

Замените <YOUR_HEX_ID> фактическим шестнадцатеричным идентификатором, который вы нашли в предыдущем выводе команды ls. Например:

ls -l /var/log/journal/4ec03abd2f7b40118b1b357f479b3112/

Вы должны увидеть файлы, такие как system.journal и, возможно, user-1000.journal.

Даже при наличии постоянных журналов система не хранит все данные вечно. Журнал имеет встроенный механизм ротации журналов. Вы можете настроить ограничения по размеру и периоды хранения в файле /etc/systemd/journald.conf, используя такие параметры, как SystemMaxUse, SystemKeepFree, SystemMaxFileSize и MaxRetentionSec.

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

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

journalctl --list-boots

Вы увидите список идентификаторов загрузки и соответствующих им временных диапазонов. Текущая загрузка обычно имеет значение 0. Предыдущие загрузки — отрицательные числа (-1, -2 и т. д.).

Чтобы просмотреть записи только из текущей загрузки системы:

journalctl -b

Чтобы просмотреть записи из предыдущей загрузки (например, той, что была перед текущей, обычно -1):

journalctl -b -1

На этом настройка постоянного хранения журнала завершена.

Поддержание точного системного времени с помощью timedatectl и chronyd

На этом шаге вы узнаете, как поддерживать точное системное время с помощью команды timedatectl и поймете роль службы chronyd. Точное ведение времени имеет решающее значение для ведения журналов, безопасности и многих сетевых служб.

1. Использование timedatectl для управления системным временем и часовыми поясами:

Команда timedatectl предоставляет обзор текущих системных настроек, связанных со временем, включая местное время, всемирное координированное время (UTC), время RTC, часовой пояс и статус синхронизации NTP.

Давайте проверим текущие настройки времени вашей системы:

timedatectl

Вы должны увидеть вывод, аналогичный этому (точное время и дата будут отражать текущее системное время):

               Local time: Sun 2025-06-15 21:46:11 EDT
           Universal time: Mon 2025-06-16 01:46:11 UTC
                 RTC time: Mon 2025-06-16 01:46:10
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Вы можете перечислить все доступные часовые пояса, используя опцию list-timezones:

timedatectl list-timezones | less

Нажмите q, чтобы выйти из less. Часовые пояса называются на основе базы данных часовых поясов Internet Assigned Numbers Authority (IANA), обычно по континенту/океану, а затем по крупнейшему городу.

Чтобы изменить часовой пояс системы, вы используете опцию set-timezone. Например, давайте изменим часовой пояс на America/Phoenix. Для этого вам потребуются привилегии sudo.

sudo timedatectl set-timezone America/Phoenix

Теперь проверьте изменение:

timedatectl

Вы должны увидеть, что часовой пояс обновился до America/Phoenix.

Вы также можете вручную установить текущее время системы, используя опцию set-time. Формат: "YYYY-MM-DD hh:mm:ss", но вы можете опустить дату или время. Давайте установим время на 09:00:00 (для текущей даты).

sudo timedatectl set-time 09:00:00

Проверьте изменение времени:

timedatectl

Наконец, опция set-ntp включает или отключает синхронизацию NTP для автоматической корректировки времени. Она принимает true или false в качестве аргумента. Давайте на мгновение отключим синхронизацию NTP (мы снова включим ее позже).

sudo timedatectl set-ntp false

Проверьте статус службы NTP:

timedatectl

Вы должны увидеть NTP service: inactive.

2. Понимание и настройка службы chronyd:

Служба chronyd — это демон, который поддерживает точность часов реального времени (RTC) системы, синхронизируя их с серверами Network Time Protocol (NTP). Это клиент NTP по умолчанию в Red Hat Enterprise Linux.

Файл конфигурации для chronyd/etc/chrony.conf. По умолчанию он использует общедоступные серверы NTP. В реальном сценарии вы можете настроить его на использование внутренних серверов NTP.

Давайте посмотрим файл chrony.conf по умолчанию.

cat /etc/chrony.conf

Вы увидите строки, начинающиеся с server или pool, которые определяют источники NTP. Опция iburst рекомендуется, поскольку она быстро выполняет четыре измерения для более точной начальной синхронизации.

Stratum (страта) источника времени NTP указывает его качество. Stratum 0 — это эталонные часы, stratum 1 напрямую подключен к эталонным часам, а stratum 2 синхронизируется с сервером stratum 1.

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

Давайте повторно включим синхронизацию NTP с помощью timedatectl.

sudo timedatectl set-ntp true

Снова проверьте статус службы NTP:

timedatectl

Вы должны увидеть NTP service: active.

Команда chronyc действует как клиент для службы chronyd. Вы можете использовать ее для мониторинга статуса синхронизации. Команда chronyc sources показывает текущие источники времени и их статус синхронизации.

chronyc sources -v

Вывод покажет подробности об источниках NTP. Звездочка * в поле S (Source state - состояние источника) указывает на источник, с которым chronyd в данный момент синхронизирован.

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 100.100.61.88                 1   5   377    16  +1824us[+2180us] +/-   85ms
...output omitted...

Этот вывод подтверждает, что ваша система активно синхронизирует свое время с сервером NTP.

Резюме

В этой лабораторной работе мы получили всестороннее понимание архитектуры системного журнала в Red Hat Enterprise Linux 9, сосредоточившись на взаимодействии между systemd-journald и rsyslog. Мы узнали, что systemd-journald собирает и хранит структурированные, индексированные двоичные журналы в журнале, в то время как rsyslog обрабатывает эти сообщения и записывает их в традиционные файлы журналов в /var/log. Мы изучили ключевые файлы журналов, такие как /var/log/messages, /var/log/secure и другие, и попрактиковались в просмотре и фильтрации файлов syslog с помощью общих команд. Мы также узнали, как вручную отправлять пользовательские сообщения syslog.

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