Linux Logging Basics
Operating system logs provide a wealth of diagnostic information about your computer, and Linux is no exception. Everything from kernel events to user actions are logged by Linux, allowing you to see almost any action performed on your servers. In this section, we’ll explain what Linux logs are, where you can find them, and how to interpret them.
Linux System Logs
Linux has a special directory for storing logs called /var/log . This directory contains logs from the OS itself, services, and various applications running on the system. Here’s what this directory looks like on a typical Ubuntu system.
Some of the most important Linux system logs include:
- /var/log/syslog and /var/log/messages store all global system activity data, including startup messages. Debian-based systems like Ubuntu store this in /var/log/syslog , while Red Hat-based systems like RHEL or CentOS use /var/log/messages .
- /var/log/auth.log and /var/log/secure store all security-related events such as logins, root user actions, and output from pluggable authentication modules (PAM). Ubuntu and Debian use /var/log/auth.log , while Red Hat and CentOS use /var/log/secure .
- /var/log/kern.log stores kernel events, errors, and warning logs, which are particularly helpful for troubleshooting custom kernels.
- /var/log/cron stores information about scheduled tasks (cron jobs). Use this data to verify that your cron jobs are running successfully.
Some applications also write log files in this directory. For example, the Apache web server writes logs to the /var/log/apache2 directory (on Debian), while MySQL writes logs to the /var/log/mysql directory. Some applications also log via syslog, which we’ll explain in the next section.
What’s Syslog?
Syslog is a standard for creating and transmitting logs. The word “syslog” can refer to any of the following.
- The syslog service, which receives and processes syslog messages. It listens for events by creating a socket located at /dev/log , which applications can write to. It can write messages to a local file or forward messages to a remote server. There are different syslog implementations including rsyslogd and syslog-ng.
- The syslog protocol (RFC 5424), which is a transport protocol that specifies how to transmit logs over a network. It is also a data format defining how messages are structured. By default, it uses port 514 for plaintext messages and port 6514 for encrypted messages.
- A syslog message, which is any log formatted in the syslog message format. A syslog message consists of a standardized header and message containing the log’s contents.
Since syslog can forward messages to remote servers, it’s often used to forward system logs to log management solutions such as SolarWinds ® Loggly ® and SolarWinds Papertrail ™ .
Syslog Format and Fields
Syslog messages contain a standardized header with several fields. These include the timestamp, the name of the application that generated the event, the location in the system where the message originated, and its priority. You can change this format in your syslog implementation’s configuration file, but using the standard format makes it easier to parse, analyze, and route syslog events.
Here is an example log message using the default format. It’s from the sshd daemon, which controls remote logins to the system. This message describes a failed login attempt:
You can also add additional fields to your syslog messages. Let’s repeat the last event after adding a few new fields. We’ll use the following rsyslog template, which adds the priority ( ), protocol version ( %protocol-version% ), and the date formatted using RFC 3339 ( %timestamp. date-rfc3339% ):
This generates the following log:
Below, you’ll find descriptions of some of the most commonly used syslog fields when searching or troubleshooting issues.
The timestamp field indicates the time and date the message was generated on the system sending the message. The example timestamp breaks down like this:
- “2019-06-05”is the year, month, and day.
- “T”is a required element of the timestamp field, separating the date and the time.
- “22:14:15.003”is the 24-hour format of the time, including the number of milliseconds (003).
- “Z”indicates UTC time. Instead of z, the example could have included an offset, such as -08:00, which indicates that the time is offset from UTC by eight hours.
The hostname field (“server1” in the example above) indicates the name of the host or system that originally sent the message.
The app-name field (“sshd:auth” in the example) indicates the name of the application that sent the message.
The priority field or pri for short (“ ” in the example above) tells you how urgent or severe the event is. It’s a combination of two numerical fields: the facility and the severity. The facility specifies the type of process that created the event, ranging from 0 for kernel messages to 23 for local applications. The severity ranges from 0–7, with 0 indicating an emergency and 7 indicating a debug event.
Pri can be output in two ways. The first is as a single number, prival, which is calculated as the facility field value multiplied by eight, then the result is added to the severity field value: (facility)(8) + (severity). The second is pri-text, which will output in the string format “facility.severity”. The latter format can often be easier to read and search, but takes up more storage space.
Logging with Systemd
Many Linux distributions ship with systemd, which is a process and service manager. Systemd implements its own logging service called journald that can replace or complement syslog. Journald logs in a significantly different manner than systemd, which is why it has its own section in the Ultimate Guide to Logging. You can learn more about logging via systemd in the Systemd Logging section.
Источник
Логи в Linux. Как найти и прочитать?
Обновл. 20 Май 2021 |
Процесс загрузки системы, работа приложений и служб, различные действия пользователей, сообщения ядра ОС и многое другое — все эти события регистрируются в специальных журналах операционной системы, так называемых log-файлах (или «логах»). Если в работе системы что-то пойдет не так, то эти файлы станут для вас полезным источником информации, с помощью которого вы сможете разобраться в причинах возникших проблем и самостоятельно их устранить.
Как посмотреть логи в Linux?
Большинство логов в Linux генерируются системными демонами syslogd или rsyslogd и хранятся в обычном текстовом файле ASCII в каталоге /var/log. Этот каталог содержит лог-файлы самой ОС, служб и различных приложений, запущенных в системе. Вот как этот каталог выглядит в типичной системе Debian Linux:
Если вы попробуете просмотреть какой-нибудь лог-файл от имени обычного пользователя, то в 99% случаев система ответит вам сообщением о нехватке прав доступа. Поэтому я заранее переключился на пользователя root (команда su –) и все дальнейшие действия будут выполняться от его имени.
Теперь можно перейти к непосредственному изучению содержимого лог-файлов. И для начала, мы заглянем внутрь boot.log. Данный лог-файл содержит информацию обо всех этапах загрузки операционной системы:
root@debian:/var/log# tail boot.log
Как вы можете заметить, команда tail вывела последние 10 строк лог-файла, которые дают нам информацию о последовательном запуске различных сервисов, а также отображает их статус.
Как уже было сказано выше, многие лог-файлы хранятся в виде обычных текстовых файлов, поэтому их можно просматривать с помощью следующих стандартных команд:
tail — вывод последних 10 строк;
head — вывод первых 10 строк;
cat — вывод содержимого всего лог-файла;
grep — поиск в лог-файле всех вхождений заданного выражения или фильтрация лог-файла по заданному выражению;
zcat — отображает всё содержимое сжатых лог-файлов (с расширением *.gz);
zmore — постраничный просмотр сжатых лог-файлов, без их распаковки;
zgrep — поиск внутри сжатого лог-файла.
Основные логи
В основных логах, необходимых для работы Linux, содержится наиболее значительный объем информации о текущем состоянии системы. Их можно условно разделить на четыре категории:
Многие из этих лог-файлов располагаются в каталоге var/log. Наиболее распространенными логами являются:
/var/log/boot.log — журнал загрузки системы (в нем хранится вся информация, связанная с этапами загрузки ОС);
/var/log/kern.log — журнал ядра (в нем хранятся сообщения и предупреждения, поступающие непосредственно из ядра Linux);
/var/log/syslog или /var/log/messages — журналы, в которых хранится информация об общей активности в системе (включая сообщения этапа загрузки);
/var/log/auth.log или /var/log/secure — журналы аутентификации и безопасности (в них хранятся записи обо всех попытках входа в систему, включая как успешные, так и неудачные);
/var/log/debug — журнал отладки (в нем хранится подробная отладочная информация системы и приложений);
/var/log/daemon.log — журнал демонов (содержит информацию о событиях, связанных с различными запущенными в системе демонами/службами);
/var/log/maillog или /var/log/mail.log — журналы почтовых серверов (в них хранится информация, относящаяся к почтовым серверам и архивированию электронных писем);
/var/log/cron — журнал, в котором хранится информация о запланированных задачах (заданиях cron);
/var/log/faillog — информация о неудачных входах в систему. Журнал полезен для изучения потенциальных нарушений безопасности, таких как: взломы учетных записей, попытки перебора паролей и пр.;
/var/log/dmesg — журнал сообщений драйверов устройств. Просмотреть содержимое данного журнала можно с помощью команды dmesg . Стоит заметить, что при достижении своего предела, старые сообщения перезаписываются более новыми.
/var/log/Xorg.x.log — журнал сообщений X-сервера.
В зависимости от выбранного дистрибутива, вы можете встретить следующие лог-файлы менеджеров пакетов:
/var/log/dpkg.log — журнал пакетов, установленных через утилиту dpkg в системах на основе Debian Linux.
/var/log/yum.log — журнал пакетов, установленных через утилиту yum в системах на основе Red Hat Linux.
/var/log/emerge.log — журнал пакетов (ebuild), установленных через утилиту emerge в Gentoo Linux.
Не все журналы разработаны в удобочитаемом виде. Некоторые из них предназначены только для чтения системными приложениями и представлены в бинарном формате данных:
/var/log/utmp и /var/log/utmp — журналы учета входов пользователей в систему. Для просмотра сообщений применяется команда utmpdump , например:
/var/log/lastlog — журнал с информацией о последних входах пользователей. Для просмотра сообщений применяется команда lastlog :
Ротация лог-файлов
Если учесть, что информация в лог-файлы поступает регулярно и по любому поводу, то в скором времени они должны были бы стать просто гигантскими, занимая при этом огромную кучу места на диске. А работать с ними было бы просто невозможно. Но этого не происходит благодаря ротации лог-файлов.
Цель ротации заключается в сжатии устаревших лог-файлов, которые занимают много места. Лог-файлы, в конце имен которых добавлены нули, являются ротируемыми (их имена были автоматически изменены системой). Ротацию лог-файлов можно выполнить с помощью команды logrotate, например:
Настройки ротации лог-файлов хранятся в соответствующем файле конфигурации /etc/logrotate.conf:
var/log/имя_журнала.log <
Missingok
Notifempty
Compress
Size 20k
Daily
Create 0600 root root
>
Разберем детально каждую строку вышеприведенного фрагмента:
Missingok — указывает команде logrotate не выводить ошибку, если лог-файл отсутствует.
Notifempty — если лог-файл пуст, то ротации не будет.
Compress — лог-файл необходимо сжать.
Size 20k — гарантирует, что лог-файл не превышает заданного размера, в противном случае производится его ротация.
Daily — ротация лог-файлов по ежедневному расписанию. Также можно задавать ежечасный ( Hourly ), еженедельный ( Weekly ), ежемесячный ( Monthly ) или ежегодный ( Yearly ) график.
Create 0600 root root — создает экземпляр лог-файла, владельцем и группой которого является root.
Теперь, разобравшись с тем, что означает каждый параметр, можно каждому лог-файлу задавать соответствующий индивидуальный параметр ротации.
systemd и journald
systemd — это подсистема инициализации и управления службами в Linux, фактически вытеснившая в 2010-е годы традиционную подсистему init. В связке с ней работает и journald — демон сбора логов, являющийся частью systemd. Он собирает логи со всей системы и хранит их в бинарном виде в каталоге /var/log/journal. Для того чтобы их просмотреть, создана специальная утилита journalctl. Рассмотрим несколько примеров её применения.
Чтобы просмотреть последние 10 строк логов всех запусков системы, достаточно выполнить следующую команду:
# journalctl —list-boots | tail
Видите столбец, который я обвел красным? Цифрой 0 в нем обозначена текущая загрузка системы, цифрой -1 — предыдущая и т.д. Если вы хотите просмотреть логи какой-то конкретной загрузки, например, позапрошлой, то достаточно ввести:
Также можно просмотреть информацию по выбранной службе, например, по NetworkManager:
# journalctl -u NetworkManager
Или же вывести сообщения ядра ОС:
Для получения своих, каких-то более конкретных результатов, допускается комбинировать опции и параметры команды journalctl :
# journalctl -b -1 -u NetworkManager
Для вывода информации только по нескольким последним записям, применяется опция -n , задающая их количество:
# journalctl -u NetworkManager -n 5
Если говорить про systemd, то, наверное, стоит упомянуть и про команду systemd-analyze, которая отвечает за сбор статистики загрузки системы. Применение данной команды без параметров отобразит общее время загрузки системы:
С помощью параметра blame можно увидеть, сколько времени понадобилось для загрузки каждой конкретной службы (при этом сверху отобразятся самые медленные):
Приоритет сообщений в лог-файлах
Сообщения в лог-файлах создаются в зависимости от типа событий. В свою очередь, событие имеет определенную степень важности. В зависимости от этой важности событию присваивается определенный приоритет:
emerg — наивысший приоритет, что-то сломалось, повод паниковать;
alert — тревога, стоит волноваться;
crit — критическое событие, стоит насторожиться;
err — ошибка;
warning — предупреждение;
notice — уведомление, можно не заморачиваться;
info — информационное сообщение, принять к сведению и забыть;
debug — отладочная информация.
Применяя вышеописанные значения приоритетов, можно просматривать сообщения лог-файлов, фильтруя их по заданному приоритету:
# grep ‘err’ /var/log/syslog
Или же для journalctl:
# journalctl -p warning -b 0
Заключение
Конечно, на данном уроке были рассмотрены только самые основные моменты данной темы. Но в то же время объема представленной информации вполне хватит обычному пользователю, чтобы свободно работать с логами в Linux. Увидимся!
Поделиться в социальных сетях:
Источник
