In this chapter, we will discuss in detail about system logging in Unix.
Unix systems have a very flexible and powerful logging system, which enables you to record almost anything you can imagine and then manipulate the logs to retrieve the information you require.
Many versions of Unix provide a general-purpose logging facility called syslog. Individual programs that need to have information logged, send the information to syslog.
Unix syslog is a host-configurable, uniform system logging facility. The system uses a centralized system logging process that runs the program /etc/syslogd or /etc/syslog.
The operation of the system logger is quite straightforward. Programs send their log entries to syslogd, which consults the configuration file /etc/syslogd.conf or /etc/syslog and, when a match is found, writes the log message to the desired log file.
There are four basic syslog terms that you should understand −
Sr.No.
Term & Description
1
The identifier used to describe the application or process that submitted the log message. For example, mail, kernel, and ftp.
An indicator of the importance of the message. Levels are defined within syslog as guidelines, from debugging information to critical events.
A combination of one or more facilities and levels. When an incoming event matches a selector, an action is performed.
What happens to an incoming message that matches a selector — Actions can write the message to a log file, echo the message to a console or other device, write the message to a logged in user, or send the message along to another syslog server.
Syslog Facilities
We will now understand about the syslog facilities. Here are the available facilities for the selector. Not all facilities are present on all versions of Unix.
Facility
Description
1
Activity related to requesting name and password (getty, su, login)
Same as auth but logged to a file that can only be read by selected users
Used to capture messages that are generally directed to the system console
Messages from the cron system scheduler
System daemon catch-all
Messages relating to the ftp daemon
Local facilities defined per site
Messages from the line printing system
Messages relating to the mail system
Pseudo-event used to generate timestamps in log files
Messages relating to network news protocol (nntp)
Messages relating to network time protocol
Regular user processes
Syslog Priorities
The syslog priorities are summarized in the following table −
Sr.No.
Priority & Description
1
Emergency condition, such as an imminent system crash, usually broadcast to all users
Condition that should be corrected immediately, such as a corrupted system database
Critical condition, such as a hardware error
Condition that is not an error, but possibly should be handled in a special way
Messages that are used when debugging programs
Pseudo level used to specify not to log messages
The combination of facilities and levels enables you to be discerning about what is logged and where that information goes.
As each program sends its messages dutifully to the system logger, the logger makes decisions on what to keep track of and what to discard based on the levels defined in the selector.
When you specify a level, the system will keep track of everything at that level and higher.
The /etc/syslog.conf file
The /etc/syslog.conf file controls where messages are logged. A typical syslog.conf file might look like this −
Each line of the file contains two parts −
A message selector that specifies which kind of messages to log. For example, all error messages or all debugging messages from the kernel.
An action field that says what should be done with the message. For example, put it in a file or send the message to a user’s terminal.
Following are the notable points for the above configuration −
Message selectors have two parts: a facility and a priority. For example, kern.debug selects all debug messages (the priority) generated by the kernel (the facility).
Message selector kern.debug selects all priorities that are greater than debug.
An asterisk in place of either the facility or the priority indicates «all». For example, *.debug means all debug messages, while kern.* means all messages generated by the kernel.
You can also use commas to specify multiple facilities. Two or more selectors can be grouped together by using a semicolon.
Logging Actions
The action field specifies one of five actions −
Log message to a file or a device. For example, /var/log/lpr.log or /dev/console.
Send a message to a user. You can specify multiple usernames by separating them with commas; for example, root, amrood.
Send a message to all users. In this case, the action field consists of an asterisk; for example, *.
Pipe the message to a program. In this case, the program is specified after the Unix pipe symbol (|).
Send the message to the syslog on another host. In this case, the action field consists of a hostname, preceded by an at sign; for example, @tutorialspoint.com.
The logger Command
Unix provides the logger command, which is an extremely useful command to deal with system logging. The logger command sends logging messages to the syslogd daemon, and consequently provokes system logging.
This means we can check from the command line at any time the syslogd daemon and its configuration. The logger command provides a method for adding one-line entries to the system log file from the command line.
The format of the command is −
Here is the detail of the parameters −
Sr.No.
Option & Description
1
Uses the contents of file filename as the message to log.
Logs the process ID of the logger process with each line.
Enters the message with the specified priority (specified selector entry); the message priority can be specified numerically, or as a facility.priority pair. The default priority is user.notice.
Marks each line added to the log with the specified tag.
The string arguments whose contents are concatenated together in the specified order, separated by the space.
You can use Manpage Help to check complete syntax for this command.
Log Rotation
Log files have the propensity to grow very fast and consume large amounts of disk space. To enable log rotations, most distributions use tools such as newsyslog or logrotate.
These tools should be called on a frequent time interval using the cron daemon. Check the man pages for newsyslog or logrotate for more details.
Important Log Locations
All the system applications create their log files in /var/log and its sub-directories. Here are few important applications and their corresponding log directories −
Источник
Управление логгированием в systemd
Демон инициализации systemd де-факто уже стал стандартом в современных Linux-системах. На него перешли многие популярные дистрибутивы: Debian, RHEL/CentOS, Ubuntu (начиная с версии 15.04). В systemd используется принципиально иной (по сравнению с традиционным инструментом syslog) подход к логгированию. В его основе лежит централизация: специализированный компонент journal cобирает все системные сообщения (сообщения ядра, различных служб и приложений). При этом специально настраивать отправку логов не нужно: приложения могут просто писать в stdout и stderr, a journal сохранит эти сообщения автоматически. Работа в таком режиме возможна и с Upstart, но он сохраняет все логи в отдельный файл, тогда как systemd сохраняет их в бинарной базе, что существенно упрощает систематизацию и поиск.
Хранение логов в бинарных файлах также позволяет избежать сложностей с использованием парсеров для разных видов логов. При необходимости логи можно без проблем переконвертировать в другие форматы (более подробно об этом будет рассказано ниже). Journal может работать как совместно с syslog, так и полностью заменить его. Для просмотра логов используется утилита journalctl. Об особенностях и тонкостях работы с ней мы расскажем в этой статье.
Установка времени
Одним из существенных недостатков syslog является сохранение записей без учёта часового пояса. В journal этот недостаток устранён: для логгируемых событий можно указывать как местное время, так и универсальное координированное время (UTC). Установка времени осуществляется с помощью утилиты timedatectl. Просмотреть список часовых поясов можно при помощи команды:
Установка нужного часового пояса осуществляется так:
По завершении установки будет нелишним убедиться в том, что всё сделано правильно:
В самой первой строке (Local time) должны быть показаны точное текущее время и дата.
Journalctl: просмотр логов
Для просмотра логов используется утилита journalctl. Если ввести команду journalсtl без каких-либо аргументов, на консоль будет выведен огромный список:
Здесь мы привели лишь небольшой его фрагмент; на самом деле он включает гигантское количество записей.
Фильтрация логов
У утилиты journalctl есть опции, с помощью которых можно осуществлять фильтрацию логов и быстро извлекать из них нужную информацию.
Просмотр логов с момента текущей загрузки
С помощью опции -b можно просмотреть все логи, собранные с момента последней загрузки системы:
Просмотр логов предыдущих сессий
С помощью journalctl можно просматривать информацию о предыдущих сессиях работы в системе — в некоторых случаях это бывает полезным. Следует, однако, учитывать, что сохранение информации о предыдущих сессиях поддерживается по умолчанию не во всех дистрибутивах Linux. Иногда его требуется активировать
Для этого нужно открыть конфигурационный файл journald.conf, найти в нём раздел [Journal] и изменить значение параметра storage на persistent:
Просмотреть список предыдущих загрузок можно с помощью команды:
Её вывод состоит из четырёх колонок. В первой из них указывается порядковый номер загрузки, во второй — её ID, в третьей — дата и время. Чтобы просмотреть лог для конкретной загрузки, можно использовать идентификаторы как из первой, так и из второй колонки:
Фильтрация по дате и времени
В journalctl имеется также возможность просмотра логов за определённые периоды времени. Для этого используются опции —since и —until. Предположим, нам нужно просмотреть логи начиная с 17 часов 15 минут 20 июля 2015 года. Для этого потребуется будет выполнить команду:
Если с опцией since не будет указано никакой даты, на консоль будут выведены логи начиная с текущей даты. Если дата указана, но при этом не указано время, будет применено значение времени по умолчанию — «00:00:00». Секунды также указывать не обязательно (в этом случае применяется значение по умолчанию — 00).
Можно воспользоваться и вот такими человекопонятными конструкциями:
Фильтрация по приложениям и службам
Для просмотра логов конкретного приложения или службы используется опция -u, например:
Приведённая команда выведет на консоль логи веб-сервера nginx. Нередко возникает необходимость просмотреть логи какой-либо службы за определённый период времени. Это можно сделать при помощи команды вида:
C опцией -u также используется фильтрация по дате и времени, например:
Благодаря этому можно отслеживать взаимодействие различных служб и получать информацию, которую нельзя было бы получить при отслеживании соответствующих процессов по отдельности.
Фильтрация по процессам, пользователям и группам
Просмотреть логи для какого-либо процесса можно, указав в команде journalctl его идентификационный номер (PID), например:
Для просмотра логов процессов, запущенных от имени определённого пользователя или группы, используются фильтры _UID и _GID соответственно. Предположим, у нас имеется веб-сервер, запущенный от имени пользователя www-data. Определим сначала ID этого пользователя:
Теперь можно просмотреть логи всех процессов, запущенных от имени этого пользователя:
Вывести на консоль список пользователей, о которых имеются записи в логах, можно так:
Для просмотра аналогичного списка пользовательских групп используется команда:
С командной journalctl можно использовать и другие фильтры. Просмотреть список всех доступных фильтров можно, выполнив команду
Фильтрация по пути
Просмотреть логи для какого-либо процесса также можно, указав путь к нему, например:
Иногда таким способом можно получить более подробную информацию (например, просмотреть записи для всех дочерних процессов).
Просмотр сообщений ядра
Для просмотра сообщений ядра используется опция -k или −−dmesg:
Приведённая команда покажет все сообщения ядра для текущей загрузки. Чтобы просмотреть сообщения ядра для предыдущих сессий, нужно воспользоваться опцией -b и указать один из идентификаторов сессии (порядковый номер в списке или ID):
Фильтрация сообщений по уровню ошибки
Во время диагностики и исправления неполадок в системе нередко требуется просмотреть логи и выяснить, есть ли в них сообщения о критических ошибках. Специально для этого в journalctl предусмотрена возможность фильтрации по уровню ошибки. Просмотреть сообщения обо всех ошибках, имевших место в системе, можно с помощью опции -p:
Приведённая команда покажет все сообщения об ошибках, имевших место в системе.
Эти сообщения можно фильтровать по уровню. В journal используется такая же классификация уровней ошибок, как и в syslog:
0 — EMERG (система неработоспособна);
1 — ALERT (требуется немедленное вмешательство);
2 — CRIT (критическое состояние);
3 — ERR (ошибка);
4 — WARNING (предупреждение);
5 — NOTICE (всё нормально, но следует обратить внимание);
6 — INFO (информационное сообщение);
7 —DEBUG (отложенная печать).
Коды уровней ошибок указываются после опции -p.
Запись логов в стандартный вывод
По умолчанию journalctl использует для вывода сообщений логов внешнюю утилиту less. В этом случае к ним невозможно применять стандартные утилиты для обработки текстовых данных (например, grep). Эта проблема легко решается: достаточно воспользоваться опцией −−no-pager, и все сообщения будут записываться в стандартный вывод:
После этого их можно будет передать другим утилитам для дальнейшей обработки или сохранить в текстовом файле.
Выбор формата вывода
C помощью опции -o можно преобразовывать данные логов в различные форматы, что облегчает их парсинг и дальнейшую обработку, например:
Объект json можно представить в более структурированном и человекочитаемом виде, указав формат json-pretty или json-sse:
Помимо JSON данные логов могут быть преобразованы в следующие форматы:
cat — только сообщения из логов без служебных полей;
export — бинарный формат, подходит для экспорта или резервного копирования логов;
short — формат вывода syslog;
short-iso — формат вывода syslog с метками времени в формате ISO 8601;
short-monotonic — формат вывода syslog c метками монотонного времени (monotonic timestamp);
short-precise — формат вывода syslog с метками точного времени (время событий указывается с точностью до микросекунд);
verbose — максимально подробный формат представления данных (включает даже те поля, которые в других форматах не отображаются).
Просмотр информации о недавних событиях
Опция -n используется для просмотра информации о недавних событиях в системе:
По умолчанию на консоль выводится информация о последних 10 событиях. С опцией -n можно указать необходимое число событий:
Просмотр логов в режиме реального времени
Сообщения из логов можно просматривать не только в виде сохранённых файлов, но и в режиме реального времени. Для этого используется опция -f:
Управление логгированием
Определение текущего объёма логов
Со временем объём логов растёт, и они занимают всё больше места на жёстком диске. Узнать объём имеющихся на текущий момент логов можно с помощью команды:
Ротация логов
Настройка ротации логов осуществляется с помощью опций −−vacuum-size и −−vacuum-time. Первая из них устанавливает предельно допустимый размер для хранимых на диске логов (в нашем примере — 1 ГБ):
Как только объём логов превысит указанную цифру, лишние файлы будут автоматические удалены. Аналогичным образом работает опция −−vacuum-time. Она устанавливает для логов срок хранения, по истечении которого они будут автоматически удалены:
Настройка ротации логов в конфигурационном файле
Настройки ротации логов можно также прописать в конфигурационном файле /еtc/systemd/journald.conf, который включает в числе прочих следующие параметры:
SystemMaxUse= максимальный объём, который логи могут занимать на диске;
SystemKeepFree= объём свободного места, которое должно оставаться на диске после сохранения логов;
SystemMaxFileSize= объём файла лога, по достижении которого он должен быть удален с диска;
RuntimeMaxUse= максимальный объём, который логи могут занимать в файловой системе /run;
RuntimeKeepFree= объём свободного места, которое должно оставаться в файловой системе /run после сохранения логов;
RuntimeMaxFileSize= объём файла лога, по достижении которого он должен быть удален из файловой системы /run.
Централизованное хранение логов
Одной из самых распространённых задач в работе системного администратора является настройка сбора логов с нескольких машин с последующим помещением в централизованное хранилище. В systemd предусмотрены специальные компоненты для решения этой задачи: systemd-journal-remote, systemd-journal-upload и systemd-journal-gatewayd.
С помощью команды systemd-journal-remote можно принимать логи с удалённых хостов и сохранять их (на каждом их этих хостов должен быть запущен демон systemd-journal-gatewayd), например:
В результате выполнения приведённой команды логи с хоста some.host будут сохранены в директории var/log/journal/some.host/remote-some
С помощью команды systemd-journal-remote можно также складывать имеющиеся на локальной машине логи в отдельную директорию, например:
Команда systemd-journal-upload используется для загрузки логов с локальной машины в удалённое хранилище:
Как видно из приведённых примеров, «родные» утилиты systemd для поддержки централизованного логгирования просты и удобны в работе. Но они, к сожалению, пока что включены далеко не во все дистрибутивы, а только в Fedora и ArchLinux.
Пользователи других дистрибутивов пока что приходится передавать логи в syslog или rsyslog, которые затем пересылают их по сети. Ещё одно решение проблемы централизованного логгирования было предложено разработчиками утилиты journal2gelf, включённой в официальный репозиторий systemd: вывод journalсtl в формате JSON конвертируется в формат GELF, а затем передаётся приложению для сбора и анализа логов Graylog. Решение не очень удобное, но ничего лучше в текущей ситуации придумать нельзя. Остаётся только ждать, когда «родные» компоненты будут добавлены во все дистрибутивы.
Заключение
Как видно из проделанного рассмотрения, systemd journal представляет собой гибкий и удобный инструмент для сбора системных данных и данных приложений. Высокого уровня гибкости и удобства удалось добиться, во-первых, благодаря централизованному подходу к логгированию, а во-вторых — благодаря автоматической записи в логи подробных метаданных. С помощью journalctl можно просматривать логи, получая необходимую информацию для анализа работы и отладки различных системных компонентов. Если у вас есть вопросы и дополнения — добро пожаловать в комментарии. Разговор о systemd и его компонентах будет продолжен в следующих публикациях.
Читателей, которые по тем или иным причином не могут оставлять комментарии здесь, приглашаем в наш блог.
