Журналы операционных систем предоставляют множество диагностической информации о ваших компьютерах, и Linux не является исключением. Все, от событий ядра до действий пользователя, записывается в журнал Linux, что позволяет вам увидеть практически любое действие, выполняемое на ваших серверах. В этом руководстве мы объясним, что такое журналы Linux, где они находятся и как их интерпретировать.
Системные журналы Linux
В Linux есть специальный каталог для хранения журналов под названием /var/log. Этот каталог содержит журналы самой ОС, служб и различных приложений, работающих в системе. Вот как выглядит этот каталог в типичной системе Debian.
Некоторые из наиболее важных системных журналов Linux включают:
- /var/log/syslog и /var/log/messages хранят все данные о глобальной активности системы, включая сообщения о запуске. Системы на базе Debian, такие как Ubuntu, хранят эти данные в /var/log/syslog, а системы на базе Red Hat, такие как RHEL или CentOS, используют /var/log/messages.
- В /var/log/auth.log и /var/log/secure хранятся все события, связанные с безопасностью, такие как вход в систему, действия пользователя root, а также данные от подключаемых модулей аутентификации (PAM). Ubuntu и Debian используют /var/log/auth.log, а Red Hat и CentOS - /var/log/secure.
- /var/log/kern.log хранит журналы событий, ошибок и предупреждений ядра, которые особенно полезны для устранения неполадок в пользовательских ядрах.
- /var/log/cron хранит информацию о запланированных заданиях (заданиях cron). Используйте эти данные для проверки успешного выполнения заданий cron.
Некоторые приложения также записывают файлы журналов в этот каталог. Например, веб-сервер Apache записывает журналы в каталог /var/log/apache2 (в Debian), а MySQL записывает журналы в каталог /var/log/mysql. Некоторые приложения также ведут журнал через Syslog, о чем мы расскажем в следующем разделе.
Что такое Syslog?
Syslog - это стандарт для создания и передачи журналов. Слово "syslog" может относиться к любому из следующих понятий:
- Служба syslog получает и обрабатывает сообщения syslog и прослушивает события, создавая сокет по адресу /dev/log, на который могут писать приложения. Она может записывать сообщения в локальный файл или пересылать сообщения на удаленный сервер. Существуют различные реализации syslog, включая rsyslogd и syslog-ng.
- Протокол Syslog (RFC 5424) - это транспортный протокол, определяющий способ передачи журналов по сети. Это также формат данных, определяющий, как структурируются сообщения. По умолчанию он использует порт 514 для сообщений в открытом виде и порт 6514 для зашифрованных сообщений.
- Сообщение syslog - это любой журнал, отформатированный в формате сообщений syslog и состоящий из стандартного заголовка и сообщения, содержащего содержимое журнала.
Поскольку Syslog может пересылать сообщения на удаленные серверы, он часто используется для пересылки системных журналов в решения для управления журналами.
RFC 3164 против RFC 5424
Хотя RFC 5424 является текущим протоколом Syslog, это не единственный стандарт, который можно встретить в природе. RFC 3164 (он же "BSD syslog" или "старый syslog") - это более старый формат syslog, который до сих пор используется многими устройствами. На практике администраторы, скорее всего, увидят сообщения syslog, использующие формат RFC 3164 и RFC 5424.
Хорошими индикаторами сообщения RFC 3164 syslog являются отсутствие структурированных данных и временные метки, использующие формат "Mmm dd hh:mm:ss".
Вот несколько примеров того, как выглядят сообщения BSD, используя раздел 5.4 RFC 3164 в качестве ссылки:
| 1 | <34>Dec 22 15:22:05 server su: 'su admin' failed for user1 on /dev/pts/0 |
| 1 | <13>Dec 22 16:23:13 192.168.100.11 message |
Здесь мы сосредоточимся на более новом протоколе RFC 5424, но имейте в виду RFC 3164, если вы увидите сообщения, не соответствующие RFC 5424.
Формат и поля Syslog
Сообщения Syslog содержат стандартный заголовок с несколькими полями. Они включают временную метку, имя приложения, сгенерировавшего событие, местоположение в системе, откуда пришло сообщение, и его приоритет. Вы можете изменить этот формат в конфигурационном файле вашей реализации syslog, но использование стандартного формата облегчает разбор, анализ и маршрутизацию событий syslog.
Вот пример сообщения журнала, использующего формат по умолчанию. Это сообщение от демона SSH (sshd), который управляет удаленным входом в систему. Это сообщение описывает неудачную попытку входа в систему:
| 1 | Dec 22 11:14:15 server1 sshd[1234] : Failed password for root from 10.0.1.1 port 22 ssh2 |
Вы также можете добавить дополнительные поля в сообщения syslog. Давайте повторим последнее событие после добавления нескольких новых полей. Мы будем использовать следующий шаблон rsyslog, который добавляет приоритет (<%pri%>), версию протокола (%protocol-version%) и дату в формате RFC 3339 (%timestamp:::date-rfc3339%):
| 1 | <%pri%>%protocol-version% %timestamp:::date-rfc3339% %HOSTNAME% %app-name% %procid% %msgid% %msg%n |
При этом генерируется следующий журнал:
| 1 | <34>1 2022-12-22T11:14:15.003Z server1 sshd - - pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.1.1 |
Ниже приведены описания некоторых наиболее часто используемых полей syslog при поиске или устранении неполадок.
Приоритет
Поле приоритета или сокращенно pri ("<34>" в примере) показывает, насколько срочным или серьезным является событие. Оно представляет собой комбинацию двух числовых полей: объект и серьезность. Объект определяет тип процесса, создавшего событие, в диапазоне от 0 для сообщений ядра до 23 для локальных приложений. Степень серьезности варьируется от 0 до 7, причем 0 означает чрезвычайную ситуацию, а 7 - событие отладки.
Pri может быть выведено двумя способами. Первый - в виде одного числа, prival, которое рассчитывается как значение поля facility, умноженное на восемь; затем результат прибавляется к значению поля severity: (facility)(8) + (severity). Второй параметр - pri-text, который выводится в строковом формате "facility.severity". Последний формат часто более удобен для чтения и поиска, но занимает больше места в памяти.
Временная метка
Поле временной метки ("2022-12-22T11:14:15.003Z" в примере выше) указывает время и дату создания сообщения в системе, отправляющей сообщение. Пример временной метки выглядит следующим образом:
- "2022-12-22" - это год, месяц и день.
- "T" - обязательный элемент поля временной метки, разделяющий дату и время.
- "11:14:15.003" - это 24-часовой формат времени, включая количество миллисекунд (003).
- "Z" указывает на время UTC. Вместо Z в примере можно было бы указать смещение, например -08:00, которое указывает, что время смещено от UTC на восемь часов.
Имя хоста
Поле hostname ("server1" в примере) указывает имя узла или системы, которая первоначально отправила сообщение.
Имя приложения
Поле app-name ("sshd:auth" в примере) указывает имя приложения, которое отправило сообщение.
ID процесса
Поле procid содержит PID процесса, создававшее событие
Сообщение (событие)
В поле msg помещается полезная нагрузка события, в зависимости от демона или модуля создавшее сообщение.