Просмотр и управление логами Systemd с помощью Journalctl

Системное и логирование процессов — это лишь два из наиболее важных преимуществ systemd. Когда логи рассредоточены по всей системе, охватывают несколько приложений и обрабатываются различными процессами и демонами, их интерпретация может быть сложной задачей. Systemd предоставляет централизованное решение для управления всеми логами процессов ядра и пользовательского пространства в компиляционной среде, известной как журнал. Вы можете узнать больше о systemd в нашем руководстве по управлению службами и юнитами systemd с помощью systemctl. Все сообщения, генерируемые службами, initrd, ядрами и т. д. в журнале, обрабатываются демоном журнала. Цель этого руководства — показать, как получать доступ к данным журнала и управлять ими с помощью journalctl.

Основная концепция

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

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

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

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

Настройка системного времени

По умолчанию systemd отображает результаты по местному времени, что является преимуществом бинарного логирования журнала с точки зрения просмотра записей логов. Кроме того, их можно просматривать в формате UTC. Поэтому важно убедиться, что часовой пояс настроен правильно, прежде чем приступать к логированию в журнал. Для этого в systemd есть инструмент под названием timedatectl. Мы начнем с того, что посмотрим, какие часовые пояса доступны для использования, выведя список с помощью опции list-timezones:

После того как вы найдете часовой пояс, соответствующий местоположению вашего сервера, его можно установить с помощью опции set-timezone:

Чтобы протестировать и убедиться, что часовой пояс теперь отображается правильно, вы можете использовать команду timedatectl как саму по себе, так и с добавлением «status»:

Первая строка показывает местное время. Эта строка должна содержать правильное время для вашего региона.

Общий просмотр логов

Команда journalctl позволит вам просматривать логи, собранные демоном journald. При использовании journalctl каждая запись журнала из системы будет отображаться на экране, причем самые старые записи будут находиться вверху. Однако полный список данных будет состоять из десятков тысяч строк.

Те, кто использовал стандартное логирование syslog, найдут этот формат знакомым, но важно иметь в виду, что этот сбор данных включает информацию из множества источников, в отличие от метода syslog. Логи будут включать ранний процесс загрузки, initrd и ядро, а также стандартные ошибки приложений.

Теперь, когда установлено локальное время, все записи будут начинаться с временных меток в локальном времени, и это доступно для каждого лога, хранящегося в системе в данный момент, при этом вся логика отображается с использованием этой новой информации. Однако вы не ограничены локальным временем. Используя флаг –utc, вы также можете отображать временные метки в UTC:

Фильтрация журнала по времени

Наличие такого большого количества данных — это здорово, но прочесывать их и усваивать, не говоря уже о том, чтобы обрабатывать их в уме, может быть сложной задачей. С учетом этого мы переходим к самой важной части функции journalctl: фильтрации.

Отображение логов текущей загрузки

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

Если пользователь решит не изучать каждую отдельную запись, journalctl покажет загрузки более чем за день с удобными разделителями «Reboot». Это помогает логически разделить информацию о различных сеансах загрузки для анализа:

Информация о прошлых загрузках

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

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

Кроме того, вы можете отредактировать конфигурационный файл журнала следующим образом:

Установка параметра Storage= в значение «persistent» в разделе [Journal] включит постоянное логирование:

Как только это будет включено, journalctl сделает доступными определенные команды, которые помогут вам обозначить эти загрузки как единицы разделения. Чтобы просмотреть загрузки, записанные в journald, вы можете использовать опцию –list-boots в journalctl:

Как показано, каждая загрузка будет выведена на отдельной строке, причем в первой колонке будут отражены предыдущие загрузки в порядке от самой старой к самой последней. Если требуется более точная ссылка, во второй колонке содержится идентификатор загрузки. После этого указаны две спецификации времени. Для отображения информации журнала конкретной загрузки можно использовать данные как из первой, так и из второй колонки. Например, вы можете использовать флаг -b с относительным указателем загрузки -1 для просмотра информации о предпоследней перезагрузке:

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

Временные окна

Просмотр загрузок по ID — это один из вариантов, но часто бывает полезнее ссылаться на прошлые загрузки по временному интервалу в прошлом, который не обязательно совпадает с конкретными загрузками. Например, это актуально в ситуации, когда вы работаете с серверами, которые работают долго и перезагружаются нечасто. Фильтрацию временных ограничений можно выполнять с произвольными временными рамками. Это позволит отобразить только информацию о перезагрузках, попадающих в определенное временное окно. Параметры этого окна задаются с помощью опций –since и –until. Для временных опций доступно несколько форматов. Формат абсолютного значения времени выглядит следующим образом:

Итак, если вы хотите увидеть все загрузки с 10 января 2015 года, 17:15, введите следующую команду:

Если какие-либо компоненты опущены, используются встроенные значения по умолчанию. Кроме того, если дата не указана, по умолчанию используется текущая дата. Если отсутствует компонент времени, по умолчанию принимается полночь (00:00:00). Если вы опустите секунды в компоненте времени, они по умолчанию будут установлены на начало этой минуты (00):

Журнал может распознавать сокращения, связанные со временем, такие как «today» (сегодня), «tomorrow» (завтра), «yesterday» (вчера) и «now» (сейчас). Такие слова, как «ago» (назад), в сочетании с префиксами «-» и «+» можно использовать для построения команд, похожих на предложения:

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

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

Фильтрация по интересующим сообщениям

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

По юниту

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

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

Это особенно полезно при использовании возможности журнала объединять записи из нескольких юнитов, особенно взаимодействующих друг с другом. Если процесс Nginx подключен к юниту PHP-FPN для обработки динамического контента, записи можно объединить в хронологическом порядке, указав оба юнита:

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

По ID группы, процессу или пользователю

Многие службы запускают множество подпроцессов (дочерних процессов) для выполнения определенной работы. Если известен ID конкретного процесса, фильтрацию также можно выполнить, указав поле _PID. Если интересующий PID — 8088, можно сделать следующее:

Вы также можете просмотреть записи, зарегистрированные для определенной группы или конкретного пользователя. Это можно сделать с помощью фильтров _GID и _UID. Если веб-сервер работает от имени пользователя www-data, найти необходимый ID можно следующим образом:

Используя этот ID, вы можете просмотреть соответствующие результаты в журнале:

Systemd предоставляет множество полей для фильтрации. Некоторые поля заполняются службой journald на основе информации, собранной из системы во время записи лога, в то время как другие передаются из процесса, который в данный момент записывается.

Префикс _PID указывает на то, что информация была собрана из системы во время записи лога. Журнал автоматически записывает и индексирует PID в процессе логирования, чтобы в дальнейшем была доступна фильтрация. Чтобы узнать о доступных полях журнала, вы можете ввести:

Мы обсудим некоторые из них позже в этом руководстве, а пока коснемся других полезных опций, относящихся к этим полям. Если вы хотите увидеть все доступные значения для определенного поля журнала, вы можете использовать опцию -F. Если вы хотите узнать, какие идентификаторы групп (group IDs) есть в журнале systemd, можно выполнить следующее:

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

По пути к компоненту

Фильтрацию также можно выполнять, указав путь к файлу. Если это путь к исполняемому файлу, в journalctl будут отображаться записи, связанные с этим файлом. Если вас интересует исполняемый файл «bash», вы можете ввести:

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

Отображение сообщений ядра

Сообщения ядра, которые обычно находятся в выводе dmesg, также можно получить из журнала. Чтобы отображались только эти сообщения, мы используем флаги -k или -dmesg в нашей команде:

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

По приоритету

Системные администраторы часто предпочитают фильтрацию по приоритету. Логи с низким приоритетом, хотя часто и полезны для просмотра, могут запутывать и содержать много отвлекающих факторов, что затрудняет их анализ. Использование опции -p в journalctl позволяет отображать только сообщения указанного приоритета, отфильтровывая все остальные. Если вы хотите показать записи уровня ошибок (error) и выше, введите следующее:

Эта команда вернет все сообщения, обозначенные как ошибки (error), предупреждения (alert), чрезвычайные ситуации (emergency) или критические (critical), поскольку журнал использует стандартные уровни сообщений syslog. Уровни приоритета определяются числовым значением, ранжированным от самого высокого к самому низкому:

• 0: emerg
• 1: alert
• 2: crit
• 3: err
• 4: warning
• 5: notice
• 6: info
• 7: debug

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

Изменение отображения в журнале

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

Усечение/развертывание вывода

Мы можем настроить вид вывода, определяя, сжимает или расширяет данные journalctl. По умолчанию journalctl показывает запись полностью, уводя длинные строки вправо за пределы экрана. Вы можете просмотреть записи целиком, прокручивая их с помощью клавиши со стрелкой вправо. Пользователь может захотеть усечь вывод, при этом в конце строк, которые выходят за пределы экрана, будет отображаться многоточие. Для этого можно использовать опцию –no-full:

Кроме того, вы можете разрешить отображение абсолютно всего, независимо от длины или наличия непечатных символов, используя флаг -a:

Вывод в стандартный поток вывода

По умолчанию journalctl выводит данные в пейджер, но если вы хотите обрабатывать данные с помощью инструментов редактирования текста, вам, скорее всего, понадобится вывод в стандартный поток вывода. Вы можете добиться этого с помощью опции –no-pager:

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

Форматы вывода

Данные всегда проще анализировать, когда они представлены в более удобном формате. Журнал предоставляет несколько вариантов отображения с использованием квалификатора -o, за которым следует конкретный формат.

Если вы хотите вывести записи журнала в формате JSON, вы можете сделать это следующим образом:

Эта стратегия особенно полезна при использовании утилит синтаксического анализа. Формат json-pretty лучше подходит для отображения структур данных перед их передачей обработчику JSON:

Существует несколько форматов, которые вы можете использовать для отображения:

• cat: отображает только само поле сообщения.
• export: двоичный формат, подходящий для передачи или резервного копирования.
• json: стандартный JSON, по одной записи на строку.
• json-pretty: JSON, отформатированный для лучшего восприятия человеком
• json-sse: вывод в формате JSON, обернутый для совместимости с событиями, отправляемыми сервером (server-sent events)
• short: стандартный вывод в стиле syslog
• short-iso: стандартный формат, дополненный отображением меток времени в формате ISO 8601.
• short-monotonic: стандартный формат с монотонными метками времени.
• short-precise: стандартный формат с точностью до микросекунд
• verbose: показывает все доступные поля журнала для записи, включая те, которые обычно скрыты внутри.

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

Мониторинг активных процессов

Журнал позволяет отслеживать активные или недавние действия без использования других инструментов. Вы можете сделать это с помощью команды journalctl с функцией «tail».

• Отображение недавних логов

Использование опции -n (которая работает так же, как команда tail -n) позволит отобразить определенное количество записей:

Количество записей, которые вы хотите отобразить, можно указать в виде конкретного числа после квалификатора -n:

• Отслеживание логов

Вы также можете активно отслеживать логи по мере их записи в систему с помощью флага -f. Это работает так же, как команда tail -f:

Обслуживание журнала

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

Определение текущего использования диска

Флаг –disk-usage поможет определить, сколько места на диске в данный момент занимают логи:

Удаление старых логов

В systemd версии 218 (и последующих версиях) вы можете сжать журнал двумя разными способами. Первый — это опция –vacuum-size. Она позволяет сжать журнал, указав его размер. Другими словами, старые записи будут удаляться из журнала до тех пор, пока занимаемое пространство не достигнет заданного параметра:

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

Ограничение роста журнала

Вы также можете ограничить объем пространства, который будет занимать журнал. Это делается путем редактирования файла /etc/systemd.journald.conf. Рост журнала можно ограничить любым из следующих способов:

• SystemMaxUse=: указывает максимальный объем дискового пространства, который журналу разрешено использовать в постоянном хранилище.
• SystemKeepFree=: указывает, сколько места должно оставаться свободным при добавлении записей журнала в постоянное хранилище.
• SystemMaxFileSize=: определяет, насколько большими могут стать файлы журнала в постоянном хранилище до выполнения ротации.
• RuntimeMaxUse=: определяет, какой объем дискового пространства разрешено использовать во временном хранилище (в файловой системе /run).
• RuntimeKeepFree=: при записи данных во временное хранилище этот параметр указывает объем пространства, который должен быть зарезервирован для других целей (в файловой системе /run).
• RuntimeMaxFileSize=: указывает, какой объем пространства может занимать отдельный файл журнала во временном хранилище (в файловой системе /run) перед тем, как потребуется его ротация.

Все эти параметры помогают контролировать потребление дискового пространства журналом. Важно отметить, что параметры SystemMaxFileSize и RuntimeMaxFileSize будут нацелены на архивные файлы для достижения указанных лимитов. Об этом важно помнить при интерпретации количества файлов после операций очистки (vacuuming).

Заключение

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

Приятной работы!